This session was presented 2016-01-28 at Dallas Oracle User's Group January meeting.
How long does your code take to run? Is it changing? When it is slow, WHY is it slow? Is it your fault, or somebody else's? Can you prove it? How much faster could your code be? Do you know how to measure the performance of your code as user workloads and data volumes increase? These are fundamental questions about performance, but the vast majority of Oracle application developers can't answer them. The most popular performance tools available to them—and to the database administrators that run their code in production—are incapable of answering any of these questions. But the Oracle Database can give you exactly what you need to answer these questions and many more. You can know exactly where YOUR CODE is spending YOUR TIME. This session explains how.
How to find and fix your Oracle-based application performance problemCary Millsap
How long does your code take to run? Is it changing? When it is slow, WHY is it slow? Is it your fault, or somebody else's? Can you prove it? How much faster could your code be? Do you know how to measure the performance of your code as user workloads and data volumes increase? These are fundamental questions about performance, but the vast majority of Oracle application developers can't answer them. The most popular performance tools available to them—and to the database administrators that run their code in production—are incapable of answering any of these questions. But the Oracle Database can give you exactly what you need to answer these questions and many more. You can know exactly where YOUR CODE is spending YOUR TIME. This session explains how.
This was presented 2016-01-28 at the Dallas Oracle User's Group January meeting.
The Most Important Things You Should Know about Oracle®Cary Millsap
I've been around hundreds of Oracle performance projects since 1989, and my colleagues have been around thousands more. In candid after-work talks about our experiences, there has been remarkable symmetry in what we believe makes a project successful. People everywhere seem to be discovering the same secret on their own, through the Agile, Lean Startup, and Design Thinking movements. The secret? Shorter feedback loops. But shortening your feedback loops in Oracle projects is easier said than done. It all depends on how well you Test and Measure. But how do you overcome the political and technical barriers to making great testing and measuring a part of your project plan?
Partitioning on Oracle 12c - What changed on the most important Oracle featureLuis Marques
It was introduced in Oracle 8.0 in 1997 and since then Oracle Partitioning is mandatory for a big number Oracle Database architectures and implementations to ensure that high availabity or multi-terabyte systems keep the performance requirements.
This talk will demonstrate the improvements made in Oracle Partition on 12c from new interval reference partitions to partial partitioned and global async global indexes and how the today's critical Oracle databases that still run on 11g can revamp on this set of features.
Topic Objective: This topic is about Oracle Partition, the most used and most important paid option of Oracle Database. Learning how 12c improved it is vital for any Oracle DBA. Using this new set of new features can reduce your downtime, save DBA time and reduce the number of DBA "workarounds" to deal with specific situations when current 11g set of partition features is limited.
How to find and fix your Oracle application performance problemCary Millsap
How long does your code take to run? Is it changing? When it is slow, WHY is it slow? Is it your fault, or somebody else's? Can you prove it? How much faster could your code be? Do you know how to measure the performance of your code as user workloads and data volumes increase? These are fundamental questions about performance, but the vast majority of Oracle application developers can't answer them. The most popular performance tools available to them—and to the database administrators that run their code in production—are incapable of answering any of these questions. But the Oracle Database can give you exactly what you need to answer these questions and many more. You can know exactly where YOUR CODE is spending YOUR TIME. This session explains how.
“Performance” - Dallas Oracle Users Group 2019-01-29 presentationCary Millsap
In this session, Cary Millsap begins with a little bit of the theory behind why reducing call count is the most important goal of optimizing performance. Then he works through two examples where understanding the call count reduction idea is key to making progress. The first worked example is an intermittent performance problem that was frustratingly difficult to reproduce. The second worked example is a performance problem caused by an inefficiently-written application that overtaxes the system’s CPU.
How to find and fix your Oracle-based application performance problemCary Millsap
How long does your code take to run? Is it changing? When it is slow, WHY is it slow? Is it your fault, or somebody else's? Can you prove it? How much faster could your code be? Do you know how to measure the performance of your code as user workloads and data volumes increase? These are fundamental questions about performance, but the vast majority of Oracle application developers can't answer them. The most popular performance tools available to them—and to the database administrators that run their code in production—are incapable of answering any of these questions. But the Oracle Database can give you exactly what you need to answer these questions and many more. You can know exactly where YOUR CODE is spending YOUR TIME. This session explains how.
This was presented 2016-01-28 at the Dallas Oracle User's Group January meeting.
The Most Important Things You Should Know about Oracle®Cary Millsap
I've been around hundreds of Oracle performance projects since 1989, and my colleagues have been around thousands more. In candid after-work talks about our experiences, there has been remarkable symmetry in what we believe makes a project successful. People everywhere seem to be discovering the same secret on their own, through the Agile, Lean Startup, and Design Thinking movements. The secret? Shorter feedback loops. But shortening your feedback loops in Oracle projects is easier said than done. It all depends on how well you Test and Measure. But how do you overcome the political and technical barriers to making great testing and measuring a part of your project plan?
Partitioning on Oracle 12c - What changed on the most important Oracle featureLuis Marques
It was introduced in Oracle 8.0 in 1997 and since then Oracle Partitioning is mandatory for a big number Oracle Database architectures and implementations to ensure that high availabity or multi-terabyte systems keep the performance requirements.
This talk will demonstrate the improvements made in Oracle Partition on 12c from new interval reference partitions to partial partitioned and global async global indexes and how the today's critical Oracle databases that still run on 11g can revamp on this set of features.
Topic Objective: This topic is about Oracle Partition, the most used and most important paid option of Oracle Database. Learning how 12c improved it is vital for any Oracle DBA. Using this new set of new features can reduce your downtime, save DBA time and reduce the number of DBA "workarounds" to deal with specific situations when current 11g set of partition features is limited.
How to find and fix your Oracle application performance problemCary Millsap
How long does your code take to run? Is it changing? When it is slow, WHY is it slow? Is it your fault, or somebody else's? Can you prove it? How much faster could your code be? Do you know how to measure the performance of your code as user workloads and data volumes increase? These are fundamental questions about performance, but the vast majority of Oracle application developers can't answer them. The most popular performance tools available to them—and to the database administrators that run their code in production—are incapable of answering any of these questions. But the Oracle Database can give you exactly what you need to answer these questions and many more. You can know exactly where YOUR CODE is spending YOUR TIME. This session explains how.
“Performance” - Dallas Oracle Users Group 2019-01-29 presentationCary Millsap
In this session, Cary Millsap begins with a little bit of the theory behind why reducing call count is the most important goal of optimizing performance. Then he works through two examples where understanding the call count reduction idea is key to making progress. The first worked example is an intermittent performance problem that was frustratingly difficult to reproduce. The second worked example is a performance problem caused by an inefficiently-written application that overtaxes the system’s CPU.
Redefine Triage by Learning the Golden Nuggets of APM From Noted "APM Best Pr...CA Technologies
Increase your APM proficiency. Learn how you can identify and harness KPIs to make sense of your APM "big data." And find out how these techniques will help to prepare for your upgrade to the new features and functionality with latest APM release.
For more information on DevOps solutions from CA Technologies, please visit: http://bit.ly/1wbjjqX
The more we are connected and the more others are connected to us, the more important reliability of your sites becomes. Site Reliability Engineering is an engineering discipline devoted to helping an organization sustainably achieve the appropriate level of reliability in their systems, services, and products. But what does this mean, and how do get started with this? In this session I will talk about the concepts of Site Reliability Engineering and use Microsoft Azure to implement some of the concepts and practices
This presentation deals with the Performance testing implemented in the Project.
We have to use Certain Tools in the POC process.
1) VSTS
2) JMeter
finally, VSTS has been Implemented.
I hope this presentation helps the viewer to get the overview of the tools which Accenture Deals.
These are the slides form the Webinar titles "Packaging Recyclability Evaluation Portal (PREP) - An Introduction"
Go to prep.org.au for further information.
#NoEstimates is an exploration of what estimates and how agile and scrum teams use them in their daily practices. This talk helps teams discover new ways to forecast delivery.
Innovative Specifications for Better Performance Logging and MonitoringCary Millsap
Imagine a car with no speedometer. There are speed limit signs and policemen all around with radar guns waiting to catch you speeding, but you have no way of knowing how fast you're going. Of course, a car like this has no openable hood (no bonnet), so to change the air filter, you have to hire a specialist to saw into the body of your car. A car like this would be preposterous. Yet people write software like this all the time.
The Oracle Database has some of the best performance logging features built into it of any software in the world. You can use it with any application—even applications that were built without logging and monitoring in mind. But you can go SO much further if you bother to include some performance logging features in your application. In this session, I explain Oracle's extended SQL tracing feature and describe how to enable and disable it. Then I show some innovative ideas that will help you design and build database applications that are easier to monitor, manage, and maintain throughout the software development life cycle.
In this talk about performance for the 2018-01-25 Dallas Oracle Users Group meeting, Cary Millsap talks about application design, ways to control Oracle sql_trace, measurement intrusion, and function interposition.
More Related Content
Similar to How to find and fix your Oracle-based application performance problem
Redefine Triage by Learning the Golden Nuggets of APM From Noted "APM Best Pr...CA Technologies
Increase your APM proficiency. Learn how you can identify and harness KPIs to make sense of your APM "big data." And find out how these techniques will help to prepare for your upgrade to the new features and functionality with latest APM release.
For more information on DevOps solutions from CA Technologies, please visit: http://bit.ly/1wbjjqX
The more we are connected and the more others are connected to us, the more important reliability of your sites becomes. Site Reliability Engineering is an engineering discipline devoted to helping an organization sustainably achieve the appropriate level of reliability in their systems, services, and products. But what does this mean, and how do get started with this? In this session I will talk about the concepts of Site Reliability Engineering and use Microsoft Azure to implement some of the concepts and practices
This presentation deals with the Performance testing implemented in the Project.
We have to use Certain Tools in the POC process.
1) VSTS
2) JMeter
finally, VSTS has been Implemented.
I hope this presentation helps the viewer to get the overview of the tools which Accenture Deals.
These are the slides form the Webinar titles "Packaging Recyclability Evaluation Portal (PREP) - An Introduction"
Go to prep.org.au for further information.
#NoEstimates is an exploration of what estimates and how agile and scrum teams use them in their daily practices. This talk helps teams discover new ways to forecast delivery.
Innovative Specifications for Better Performance Logging and MonitoringCary Millsap
Imagine a car with no speedometer. There are speed limit signs and policemen all around with radar guns waiting to catch you speeding, but you have no way of knowing how fast you're going. Of course, a car like this has no openable hood (no bonnet), so to change the air filter, you have to hire a specialist to saw into the body of your car. A car like this would be preposterous. Yet people write software like this all the time.
The Oracle Database has some of the best performance logging features built into it of any software in the world. You can use it with any application—even applications that were built without logging and monitoring in mind. But you can go SO much further if you bother to include some performance logging features in your application. In this session, I explain Oracle's extended SQL tracing feature and describe how to enable and disable it. Then I show some innovative ideas that will help you design and build database applications that are easier to monitor, manage, and maintain throughout the software development life cycle.
In this talk about performance for the 2018-01-25 Dallas Oracle Users Group meeting, Cary Millsap talks about application design, ways to control Oracle sql_trace, measurement intrusion, and function interposition.
Oracle trace data collection errors: the story about oceans, islands, and riversCary Millsap
When you execute a business task on a computer system, you create an experience. The duration of this experience is called response time. The richest and easiest information about response time to obtain in the whole Oracle technology stack is available from the Oracle Database tier: Oracle's extended SQL trace data. But in almost 100% of first tries with using trace data, people make a data collection mistake that complicates their analysis. This is the story of that mistake.
Most important "trick" of performance instrumentationCary Millsap
This is the material from my 10-minute TED-style talk 2014-09-29 at OakTable World held in conjunction with Oracle OpenWorld 2014 in San Francisco. It explains the importance of assigning a unique id to the Oracle Database code path associated with each performance experience that users can have with your system
Among Oracle database administrators (DBAs), "Agile" is widely regarded as a dirty word, a synonym for "sloppy programming." But in the most commercially and technically successful projects I've ever worked on, the principles of the Agile Manifesto have defined our work (specifically, the implementation of the Agile Manifesto called Extreme Programming (XP), as explained by Kent Beck). In fact, further than that: the principles of Agile, implemented as XP, have profoundly enriched my entire life—not just professionally, but personally. The contradiction between the typical DBA's perception of "Agile" and my own is, thus, stunning.
This session describes my experiences with Agile values and our implementation of them. I describe the circumstances that have led me to believe passionately that it's XP that will best assure the success of my projects. I describe what has worked for me and why, and I describe what hasn't worked and why.
Diagnosability versus The Cloud, Redwood Shores 2011-08-30Cary Millsap
In our increasingly virtualized environments, it's ever more difficult to diagnose application defects—especially performance defects that affect response time or throughput expectations. Runtime diagnosis of defects can be an unbearably complicated problem to solve once the application is sealed up and put into production use. But having excellent runtime diagnostics is surprisingly easy if you design the diagnostic features into the application from its inception, as it is being grown, like you would with any other desired application feature.
Diagnosability versus The Cloud, Toronto 2011-04-21Cary Millsap
In our increasingly virtualized environments, it's ever more difficult to diagnose application defects—especially performance defects that affect response time or throughput expectations. Runtime diagnosis of defects can be an unbearably complicated problem to solve once the application is sealed up and put into production use. But having excellent runtime diagnostics is surprisingly easy if you design the diagnostic features into the application from its inception, as it is being grown, like you would with any other desired application feature.
Analysis insight about a Flyball dog competition team's performanceroli9797
Insight of my analysis about a Flyball dog competition team's last year performance. Find more: https://github.com/rolandnagy-ds/flyball_race_analysis/tree/main
Learn SQL from basic queries to Advance queriesmanishkhaire30
Dive into the world of data analysis with our comprehensive guide on mastering SQL! This presentation offers a practical approach to learning SQL, focusing on real-world applications and hands-on practice. Whether you're a beginner or looking to sharpen your skills, this guide provides the tools you need to extract, analyze, and interpret data effectively.
Key Highlights:
Foundations of SQL: Understand the basics of SQL, including data retrieval, filtering, and aggregation.
Advanced Queries: Learn to craft complex queries to uncover deep insights from your data.
Data Trends and Patterns: Discover how to identify and interpret trends and patterns in your datasets.
Practical Examples: Follow step-by-step examples to apply SQL techniques in real-world scenarios.
Actionable Insights: Gain the skills to derive actionable insights that drive informed decision-making.
Join us on this journey to enhance your data analysis capabilities and unlock the full potential of SQL. Perfect for data enthusiasts, analysts, and anyone eager to harness the power of data!
#DataAnalysis #SQL #LearningSQL #DataInsights #DataScience #Analytics
Levelwise PageRank with Loop-Based Dead End Handling Strategy : SHORT REPORT ...Subhajit Sahu
Abstract — Levelwise PageRank is an alternative method of PageRank computation which decomposes the input graph into a directed acyclic block-graph of strongly connected components, and processes them in topological order, one level at a time. This enables calculation for ranks in a distributed fashion without per-iteration communication, unlike the standard method where all vertices are processed in each iteration. It however comes with a precondition of the absence of dead ends in the input graph. Here, the native non-distributed performance of Levelwise PageRank was compared against Monolithic PageRank on a CPU as well as a GPU. To ensure a fair comparison, Monolithic PageRank was also performed on a graph where vertices were split by components. Results indicate that Levelwise PageRank is about as fast as Monolithic PageRank on the CPU, but quite a bit slower on the GPU. Slowdown on the GPU is likely caused by a large submission of small workloads, and expected to be non-issue when the computation is performed on massive graphs.
Techniques to optimize the pagerank algorithm usually fall in two categories. One is to try reducing the work per iteration, and the other is to try reducing the number of iterations. These goals are often at odds with one another. Skipping computation on vertices which have already converged has the potential to save iteration time. Skipping in-identical vertices, with the same in-links, helps reduce duplicate computations and thus could help reduce iteration time. Road networks often have chains which can be short-circuited before pagerank computation to improve performance. Final ranks of chain nodes can be easily calculated. This could reduce both the iteration time, and the number of iterations. If a graph has no dangling nodes, pagerank of each strongly connected component can be computed in topological order. This could help reduce the iteration time, no. of iterations, and also enable multi-iteration concurrency in pagerank computation. The combination of all of the above methods is the STICD algorithm. [sticd] For dynamic graphs, unchanged components whose ranks are unaffected can be skipped altogether.
06-04-2024 - NYC Tech Week - Discussion on Vector Databases, Unstructured Data and AI
Discussion on Vector Databases, Unstructured Data and AI
https://www.meetup.com/unstructured-data-meetup-new-york/
This meetup is for people working in unstructured data. Speakers will come present about related topics such as vector databases, LLMs, and managing data at scale. The intended audience of this group includes roles like machine learning engineers, data scientists, data engineers, software engineers, and PMs.This meetup was formerly Milvus Meetup, and is sponsored by Zilliz maintainers of Milvus.
06-04-2024 - NYC Tech Week - Discussion on Vector Databases, Unstructured Data and AI
Round table discussion of vector databases, unstructured data, ai, big data, real-time, robots and Milvus.
A lively discussion with NJ Gen AI Meetup Lead, Prasad and Procure.FYI's Co-Found
14. @CaryMillsap
has to finish quickly.”
click
button
link
row
query
report
job
}{“My
14
This is what performance is.
15. @CaryMillsap
has to finish quickly.”
click
button
link
row
query
report
job
}{“My
15
A performance problem is when it doesn’t.
16. @CaryMillsap 16
“How long does it take?”
Response time (R)
Duration from service request to
service fulfillment.
Sanjay Nancy Ken Jorge
R
t0
t1
R = t1 – t0
Two big questions...
1. How long did it take?
2. Why?
26. @CaryMillsap
EXADATAD A T A B A S E
ENTERPRISE EDITION
D A T A B A S E
STANDARD EDITION
D A T A B A S E
EXPRESS EDITION
Oracle extended SQL tracing
is a feature of every Oracle Database.
26
Oracle7 1992 Oracle8 1997 Oracle8i 2000 Oracle9i 2001 Oracle 10g 2004 Oracle 11g 2007 Oracle 12c 2013
40. @CaryMillsap
// JDBC 11g example
String metrics[] = new String[OraCxn.END_TO_END_STATE_INDEX_MAX];
metrics[END_TO_END_MODULE_INDEX] = "OE BOOK";
metrics[END_TO_END_ACTION_INDEX] = UUID.randomUUID().toString();
conn.setEndToEndMetrics(metrics, (short) 0);
// Your OE BOOK code
metrics[END_TO_END_MODULE_INDEX] = "";
metrics[END_TO_END_ACTION_INDEX] = "";
conn.setEndToEndMetrics(metrics, (short) 0);
40
Java ADF
To set your code’s module and action names...
41. @CaryMillsap
// JDBC 12c example
Properties p = new Properties();
p.put("OCSID.MODULE", "OE BOOK");
p.put("OCSID.ACTION", UUID.randomUUID().toString());
connection.setClientInfo(p);
// Your OE BOOK code
p.put("OCSID.MODULE", "");
p.put("OCSID.ACTION", "");
connection.setClientInfo(p);
41
Java ADF
To set your code’s module and action names...
64. @CaryMillsap 64
begin prepare
CPU
latch-related syscall
CPU
end prepare
begin exec
CPU
write(SQLNET_OUT, result_to_client);
end exec
read(SQLNET_IN, next_request_from_client);
begin fetch
CPU
latch-related syscall
CPU
write(SQLNET_OUT, result_to_client);
end fetch
read(SQLNET_IN, next_request_from_client);
begin fetch
CPU
write(SQLNET_OUT, result_to_client);
write(SQLNET_OUT, more_results);
write(SQLNET_OUT, more_results);
end fetch
read(SQLNET_IN, next_request_from_client);
begin fetch
CPU
write(SQLNET_OUT, result_to_client);
write(SQLNET_OUT, more_results);
write(SQLNET_OUT, more_results);
end fetch
read(SQLNET_IN, next_request_from_client);
begin fetch
CPU
write(SQLNET_OUT, result_to_client);
write(SQLNET_OUT, more_results);
write(SQLNET_OUT, more_results);
end fetch
read(SQLNET_IN, next_request_from_client);
Oracle kernel code path
This is the
kind of stuff
your code
causes the
Oracle kernel
to do.
65. @CaryMillsap 65
WAIT #42: nam='latch: library cache'…
PARSE #42:c=10000,…
WAIT #42: nam='SQL*Net message to client'…
EXEC #42:c=10000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='latch: cache buffers chains'…
WAIT #42: nam='SQL*Net message to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='SQL*Net message to client'…
WAIT #42: nam='SQL*Net more data to client'…
WAIT #42: nam='SQL*Net more data to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='SQL*Net message to client'…
WAIT #42: nam='SQL*Net more data to client'…
WAIT #42: nam='SQL*Net more data to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='SQL*Net message to client'…
WAIT #42: nam='SQL*Net more data to client'…
WAIT #42: nam='SQL*Net more data to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
Oracle extended SQL trace data
begin prepare
CPU
latch-related syscall
CPU
end prepare
begin exec
CPU
write(SQLNET_OUT, result_to_client);
end exec
read(SQLNET_IN, next_request_from_client);
begin fetch
CPU
latch-related syscall
CPU
write(SQLNET_OUT, result_to_client);
end fetch
read(SQLNET_IN, next_request_from_client);
begin fetch
CPU
write(SQLNET_OUT, result_to_client);
write(SQLNET_OUT, more_results);
write(SQLNET_OUT, more_results);
end fetch
read(SQLNET_IN, next_request_from_client);
begin fetch
CPU
write(SQLNET_OUT, result_to_client);
write(SQLNET_OUT, more_results);
write(SQLNET_OUT, more_results);
end fetch
read(SQLNET_IN, next_request_from_client);
begin fetch
CPU
write(SQLNET_OUT, result_to_client);
write(SQLNET_OUT, more_results);
write(SQLNET_OUT, more_results);
end fetch
read(SQLNET_IN, next_request_from_client);
Oracle kernel code path
This is the
kind of
trace data
the kernel
produces.
66. @CaryMillsap 66
WAIT #42: nam='latch: library cache'…
PARSE #42:c=10000,…
WAIT #42: nam='SQL*Net message to client'…
EXEC #42:c=10000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='latch: cache buffers chains'…
WAIT #42: nam='SQL*Net message to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='SQL*Net message to client'…
WAIT #42: nam='SQL*Net more data to client'…
WAIT #42: nam='SQL*Net more data to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='SQL*Net message to client'…
WAIT #42: nam='SQL*Net more data to client'…
WAIT #42: nam='SQL*Net more data to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='SQL*Net message to client'…
WAIT #42: nam='SQL*Net more data to client'…
WAIT #42: nam='SQL*Net more data to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
Oracle extended SQL trace data
Of course,
you don’t
directly get
to see the
kernel code
path.
67. @CaryMillsap 67
WAIT #42: nam='latch: library cache'…
PARSE #42:c=10000,…
WAIT #42: nam='SQL*Net message to client'…
EXEC #42:c=10000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='latch: cache buffers chains'…
WAIT #42: nam='SQL*Net message to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='SQL*Net message to client'…
WAIT #42: nam='SQL*Net more data to client'…
WAIT #42: nam='SQL*Net more data to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='SQL*Net message to client'…
WAIT #42: nam='SQL*Net more data to client'…
WAIT #42: nam='SQL*Net more data to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='SQL*Net message to client'…
WAIT #42: nam='SQL*Net more data to client'…
WAIT #42: nam='SQL*Net more data to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
Oracle extended SQL trace data
...Or that
helpful grid
that I drew
for you.
68. @CaryMillsap 68
WAIT #42: nam='latch: library cache'…
PARSE #42:c=10000,…
WAIT #42: nam='SQL*Net message to client'…
EXEC #42:c=10000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='latch: cache buffers chains'…
WAIT #42: nam='SQL*Net message to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='SQL*Net message to client'…
WAIT #42: nam='SQL*Net more data to client'…
WAIT #42: nam='SQL*Net more data to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='SQL*Net message to client'…
WAIT #42: nam='SQL*Net more data to client'…
WAIT #42: nam='SQL*Net more data to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='SQL*Net message to client'…
WAIT #42: nam='SQL*Net more data to client'…
WAIT #42: nam='SQL*Net more data to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
Oracle extended SQL trace data
All you
get to see
is this.
69. @CaryMillsap
WAIT #42: nam='latch: library cache'…
PARSE #42:c=10000,…
WAIT #42: nam='SQL*Net message to client'…
EXEC #42:c=10000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='latch: cache buffers chains'…
WAIT #42: nam='SQL*Net message to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='SQL*Net message to client'…
WAIT #42: nam='SQL*Net more data to client'…
WAIT #42: nam='SQL*Net more data to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='SQL*Net message to client'…
WAIT #42: nam='SQL*Net more data to client'…
WAIT #42: nam='SQL*Net more data to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
WAIT #42: nam='SQL*Net message to client'…
WAIT #42: nam='SQL*Net more data to client'…
WAIT #42: nam='SQL*Net more data to client'…
FETCH #42:c=20000,…
WAIT #42: nam='SQL*Net message from client'…
69
Oracle extended SQL trace dataOracle kernel code path
begin prepare
CPU
latch-related syscall
CPU
end prepare
begin exec
CPU
write(SQLNET_OUT, result_to_client);
end exec
read(SQLNET_IN, next_request_from_client);
begin fetch
CPU
latch-related syscall
CPU
write(SQLNET_OUT, result_to_client);
end fetch
read(SQLNET_IN, next_request_from_client);
begin fetch
CPU
write(SQLNET_OUT, result_to_client);
write(SQLNET_OUT, more_results);
write(SQLNET_OUT, more_results);
end fetch
read(SQLNET_IN, next_request_from_client);
begin fetch
CPU
write(SQLNET_OUT, result_to_client);
write(SQLNET_OUT, more_results);
write(SQLNET_OUT, more_results);
end fetch
read(SQLNET_IN, next_request_from_client);
begin fetch
CPU
write(SQLNET_OUT, result_to_client);
write(SQLNET_OUT, more_results);
write(SQLNET_OUT, more_results);
end fetch
read(SQLNET_IN, next_request_from_client);
You can learn
to envision the
kernel’s code
path that
motivated
your trace file.
86. @CaryMillsap
OPTIM
IZE ANYT
HING
M
eTH O D
R
You might have known that you should
“use bind variables,” but you couldn’t
have quantified the R impact on the
experience without this trace file.
86
88. @CaryMillsap
BASELINE: BAD
for each invoice number {
cursor = parse(“select ...where invoice_number = ” + number);
exec(cursor);
loop over the result set to fetch all the rows;
}
FIX 1 “Hey, let’s use bind variables”:
for each invoice number {
cursor = parse(“select ...where invoice_number = :a1”);
exec(cursor, number);
loop over the result set to fetch all the rows;
}
88
STILL BAD
A little better, but still really awful:
• Uses too much CPU for PARSE calls
• Serialization on library cache latches
• Maybe, too many network round-trips