SlideShare a Scribd company logo
1 of 59
Download to read offline
Consulting Member ofTechnical Staff
Real-World Performance
ServerTechnologies
Toon Koppelaars
Database Performance Core Principles
Part of Oracle eco-system since 1987
• Have done and seen quite a lot of application development
• Database design, SQL and PL/SQL
Big fan of “Using DatabaseAs a Processing Engine”
• Not just as a layer to persist data
Member of Oracle’s Real-World Performance Group
About Me
My Dilemma…
• That what you are about to hear, is probably not going to be of much help to you
• Why?
• Because you are stuck with applications that can’t be changed
• Those applications could run faster *and* use less computing resources, yet would require re-
architecting
• I can only create awareness of this
• My hope is that you can use this talk’s knowledge to influence architectural decisions of future
applications
• If I have a single CPU how many processes can be active at any one time?
• And if I have four CPU’s?
• What’s the implication if there are more processes wanting to run than there are CPU’s?
• If my process needs to access an external resource (network, I/O) what happens to it?
• Once request has finished, what decides when my process gets back onto CPU and how much is
it allocated?
• What is the difference between user and sys CPU?
Performance Core Principles: Why?
Database Performance Core Principles
• Implications of Oracle’s Process Based Architecture
• End User ResponseTime,Throughput, and DBTime
What happened last two decades with application development?
• It fundamentally moved away from these principles
Agenda
Oracle instance = Process based architecture:
Foreground process is serving your database calls
To perform efficiently:
1. process needs to get on CPU as quickly as possible
Process needs to stay on CPU as long as possible:
2. process shouldn’t go to sleep voluntarily a lot
3. process should experience as few involuntary sleeps as possible
Database Performance Core Principles
1: Get On CPU
Oracle
Foreground
Process
Idle CPU
Idle/sleeping
1: Get On CPU
Idle/sleeping
Idle
OS receives interrupt:
figures out which process to
wake-up
Scheduler needs to get this
process on CPU
CPU
Oracle
Foreground
Process
Application issues
database call
All work performed by
OS and scheduler is
reported as SYS cpu
• Only one process can be on a core at a time
(it’s either 1 or 0)
• How quickly you can get on core depends
on current utilization
• Higher busy rate  higher chance of
spending time on run-queue before getting
scheduled
• Less straightforward with multiple cores
1: Get On CPU
CPU Utilization Chance of getting scheduled
immediately
50% 1 in 2
66% 1 in 3
75% 1 in 4
80% 1 in 5
90% 1 in 10
• Not only does it take longer to get on CPU, moreover:
• Busy rate has measurable impact on DB-call response time
• Which becomes noticeable when CPU has 60-65+% busy rate
• This is in essence basic queueing theory, nothing new…
Impact of CPU Utilization on Database Call ResponseTime
Database Call ResponseTime, Single Core
R = S / (1 – U) Random arrival
Response time
Service time
Utilization%
R – S = queue-time
while resource is
servicing others
This is an
exponential curve
Every system starts queueing at some point, impacting response times
This depends upon:
• Arrival rate, service times, number of cores, and busy rate
More ComplexWith Multiple Cores
Response time
Arrival rate
Service
times
Number of
cores
CPU busy-rate
On busy system,
significant portion of
this is queuing-time
You never want database server to
be running at full capacity all the
time:
stay well clear of 100% busy
2: Stay on CPU, not Go to SleepVoluntarily a Lot
Ten database calls One database call
Completed 10 calls
10Voluntary sleeps
Scheduled 10 times
10 CPUThread
Context Switches
(more SYS cpu)
CPU CPU
Oracle
Foreground
Process
Oracle
Foreground
Process
Insert 10 rows
 row-by-row
