Oracle Scratchpad

Public Appearances


7th/9th May 2019 Bonn, Germany: I’ll be delivering the closing Keynote at DOAG’s “APEX Connect” event with the title: “That’s not MY job”.

In principle there aren’t many things you have to get right to design, code and deliver an Oracle-based application that performs well at scale, but there’s one aspect of getting it right that is a constantly moving target – the data that’s going into the application. No matter how well you’ve done picking the relevant features, no matter how elegantly you’ve written your user-facing code, no matter how carefully you’ve designed your indexing strategy, you still need to ensure that the database engine “understands” the data otherwise you will find that over time the changes in the data content will result in the optimizer picking inappropriate execution plans and producing a huge but randomly varying load on your application.

So how do you make sure that Oracle understands the data, and whose job is it to help the Optimise understand the data? Mostly it’s about a question of statistics, and Oracle has built-in jobs that try to make sure the statistics are valid – but there are gaps and limitations to what the optimizer can do and someone has to fill the gaps. So where are the gaps, who fills them, and how?

12th June 2019 Glasgow, Scotland: I’ll be speaking at the OUG Scotland event, presenting “Struggles with Statistics” 

Struggling with statistics.

No matter how recently you collected the most accurate possible statistics that Oracle’s routines allow you to gather, there are still many cases where you can’t leave it all to Oracle to get the right execution plan. This presentation describes several of the errors and omissions in Oracle’s stats collection, tells you how to identify them, and suggests the best ways to work around them..

26th/27th Sept 2019 Zurich, Switzerland: It’s that time of year again, and I’ll be doing one or two presentations at Trivadis Performance Days.  The abstracts I’ve offered are:

Your probably don’t need to … read a 10053 trace

It’s almost true to say that the only time you should read a 10053 trace file is when you don’t need to. It’s also probably a fairly accurate claim that the only good reason for reading a 10053 trace file is to prove that you didn’t need to read the 10053 trace file.

In all my years of consulting and trouble-shooting I think I’ve only used the 10053 trace file a couple of times to demonstrate the cause of a performance issue and suggest a work-around – but having spent a silly amount of time generating and reviewing trace files for increasingly complicated statements I found it easy to pick the bit of the trace file I needed to examine to confirm a hypothesis and explain the evidence to management (and Oracle Support).

In this session I’ll be giving you plenty of reasons why you shouldn’t be reading a 10053 trace file – but we’ll probably end up looking at some bits of one anyway.

Problem Solving with Execution Plans

This session will examine a couple of execution plans that have appeared on the Oracle Developer Community database over the last year, explaining what information can be seen from the initial request for assistance, what further information might be needed, and what database considerations might come into play that are outside the immediate scope of the information available in a plan. There will be no Powerpoint slides in this presentation as the medium is not appropriate for displaying plans of a “real-world” level of complexity.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Comments and related questions are welcome.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Powered by