Oracle query is slower the second time

Question

I have a general question about something I'm seeing in performance tuning in Oracle. I have a query that I'm testing. It's too big and complex for me to provide a simple example, sorry! (I tried lowering it down, but lost the symptom)

The first time I run the query, it's 2 seconds. Subsequent times it's 3, 4, or even 5 seconds. This happens consistently - if I change the spacing, I get 2 seconds again, then it goes back up.

This is the opposite of what I would expect - after the first time, the database doesn't need to parse the query, and blocks should be in read into the buffer cache. The only thing I can think of is that it is writing temp data somewhere, in such a way that it is faster to write and read it than it is to just read it. But that of course makes no sense.

Does anyone know why this is happening? Or any red flags in the execution plan that would cause something like this?

FYI, this is a SELECT, with multiple joins, aggregation, and views. No internal PL/SQL.

Thank you

Answer 1

Queries may produce different execution plans after the first run because of cardinality feedback. In 12c this feature was renamed statistics feedback.

The optimizer uses information about the actual and expected number of rows from the first run, and uses that information to improve the second execution plan. In my experience this is usually a good feature. But all optimizer features can backfire occasionally.

There are at least two ways to tell if cardinality feedback is used. There will be a note in the explain plan:

Note
-----
   - cardinality feedback used for this statement

Also the statement will show up in this query:

select * from v$sql_shared_cursor where use_feedback_stats = 'Y';

You may want to check both. When I tried to create an example the query had use_feedback_stats = 'Y' but did not have the Note in the explain plan.