Array-based or stored proc 
6
On 3 GHz core
this is 0.33 ms
This is about 3 µs
This is where Oracle
code spends most of
its time
Fetch by rowid
takes 6-10 µs
2: Stay on CPU, not Go to SleepVoluntarily a Lot
Oracle
Foreground
Process
Oracle
Foreground
Process
Ten database calls One database call
Scheduled 10 times
10 Context Switches
10 Oracle kernel entries
and exits
10 Operating system
entries and exits
CPU CPU
Oracle Kernel Entry and Exit
• Like a thread context switch, this too is measurable overhead
If your calls are small and fast
Oracle Kernel Entry and Exit
• We measured this in a lab environment
• In summary:
• Simple batch process
• Built in Java
• Single threaded
• Mix of single row selects, single row inserts and single row deletes
• All issued (sequentially) over JDBC to database
• Generating 9000 calls per second
• Using “perf”, we profiled foreground process to see where CPU time is spent
Visualizing CPU Usage With Flamegraph
• Perf samples n times per second, the call-stack of your process’ execution thread
• Flamegraph visualizes this
Oracle Kernel Entry and Exit
Here, third of
USER cpu is per-
call overhead
How to SpotThis in AWR Report
DB CPU >>
sql execute elapsed time
10,000 seconds of USER cpu
spent on entry/exit
How to SpotThis in AWR Report
Do not sum up to 100%, while we
are cpu bound
This Overhead Also on Application Servers!
Every process has
this overhead!
Full Story Here
• Youtube video: https://www.youtube.com/watch?v=8jiJDflpw4Y
“Koppelaars database”
Status sofar,
• Process architectures have per call overheads:
1. OS interrupt figuring out which process to start (sys)
2. Scheduler doing its work (sys)
3. On-chip microcode execution to re-instantiate process state (sys)
4. Entering Oracle code (user)
Oracle instance = Process based architecture:
Foreground process is serving your database calls
To perform efficiently:
1. process needs to get on CPU as quickly as possible
Process needs to stay on CPU as long as possible:
2. process shouldn’t go to sleep voluntarily a lot
3. process should experience as few involuntary sleeps as possible
Database Performance Core Principles
3: Stay on CPU, minimal Number of Involuntary Sleeps
Too many processes
OS scheduler
de-schedules processes while they
still have more CPU work to do =
involuntary context switch
(sleep)CPU
Oracle
Foreground
Process
Oracle
Foreground
Process
Oracle
Foreground
Process
DB call DB callDB call
Three processes all want
to insert 10 rows
(array-based or stored procedure)
Better to have one
process insert 30 rows
Impact ofToo Many Processes
0
2000
4000
6000
8000
10000
12000
14000
16000
4 8 12 16 20 24 28
1 Proc/Core
10 Proc/CoreAvg
50 Proc/CoreAvg
# ofCPUs
TX/s
Database Performance Core Principles
• Implications of Oracle’s Process Based Architecture
• User ResponseTime,Throughput and DBTime
Database Performance Core Principles
• Actual duration is measure of performance quality (shorter = better)
• Consistency of response time is an equally important measure of performance quality
• Variance in response times will not delight your users
User ResponseTime
0
1
2
3
4
5
6
7
8
9
10
0 1 2 3 4 5 6 7 8 9 10
ResponseTime Experienced by User
Frequency X 1,000
Response time sec
Multi-hump indicating response
times with high variance
Long tail
Short tail
Single distinct spike with majority
of user experiences
• Throughput is the number of units of work processed within a period of time
• Throughput is not response time
• As the system gets busier, throughput increases (good), but the response time for each individual
unit of work will also increase (bad)
• If you’ve witnessed throughput X at 40% busy,
don’t expect throughput 2*X at 80% busy
Throughput
ResponseTimeVersus DBTime
Network Network Database
Server
Application
Server
End User
Total User Response Time
DBTime
Will be significant if
not both in cloud
• Response time
• Throughput
• DBTime
Three different things
Remember
0
1
2
3
4
5
6
7
8
9
10
0 1 2 3 4 5 6 7 8 9 10
ResponseTime Core Principle
Frequency X
1,000,000
Response Time sec
How to
ensure this
Instead of this
Good
Bad
Network Network DatabaseApplication
End User
Total User Response Time
Time Line
Query
Query
Insert
Delete
Delete
User Experience ResponseTime: Breakdown
Network Network Database
User Experience ResponseTime: Breakdown
Application
End User
Total User Response Time
Time Line
Query
Query
Insert
Delete
Delete
Again: %-Busy and Call Counts matter
User Experience ResponseTime:Variance
Breakdown of response time:
Linear relation?
How to prevent multi-hump response times
Ensuring Single Spike
Breakdown of response time:
Actual relation!
More calls  more queueing
With increasing variance
Smaller = More consistent,
single spike, response times
The Oracle database is a process based architecture
To perform efficiently each process requires:
1. to get on CPU asap, and stay on CPU
2. to not go to sleep voluntarily a lot
3. to experience as few involuntary sleeps as possible
Consistent response times require minimization of call counts across components (processes)
DB Performance Core Principles: Summary
You want to stay well clear of
CPU’s being 100% busy
Use architecture that requires small
number of processes
Better to call database
with more work than to
call with little work
So, If We SeeThese…
High number of voluntary
sleeps per second
High Call Counts per Second
LittleWork per Call (Row-by-Row Processing)
Not wanting to stay on
CPU long
High Process-to-Core Ratio + Busy System
OS Scheduler
doing what it does
best:
de-scheduling
Despite lots of CPU being used, not much work is getting done
 Majority of CPU time is spent on per-call overhead across all layers
With high busy rates on database and application servers
 Response times probably aren’t consistent
We Pretty Much KnowThat
LastTopic…
• We stopped using database as a processing engine
Conceptually 3 tiers
• Exposed functionality
- GUI's for human interaction
- REST, or otherwise, for software interaction
Internals
• Business logic
• Data store, relational database
High Level Breakdown of OLTP Application
User
Interfaces
Software
Interfaces
Business
Logic
Table
Data Store
Two Fundamentally Different Architectures
DBMS = Persistence Layer
"NoPlsql" Approach
DBMS = Processing Engine
"SmartDB" Approach
You’ll Always See: Row-by-Row, SingleTable Approach
Single-row data access
Business logic
Row fetching (data access)
Business logic
Row-by-row updating (data access)
“if-then-else-loop” code
PL/SQL here for convenience
Primitive data access
(single table, row-by-row)
You’ll Never SeeThis: Set-Based SQL
Decrease the discount percentage on all (still open) order lines,
of a given high-risk order.
Why not?
Because persistence frameworks
aren’t capable of generating this
References >1 table
Affects >1 row
“Chatty” Applications When Business Logic Outside DB
“Decrease discount
percentages for high-risk
order”
SQL engine
UI
SQL SQL SQL SQL SQL
High call counts
between processes
SQL SQL
One set-based update,
referencing multiple
tables
SQL engine
UI
SQL or SP-call
Two Fundamentally Different Architectures
Aka #SmartDB
All business logic inside database
Only UI outside database
• One user experience = one database call,
reducing voluntary sleeps
• Negligible per-call overhead, as call involves
substantial amount of work
• Requires small number of FG-processes, reducing
involuntary sleeps
Database as Processing Engine
Aka #NoPlsql
All business logic outside database
“Layered Software Architectures”
• Many small calls to database leading to high
rate of voluntary sleeps
• Noticeable per-call overhead, as call is single
row statement
• Requires large number of FG-processes risking
high rate of involuntary sleeps
Database as Bit Bucket
Youtube: “asktom
connection pool”
Every SQL statement submitted from application server
• Requires OS entry
• Requires OS scheduling
• Requires CPU context switch
• Requires Oracle kernel entry
Before it arrives at SQL-engine
Sum of these fixed CPU overheads is very real
for row-by-row SQL!
• Could be 2X CPU knock-on to SQL execution
Implication ForYour Computing Resources Footprint
Network Network Database
Implication ForYour Footprint: Affects Application Server too
Application
End User
Not just on database server: on application server as well
Query
Query
Insert
Delete
Delete
:Thread context switch
Micro Services Architecture: Rife With Context Switches
End User
Check BalanceAudit Event
Time Line: breakdown consists of many more components
v v
More components  risk
of more variability
Introduce ridiculous inefficient use of availableCPU resources
Only way to improve this  move away from row-by-row processing
This requires hand-written set-based SQL
Implication of Moving Business Logic Out of DBMS
We see database cores spending up to 60% of CPU-cycles
on OS and CPU context-switches and getting in/out database kernel
And application servers spending majority of time descending
and ascending up JDBC and framework layers
Want to Get an Idea of Inefficiency onYour Server?
High Sys-to-User ratio is
good indicator
You’re not using DBMS as it
was designed to be used
How to ReduceYour Computing Resources Footprint?
DBMS = Persistence Layer
More busy
DBMS = Processing Engine
Less busy
The #SmartDB gains of:
• Massive reduction in call counts, greatly diminishes all aforementioned
overheads per call
• Outweigh additional work you bring into database by implementing
your business logic inside SQL and PL/SQL
Here IsThe, Counter Intuitive, Core Fact
• Majority of current applications have large computing resources footprints
• Why? Because they were built using layered software architectures and have all business logic
execute on application servers
• These architectures cause very high call counts across components (processes), and thereby they
violate all database core performance principles
In Summary
• If you want to reduce your computing resources footprint
 Don’t bring data to code, bring code to data, use smart SQL
• Focus on minimizing chattiness, process context switches, call-counts, etc.
• You’ll reduce both your database-server footprint, as well as your application-server footprints
• And your user experiences will be consistent
• Questions: emailToon.Koppelaars@oracle.com, twitter: @toonkoppelaars
In Summary

More Related Content

What's hot

ScalabilityAvailability
ScalabilityAvailabilityScalabilityAvailability
ScalabilityAvailabilitywebuploader
 
Web protocols for java developers
Web protocols for java developersWeb protocols for java developers
Web protocols for java developersPavel Bucek
 
Servlet 4.0 at GeekOut 2015
Servlet 4.0 at GeekOut 2015Servlet 4.0 at GeekOut 2015
Servlet 4.0 at GeekOut 2015Edward Burns
 
NoSQL and SQL - Why Choose? Enjoy the best of both worlds with MySQL
NoSQL and SQL - Why Choose? Enjoy the best of both worlds with MySQLNoSQL and SQL - Why Choose? Enjoy the best of both worlds with MySQL
NoSQL and SQL - Why Choose? Enjoy the best of both worlds with MySQLAndrew Morgan
 
Pratiques administration avancées et techniques de développement
Pratiques administration avancées et techniques de développementPratiques administration avancées et techniques de développement
Pratiques administration avancées et techniques de développementParis Salesforce Developer Group
 
2.Oracle’S High Availability Vision
2.Oracle’S High Availability Vision2.Oracle’S High Availability Vision
2.Oracle’S High Availability VisionErmando
 
An Engineer's Intro to Oracle Coherence
An Engineer's Intro to Oracle CoherenceAn Engineer's Intro to Oracle Coherence
An Engineer's Intro to Oracle CoherenceOracle
 
Aman sharma hyd_12crac High Availability Day 2015
Aman sharma hyd_12crac High Availability Day 2015Aman sharma hyd_12crac High Availability Day 2015
Aman sharma hyd_12crac High Availability Day 2015aioughydchapter
 
Web Speed And Scalability
Web Speed And ScalabilityWeb Speed And Scalability
Web Speed And ScalabilityJason Ragsdale
 
HTTP/2 comes to Java. What Servlet 4.0 means to you. DevNexus 2015
HTTP/2 comes to Java.  What Servlet 4.0 means to you. DevNexus 2015HTTP/2 comes to Java.  What Servlet 4.0 means to you. DevNexus 2015
HTTP/2 comes to Java. What Servlet 4.0 means to you. DevNexus 2015Edward Burns
 
CON5898 What Servlet 4.0 Means To You
CON5898 What Servlet 4.0 Means To YouCON5898 What Servlet 4.0 Means To You
CON5898 What Servlet 4.0 Means To YouEdward Burns
 
Top 10 Application Problems
Top 10 Application ProblemsTop 10 Application Problems
Top 10 Application ProblemsAppDynamics
 
Batch Applications for Java Platform 1.0: Java EE 7 and GlassFish
Batch Applications for Java Platform 1.0: Java EE 7 and GlassFishBatch Applications for Java Platform 1.0: Java EE 7 and GlassFish
Batch Applications for Java Platform 1.0: Java EE 7 and GlassFishArun Gupta
 
Oracle E-Business Suite On Oracle Cloud
Oracle E-Business Suite On Oracle CloudOracle E-Business Suite On Oracle Cloud
Oracle E-Business Suite On Oracle Cloudpasalapudi
 
Oracle IaaS Overview - AIOUG Hyderabad Chapter
Oracle IaaS Overview - AIOUG Hyderabad ChapterOracle IaaS Overview - AIOUG Hyderabad Chapter
Oracle IaaS Overview - AIOUG Hyderabad Chapteraioughydchapter
 
Node.js and Oracle Database: New Development Techniques
Node.js and Oracle Database: New Development TechniquesNode.js and Oracle Database: New Development Techniques
Node.js and Oracle Database: New Development TechniquesChristopher Jones
 
JavaOne 2014 BOF4241 What's Next for JSF?
JavaOne 2014 BOF4241 What's Next for JSF?JavaOne 2014 BOF4241 What's Next for JSF?
JavaOne 2014 BOF4241 What's Next for JSF?Edward Burns
 
Scaling asp.net websites to millions of users
Scaling asp.net websites to millions of usersScaling asp.net websites to millions of users
Scaling asp.net websites to millions of usersoazabir
 

What's hot (20)

ScalabilityAvailability
ScalabilityAvailabilityScalabilityAvailability
ScalabilityAvailability
 
Web protocols for java developers
Web protocols for java developersWeb protocols for java developers
Web protocols for java developers
 
Servlet 4.0 at GeekOut 2015
Servlet 4.0 at GeekOut 2015Servlet 4.0 at GeekOut 2015
Servlet 4.0 at GeekOut 2015
 
NoSQL and SQL - Why Choose? Enjoy the best of both worlds with MySQL
NoSQL and SQL - Why Choose? Enjoy the best of both worlds with MySQLNoSQL and SQL - Why Choose? Enjoy the best of both worlds with MySQL
NoSQL and SQL - Why Choose? Enjoy the best of both worlds with MySQL
 
Pratiques administration avancées et techniques de développement
Pratiques administration avancées et techniques de développementPratiques administration avancées et techniques de développement
Pratiques administration avancées et techniques de développement
 
2.Oracle’S High Availability Vision
2.Oracle’S High Availability Vision2.Oracle’S High Availability Vision
2.Oracle’S High Availability Vision
 
An Engineer's Intro to Oracle Coherence
An Engineer's Intro to Oracle CoherenceAn Engineer's Intro to Oracle Coherence
An Engineer's Intro to Oracle Coherence
 
Aman sharma hyd_12crac High Availability Day 2015
Aman sharma hyd_12crac High Availability Day 2015Aman sharma hyd_12crac High Availability Day 2015
Aman sharma hyd_12crac High Availability Day 2015
 
Web Speed And Scalability
Web Speed And ScalabilityWeb Speed And Scalability
Web Speed And Scalability
 
HTTP/2 comes to Java. What Servlet 4.0 means to you. DevNexus 2015
HTTP/2 comes to Java.  What Servlet 4.0 means to you. DevNexus 2015HTTP/2 comes to Java.  What Servlet 4.0 means to you. DevNexus 2015
HTTP/2 comes to Java. What Servlet 4.0 means to you. DevNexus 2015
 
CON5898 What Servlet 4.0 Means To You
CON5898 What Servlet 4.0 Means To YouCON5898 What Servlet 4.0 Means To You
CON5898 What Servlet 4.0 Means To You
 
Top 10 Application Problems
Top 10 Application ProblemsTop 10 Application Problems
Top 10 Application Problems
 
Batch Applications for Java Platform 1.0: Java EE 7 and GlassFish
Batch Applications for Java Platform 1.0: Java EE 7 and GlassFishBatch Applications for Java Platform 1.0: Java EE 7 and GlassFish
Batch Applications for Java Platform 1.0: Java EE 7 and GlassFish
 
Oracle E-Business Suite On Oracle Cloud
Oracle E-Business Suite On Oracle CloudOracle E-Business Suite On Oracle Cloud
Oracle E-Business Suite On Oracle Cloud
 
Oracle IaaS Overview - AIOUG Hyderabad Chapter
Oracle IaaS Overview - AIOUG Hyderabad ChapterOracle IaaS Overview - AIOUG Hyderabad Chapter
Oracle IaaS Overview - AIOUG Hyderabad Chapter
 
Node.js and Oracle Database: New Development Techniques
Node.js and Oracle Database: New Development TechniquesNode.js and Oracle Database: New Development Techniques
Node.js and Oracle Database: New Development Techniques
 
ODTUG Webinar AWR Warehouse
ODTUG Webinar AWR WarehouseODTUG Webinar AWR Warehouse
ODTUG Webinar AWR Warehouse
 
HTTP/2 Comes to Java
HTTP/2 Comes to JavaHTTP/2 Comes to Java
HTTP/2 Comes to Java
 
JavaOne 2014 BOF4241 What's Next for JSF?
JavaOne 2014 BOF4241 What's Next for JSF?JavaOne 2014 BOF4241 What's Next for JSF?
JavaOne 2014 BOF4241 What's Next for JSF?
 
Scaling asp.net websites to millions of users
Scaling asp.net websites to millions of usersScaling asp.net websites to millions of users
Scaling asp.net websites to millions of users
 

Similar to Database Core performance principles

Analyzing and Interpreting AWR
Analyzing and Interpreting AWRAnalyzing and Interpreting AWR
Analyzing and Interpreting AWRpasalapudi
 
Secrets of highly_avail_oltp_archs
Secrets of highly_avail_oltp_archsSecrets of highly_avail_oltp_archs
Secrets of highly_avail_oltp_archsTarik Essawi
 
Insider operating system
Insider   operating systemInsider   operating system
Insider operating systemAditi Saxena
 
Problems with PostgreSQL on Multi-core Systems with MultiTerabyte Data
Problems with PostgreSQL on Multi-core Systems with MultiTerabyte DataProblems with PostgreSQL on Multi-core Systems with MultiTerabyte Data
Problems with PostgreSQL on Multi-core Systems with MultiTerabyte DataJignesh Shah
 
Analyze database system using a 3 d method
Analyze database system using a 3 d methodAnalyze database system using a 3 d method
Analyze database system using a 3 d methodAjith Narayanan
 
MySQL Performance Tuning at COSCUP 2014
MySQL Performance Tuning at COSCUP 2014MySQL Performance Tuning at COSCUP 2014
MySQL Performance Tuning at COSCUP 2014Ryusuke Kajiyama
 
Automation system performance myths
Automation system performance mythsAutomation system performance myths
Automation system performance mythspaulguerin
 
End-to-end Troubleshooting Checklist for Microsoft SQL Server
End-to-end Troubleshooting Checklist for Microsoft SQL ServerEnd-to-end Troubleshooting Checklist for Microsoft SQL Server
End-to-end Troubleshooting Checklist for Microsoft SQL ServerKevin Kline
 
Collaborate 2019 - How to Understand an AWR Report
Collaborate 2019 - How to Understand an AWR ReportCollaborate 2019 - How to Understand an AWR Report
Collaborate 2019 - How to Understand an AWR ReportAlfredo Krieg
 
Exploring Oracle Database Performance Tuning Best Practices for DBAs and Deve...
Exploring Oracle Database Performance Tuning Best Practices for DBAs and Deve...Exploring Oracle Database Performance Tuning Best Practices for DBAs and Deve...
Exploring Oracle Database Performance Tuning Best Practices for DBAs and Deve...Aaron Shilo
 
Chapter -2 operating system presentation
Chapter -2 operating system presentationChapter -2 operating system presentation
Chapter -2 operating system presentationchnrketan
 
Application Performance Troubleshooting 1x1 - Part 2 - Noch mehr Schweine und...
Application Performance Troubleshooting 1x1 - Part 2 - Noch mehr Schweine und...Application Performance Troubleshooting 1x1 - Part 2 - Noch mehr Schweine und...
Application Performance Troubleshooting 1x1 - Part 2 - Noch mehr Schweine und...rschuppe
 
MongoDB World 2019: Finding the Right MongoDB Atlas Cluster Size: Does This I...
MongoDB World 2019: Finding the Right MongoDB Atlas Cluster Size: Does This I...MongoDB World 2019: Finding the Right MongoDB Atlas Cluster Size: Does This I...
MongoDB World 2019: Finding the Right MongoDB Atlas Cluster Size: Does This I...MongoDB
 
Mapping Data Flows Perf Tuning April 2021
Mapping Data Flows Perf Tuning April 2021Mapping Data Flows Perf Tuning April 2021
Mapping Data Flows Perf Tuning April 2021Mark Kromer
 
שבוע אורקל 2016
שבוע אורקל 2016שבוע אורקל 2016
שבוע אורקל 2016Aaron Shilo
 
Progress Openedge performance management
Progress Openedge performance managementProgress Openedge performance management
Progress Openedge performance managementYassine MOALLA
 
Progress OE performance management
Progress OE performance managementProgress OE performance management
Progress OE performance managementYassine MOALLA
 
SQL Server Wait Types Everyone Should Know
SQL Server Wait Types Everyone Should KnowSQL Server Wait Types Everyone Should Know
SQL Server Wait Types Everyone Should KnowDean Richards
 
Real-Time Inverted Search NYC ASLUG Oct 2014
Real-Time Inverted Search NYC ASLUG Oct 2014Real-Time Inverted Search NYC ASLUG Oct 2014
Real-Time Inverted Search NYC ASLUG Oct 2014Bryan Bende
 

Similar to Database Core performance principles (20)

Analyzing and Interpreting AWR
Analyzing and Interpreting AWRAnalyzing and Interpreting AWR
Analyzing and Interpreting AWR
 
Secrets of highly_avail_oltp_archs
Secrets of highly_avail_oltp_archsSecrets of highly_avail_oltp_archs
Secrets of highly_avail_oltp_archs
 
Insider operating system
Insider   operating systemInsider   operating system
Insider operating system
 
Problems with PostgreSQL on Multi-core Systems with MultiTerabyte Data
Problems with PostgreSQL on Multi-core Systems with MultiTerabyte DataProblems with PostgreSQL on Multi-core Systems with MultiTerabyte Data
Problems with PostgreSQL on Multi-core Systems with MultiTerabyte Data
 
Analyze database system using a 3 d method
Analyze database system using a 3 d methodAnalyze database system using a 3 d method
Analyze database system using a 3 d method
 
MySQL Performance Tuning at COSCUP 2014
MySQL Performance Tuning at COSCUP 2014MySQL Performance Tuning at COSCUP 2014
MySQL Performance Tuning at COSCUP 2014
 
Scaling tappsi
Scaling tappsiScaling tappsi
Scaling tappsi
 
Automation system performance myths
Automation system performance mythsAutomation system performance myths
Automation system performance myths
 
End-to-end Troubleshooting Checklist for Microsoft SQL Server
End-to-end Troubleshooting Checklist for Microsoft SQL ServerEnd-to-end Troubleshooting Checklist for Microsoft SQL Server
End-to-end Troubleshooting Checklist for Microsoft SQL Server
 
Collaborate 2019 - How to Understand an AWR Report
Collaborate 2019 - How to Understand an AWR ReportCollaborate 2019 - How to Understand an AWR Report
Collaborate 2019 - How to Understand an AWR Report
 
Exploring Oracle Database Performance Tuning Best Practices for DBAs and Deve...
Exploring Oracle Database Performance Tuning Best Practices for DBAs and Deve...Exploring Oracle Database Performance Tuning Best Practices for DBAs and Deve...
Exploring Oracle Database Performance Tuning Best Practices for DBAs and Deve...
 
Chapter -2 operating system presentation
Chapter -2 operating system presentationChapter -2 operating system presentation
Chapter -2 operating system presentation
 
Application Performance Troubleshooting 1x1 - Part 2 - Noch mehr Schweine und...
Application Performance Troubleshooting 1x1 - Part 2 - Noch mehr Schweine und...Application Performance Troubleshooting 1x1 - Part 2 - Noch mehr Schweine und...
Application Performance Troubleshooting 1x1 - Part 2 - Noch mehr Schweine und...
 
MongoDB World 2019: Finding the Right MongoDB Atlas Cluster Size: Does This I...
MongoDB World 2019: Finding the Right MongoDB Atlas Cluster Size: Does This I...MongoDB World 2019: Finding the Right MongoDB Atlas Cluster Size: Does This I...
MongoDB World 2019: Finding the Right MongoDB Atlas Cluster Size: Does This I...
 
Mapping Data Flows Perf Tuning April 2021
Mapping Data Flows Perf Tuning April 2021Mapping Data Flows Perf Tuning April 2021
Mapping Data Flows Perf Tuning April 2021
 
שבוע אורקל 2016
שבוע אורקל 2016שבוע אורקל 2016
שבוע אורקל 2016
 
Progress Openedge performance management
Progress Openedge performance managementProgress Openedge performance management
Progress Openedge performance management
 
Progress OE performance management
Progress OE performance managementProgress OE performance management
Progress OE performance management
 
SQL Server Wait Types Everyone Should Know
SQL Server Wait Types Everyone Should KnowSQL Server Wait Types Everyone Should Know
SQL Server Wait Types Everyone Should Know
 
Real-Time Inverted Search NYC ASLUG Oct 2014
Real-Time Inverted Search NYC ASLUG Oct 2014Real-Time Inverted Search NYC ASLUG Oct 2014
Real-Time Inverted Search NYC ASLUG Oct 2014
 

Recently uploaded

MEASURES OF DISPERSION I BSc Botany .ppt
MEASURES OF DISPERSION I BSc Botany .pptMEASURES OF DISPERSION I BSc Botany .ppt
MEASURES OF DISPERSION I BSc Botany .pptaigil2
 
The Universal GTM - how we design GTM and dataLayer
The Universal GTM - how we design GTM and dataLayerThe Universal GTM - how we design GTM and dataLayer
The Universal GTM - how we design GTM and dataLayerPavel Šabatka
 
AI for Sustainable Development Goals (SDGs)
AI for Sustainable Development Goals (SDGs)AI for Sustainable Development Goals (SDGs)
AI for Sustainable Development Goals (SDGs)Data & Analytics Magazin
 
5 Ds to Define Data Archiving Best Practices
5 Ds to Define Data Archiving Best Practices5 Ds to Define Data Archiving Best Practices
5 Ds to Define Data Archiving Best PracticesDataArchiva
 
TINJUAN PEMROSESAN TRANSAKSI DAN ERP.pptx
TINJUAN PEMROSESAN TRANSAKSI DAN ERP.pptxTINJUAN PEMROSESAN TRANSAKSI DAN ERP.pptx
TINJUAN PEMROSESAN TRANSAKSI DAN ERP.pptxDwiAyuSitiHartinah
 
YourView Panel Book.pptx YourView Panel Book.
YourView Panel Book.pptx YourView Panel Book.YourView Panel Book.pptx YourView Panel Book.
YourView Panel Book.pptx YourView Panel Book.JasonViviers2
 
Persuasive E-commerce, Our Biased Brain @ Bikkeldag 2024
Persuasive E-commerce, Our Biased Brain @ Bikkeldag 2024Persuasive E-commerce, Our Biased Brain @ Bikkeldag 2024
Persuasive E-commerce, Our Biased Brain @ Bikkeldag 2024Guido X Jansen
 
Strategic CX: A Deep Dive into Voice of the Customer Insights for Clarity
Strategic CX: A Deep Dive into Voice of the Customer Insights for ClarityStrategic CX: A Deep Dive into Voice of the Customer Insights for Clarity
Strategic CX: A Deep Dive into Voice of the Customer Insights for ClarityAggregage
 
CI, CD -Tools to integrate without manual intervention
CI, CD -Tools to integrate without manual interventionCI, CD -Tools to integrate without manual intervention
CI, CD -Tools to integrate without manual interventionajayrajaganeshkayala
 
Elements of language learning - an analysis of how different elements of lang...
Elements of language learning - an analysis of how different elements of lang...Elements of language learning - an analysis of how different elements of lang...
Elements of language learning - an analysis of how different elements of lang...PrithaVashisht1
 
Mapping the pubmed data under different suptopics using NLP.pptx
Mapping the pubmed data under different suptopics using NLP.pptxMapping the pubmed data under different suptopics using NLP.pptx
Mapping the pubmed data under different suptopics using NLP.pptxVenkatasubramani13
 
ChistaDATA Real-Time DATA Analytics Infrastructure
ChistaDATA Real-Time DATA Analytics InfrastructureChistaDATA Real-Time DATA Analytics Infrastructure
ChistaDATA Real-Time DATA Analytics Infrastructuresonikadigital1
 
Cash Is Still King: ATM market research '2023
Cash Is Still King: ATM market research '2023Cash Is Still King: ATM market research '2023
Cash Is Still King: ATM market research '2023Vladislav Solodkiy
 
How is Real-Time Analytics Different from Traditional OLAP?
How is Real-Time Analytics Different from Traditional OLAP?How is Real-Time Analytics Different from Traditional OLAP?
How is Real-Time Analytics Different from Traditional OLAP?sonikadigital1
 
Master's Thesis - Data Science - Presentation
Master's Thesis - Data Science - PresentationMaster's Thesis - Data Science - Presentation
Master's Thesis - Data Science - PresentationGiorgio Carbone
 
SFBA Splunk Usergroup meeting March 13, 2024
SFBA Splunk Usergroup meeting March 13, 2024SFBA Splunk Usergroup meeting March 13, 2024
SFBA Splunk Usergroup meeting March 13, 2024Becky Burwell
 
Virtuosoft SmartSync Product Introduction
Virtuosoft SmartSync Product IntroductionVirtuosoft SmartSync Product Introduction
Virtuosoft SmartSync Product Introductionsanjaymuralee1
 

Recently uploaded (17)

MEASURES OF DISPERSION I BSc Botany .ppt
MEASURES OF DISPERSION I BSc Botany .pptMEASURES OF DISPERSION I BSc Botany .ppt
MEASURES OF DISPERSION I BSc Botany .ppt
 
The Universal GTM - how we design GTM and dataLayer
The Universal GTM - how we design GTM and dataLayerThe Universal GTM - how we design GTM and dataLayer
The Universal GTM - how we design GTM and dataLayer
 
AI for Sustainable Development Goals (SDGs)
AI for Sustainable Development Goals (SDGs)AI for Sustainable Development Goals (SDGs)
AI for Sustainable Development Goals (SDGs)
 
5 Ds to Define Data Archiving Best Practices
5 Ds to Define Data Archiving Best Practices5 Ds to Define Data Archiving Best Practices
5 Ds to Define Data Archiving Best Practices
 
TINJUAN PEMROSESAN TRANSAKSI DAN ERP.pptx
TINJUAN PEMROSESAN TRANSAKSI DAN ERP.pptxTINJUAN PEMROSESAN TRANSAKSI DAN ERP.pptx
TINJUAN PEMROSESAN TRANSAKSI DAN ERP.pptx
 
YourView Panel Book.pptx YourView Panel Book.
YourView Panel Book.pptx YourView Panel Book.YourView Panel Book.pptx YourView Panel Book.
YourView Panel Book.pptx YourView Panel Book.
 
Persuasive E-commerce, Our Biased Brain @ Bikkeldag 2024
Persuasive E-commerce, Our Biased Brain @ Bikkeldag 2024Persuasive E-commerce, Our Biased Brain @ Bikkeldag 2024
Persuasive E-commerce, Our Biased Brain @ Bikkeldag 2024
 
Strategic CX: A Deep Dive into Voice of the Customer Insights for Clarity
Strategic CX: A Deep Dive into Voice of the Customer Insights for ClarityStrategic CX: A Deep Dive into Voice of the Customer Insights for Clarity
Strategic CX: A Deep Dive into Voice of the Customer Insights for Clarity
 
CI, CD -Tools to integrate without manual intervention
CI, CD -Tools to integrate without manual interventionCI, CD -Tools to integrate without manual intervention
CI, CD -Tools to integrate without manual intervention
 
Elements of language learning - an analysis of how different elements of lang...
Elements of language learning - an analysis of how different elements of lang...Elements of language learning - an analysis of how different elements of lang...
Elements of language learning - an analysis of how different elements of lang...
 
Mapping the pubmed data under different suptopics using NLP.pptx
Mapping the pubmed data under different suptopics using NLP.pptxMapping the pubmed data under different suptopics using NLP.pptx
Mapping the pubmed data under different suptopics using NLP.pptx
 
ChistaDATA Real-Time DATA Analytics Infrastructure
ChistaDATA Real-Time DATA Analytics InfrastructureChistaDATA Real-Time DATA Analytics Infrastructure
ChistaDATA Real-Time DATA Analytics Infrastructure
 
Cash Is Still King: ATM market research '2023
Cash Is Still King: ATM market research '2023Cash Is Still King: ATM market research '2023
Cash Is Still King: ATM market research '2023
 
How is Real-Time Analytics Different from Traditional OLAP?
How is Real-Time Analytics Different from Traditional OLAP?How is Real-Time Analytics Different from Traditional OLAP?
How is Real-Time Analytics Different from Traditional OLAP?
 
Master's Thesis - Data Science - Presentation
Master's Thesis - Data Science - PresentationMaster's Thesis - Data Science - Presentation
Master's Thesis - Data Science - Presentation
 
SFBA Splunk Usergroup meeting March 13, 2024
SFBA Splunk Usergroup meeting March 13, 2024SFBA Splunk Usergroup meeting March 13, 2024
SFBA Splunk Usergroup meeting March 13, 2024
 
Virtuosoft SmartSync Product Introduction
Virtuosoft SmartSync Product IntroductionVirtuosoft SmartSync Product Introduction
Virtuosoft SmartSync Product Introduction
 

Database Core performance principles

  • 1. Consulting Member ofTechnical Staff Real-World Performance ServerTechnologies Toon Koppelaars Database Performance Core Principles
  • 2. Part of Oracle eco-system since 1987 • Have done and seen quite a lot of application development • Database design, SQL and PL/SQL Big fan of “Using DatabaseAs a Processing Engine” • Not just as a layer to persist data Member of Oracle’s Real-World Performance Group About Me
  • 3. My Dilemma… • That what you are about to hear, is probably not going to be of much help to you • Why? • Because you are stuck with applications that can’t be changed • Those applications could run faster *and* use less computing resources, yet would require re- architecting • I can only create awareness of this • My hope is that you can use this talk’s knowledge to influence architectural decisions of future applications
  • 4. • If I have a single CPU how many processes can be active at any one time? • And if I have four CPU’s? • What’s the implication if there are more processes wanting to run than there are CPU’s? • If my process needs to access an external resource (network, I/O) what happens to it? • Once request has finished, what decides when my process gets back onto CPU and how much is it allocated? • What is the difference between user and sys CPU? Performance Core Principles: Why?
  • 5. Database Performance Core Principles • Implications of Oracle’s Process Based Architecture • End User ResponseTime,Throughput, and DBTime What happened last two decades with application development? • It fundamentally moved away from these principles Agenda
  • 6. Oracle instance = Process based architecture: Foreground process is serving your database calls To perform efficiently: 1. process needs to get on CPU as quickly as possible Process needs to stay on CPU as long as possible: 2. process shouldn’t go to sleep voluntarily a lot 3. process should experience as few involuntary sleeps as possible Database Performance Core Principles
  • 7. 1: Get On CPU Oracle Foreground Process Idle CPU Idle/sleeping
  • 8. 1: Get On CPU Idle/sleeping Idle OS receives interrupt: figures out which process to wake-up Scheduler needs to get this process on CPU CPU Oracle Foreground Process Application issues database call All work performed by OS and scheduler is reported as SYS cpu
  • 9. • Only one process can be on a core at a time (it’s either 1 or 0) • How quickly you can get on core depends on current utilization • Higher busy rate  higher chance of spending time on run-queue before getting scheduled • Less straightforward with multiple cores 1: Get On CPU CPU Utilization Chance of getting scheduled immediately 50% 1 in 2 66% 1 in 3 75% 1 in 4 80% 1 in 5 90% 1 in 10
  • 10. • Not only does it take longer to get on CPU, moreover: • Busy rate has measurable impact on DB-call response time • Which becomes noticeable when CPU has 60-65+% busy rate • This is in essence basic queueing theory, nothing new… Impact of CPU Utilization on Database Call ResponseTime
  • 11. Database Call ResponseTime, Single Core R = S / (1 – U) Random arrival Response time Service time Utilization% R – S = queue-time while resource is servicing others This is an exponential curve
  • 12. Every system starts queueing at some point, impacting response times This depends upon: • Arrival rate, service times, number of cores, and busy rate More ComplexWith Multiple Cores Response time Arrival rate Service times Number of cores CPU busy-rate On busy system, significant portion of this is queuing-time You never want database server to be running at full capacity all the time: stay well clear of 100% busy
  • 13. 2: Stay on CPU, not Go to SleepVoluntarily a Lot Ten database calls One database call Completed 10 calls 10Voluntary sleeps Scheduled 10 times 10 CPUThread Context Switches (more SYS cpu) CPU CPU Oracle Foreground Process Oracle Foreground Process Insert 10 rows  row-by-row Array-based or stored proc 
  • 14. 6 On 3 GHz core this is 0.33 ms This is about 3 µs This is where Oracle code spends most of its time Fetch by rowid takes 6-10 µs
  • 15. 2: Stay on CPU, not Go to SleepVoluntarily a Lot Oracle Foreground Process Oracle Foreground Process Ten database calls One database call Scheduled 10 times 10 Context Switches 10 Oracle kernel entries and exits 10 Operating system entries and exits CPU CPU
  • 16. Oracle Kernel Entry and Exit • Like a thread context switch, this too is measurable overhead If your calls are small and fast
  • 17. Oracle Kernel Entry and Exit • We measured this in a lab environment • In summary: • Simple batch process • Built in Java • Single threaded • Mix of single row selects, single row inserts and single row deletes • All issued (sequentially) over JDBC to database • Generating 9000 calls per second • Using “perf”, we profiled foreground process to see where CPU time is spent
  • 18. Visualizing CPU Usage With Flamegraph • Perf samples n times per second, the call-stack of your process’ execution thread • Flamegraph visualizes this
  • 19. Oracle Kernel Entry and Exit Here, third of USER cpu is per- call overhead
  • 20. How to SpotThis in AWR Report DB CPU >> sql execute elapsed time 10,000 seconds of USER cpu spent on entry/exit
  • 21. How to SpotThis in AWR Report Do not sum up to 100%, while we are cpu bound
  • 22. This Overhead Also on Application Servers! Every process has this overhead!
  • 23. Full Story Here • Youtube video: https://www.youtube.com/watch?v=8jiJDflpw4Y “Koppelaars database” Status sofar, • Process architectures have per call overheads: 1. OS interrupt figuring out which process to start (sys) 2. Scheduler doing its work (sys) 3. On-chip microcode execution to re-instantiate process state (sys) 4. Entering Oracle code (user)
  • 24. Oracle instance = Process based architecture: Foreground process is serving your database calls To perform efficiently: 1. process needs to get on CPU as quickly as possible Process needs to stay on CPU as long as possible: 2. process shouldn’t go to sleep voluntarily a lot 3. process should experience as few involuntary sleeps as possible Database Performance Core Principles
  • 25. 3: Stay on CPU, minimal Number of Involuntary Sleeps Too many processes OS scheduler de-schedules processes while they still have more CPU work to do = involuntary context switch (sleep)CPU Oracle Foreground Process Oracle Foreground Process Oracle Foreground Process DB call DB callDB call Three processes all want to insert 10 rows (array-based or stored procedure) Better to have one process insert 30 rows
  • 26. Impact ofToo Many Processes 0 2000 4000 6000 8000 10000 12000 14000 16000 4 8 12 16 20 24 28 1 Proc/Core 10 Proc/CoreAvg 50 Proc/CoreAvg # ofCPUs TX/s
  • 27. Database Performance Core Principles • Implications of Oracle’s Process Based Architecture • User ResponseTime,Throughput and DBTime Database Performance Core Principles
  • 28. • Actual duration is measure of performance quality (shorter = better) • Consistency of response time is an equally important measure of performance quality • Variance in response times will not delight your users User ResponseTime
  • 29. 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 ResponseTime Experienced by User Frequency X 1,000 Response time sec Multi-hump indicating response times with high variance Long tail Short tail Single distinct spike with majority of user experiences
  • 30. • Throughput is the number of units of work processed within a period of time • Throughput is not response time • As the system gets busier, throughput increases (good), but the response time for each individual unit of work will also increase (bad) • If you’ve witnessed throughput X at 40% busy, don’t expect throughput 2*X at 80% busy Throughput
  • 31. ResponseTimeVersus DBTime Network Network Database Server Application Server End User Total User Response Time DBTime Will be significant if not both in cloud
  • 32. • Response time • Throughput • DBTime Three different things Remember
  • 33. 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 ResponseTime Core Principle Frequency X 1,000,000 Response Time sec How to ensure this Instead of this Good Bad
  • 34. Network Network DatabaseApplication End User Total User Response Time Time Line Query Query Insert Delete Delete User Experience ResponseTime: Breakdown
  • 35. Network Network Database User Experience ResponseTime: Breakdown Application End User Total User Response Time Time Line Query Query Insert Delete Delete
  • 36. Again: %-Busy and Call Counts matter User Experience ResponseTime:Variance Breakdown of response time: Linear relation?
  • 37. How to prevent multi-hump response times Ensuring Single Spike Breakdown of response time: Actual relation! More calls  more queueing With increasing variance Smaller = More consistent, single spike, response times
  • 38. The Oracle database is a process based architecture To perform efficiently each process requires: 1. to get on CPU asap, and stay on CPU 2. to not go to sleep voluntarily a lot 3. to experience as few involuntary sleeps as possible Consistent response times require minimization of call counts across components (processes) DB Performance Core Principles: Summary You want to stay well clear of CPU’s being 100% busy Use architecture that requires small number of processes Better to call database with more work than to call with little work
  • 39. So, If We SeeThese…
  • 40. High number of voluntary sleeps per second High Call Counts per Second
  • 41. LittleWork per Call (Row-by-Row Processing) Not wanting to stay on CPU long
  • 42. High Process-to-Core Ratio + Busy System OS Scheduler doing what it does best: de-scheduling
  • 43. Despite lots of CPU being used, not much work is getting done  Majority of CPU time is spent on per-call overhead across all layers With high busy rates on database and application servers  Response times probably aren’t consistent We Pretty Much KnowThat
  • 44. LastTopic… • We stopped using database as a processing engine
  • 45. Conceptually 3 tiers • Exposed functionality - GUI's for human interaction - REST, or otherwise, for software interaction Internals • Business logic • Data store, relational database High Level Breakdown of OLTP Application User Interfaces Software Interfaces Business Logic Table Data Store
  • 46. Two Fundamentally Different Architectures DBMS = Persistence Layer "NoPlsql" Approach DBMS = Processing Engine "SmartDB" Approach
  • 47. You’ll Always See: Row-by-Row, SingleTable Approach Single-row data access Business logic Row fetching (data access) Business logic Row-by-row updating (data access) “if-then-else-loop” code PL/SQL here for convenience Primitive data access (single table, row-by-row)
  • 48. You’ll Never SeeThis: Set-Based SQL Decrease the discount percentage on all (still open) order lines, of a given high-risk order. Why not? Because persistence frameworks aren’t capable of generating this References >1 table Affects >1 row
  • 49. “Chatty” Applications When Business Logic Outside DB “Decrease discount percentages for high-risk order” SQL engine UI SQL SQL SQL SQL SQL High call counts between processes SQL SQL One set-based update, referencing multiple tables SQL engine UI SQL or SP-call
  • 50. Two Fundamentally Different Architectures Aka #SmartDB All business logic inside database Only UI outside database • One user experience = one database call, reducing voluntary sleeps • Negligible per-call overhead, as call involves substantial amount of work • Requires small number of FG-processes, reducing involuntary sleeps Database as Processing Engine Aka #NoPlsql All business logic outside database “Layered Software Architectures” • Many small calls to database leading to high rate of voluntary sleeps • Noticeable per-call overhead, as call is single row statement • Requires large number of FG-processes risking high rate of involuntary sleeps Database as Bit Bucket Youtube: “asktom connection pool”
  • 51. Every SQL statement submitted from application server • Requires OS entry • Requires OS scheduling • Requires CPU context switch • Requires Oracle kernel entry Before it arrives at SQL-engine Sum of these fixed CPU overheads is very real for row-by-row SQL! • Could be 2X CPU knock-on to SQL execution Implication ForYour Computing Resources Footprint
  • 52. Network Network Database Implication ForYour Footprint: Affects Application Server too Application End User Not just on database server: on application server as well Query Query Insert Delete Delete :Thread context switch
  • 53. Micro Services Architecture: Rife With Context Switches End User Check BalanceAudit Event Time Line: breakdown consists of many more components v v More components  risk of more variability
  • 54. Introduce ridiculous inefficient use of availableCPU resources Only way to improve this  move away from row-by-row processing This requires hand-written set-based SQL Implication of Moving Business Logic Out of DBMS We see database cores spending up to 60% of CPU-cycles on OS and CPU context-switches and getting in/out database kernel And application servers spending majority of time descending and ascending up JDBC and framework layers
  • 55. Want to Get an Idea of Inefficiency onYour Server? High Sys-to-User ratio is good indicator You’re not using DBMS as it was designed to be used
  • 56. How to ReduceYour Computing Resources Footprint? DBMS = Persistence Layer More busy DBMS = Processing Engine Less busy
  • 57. The #SmartDB gains of: • Massive reduction in call counts, greatly diminishes all aforementioned overheads per call • Outweigh additional work you bring into database by implementing your business logic inside SQL and PL/SQL Here IsThe, Counter Intuitive, Core Fact
  • 58. • Majority of current applications have large computing resources footprints • Why? Because they were built using layered software architectures and have all business logic execute on application servers • These architectures cause very high call counts across components (processes), and thereby they violate all database core performance principles In Summary
  • 59. • If you want to reduce your computing resources footprint  Don’t bring data to code, bring code to data, use smart SQL • Focus on minimizing chattiness, process context switches, call-counts, etc. • You’ll reduce both your database-server footprint, as well as your application-server footprints • And your user experiences will be consistent • Questions: emailToon.Koppelaars@oracle.com, twitter: @toonkoppelaars In Summary