John Watson's blog
Excellent book - I've just posted this review on Amazon:
Another example of what I think of as "the self-tuning database". Setting optimizer_dynamic_sampling=11 can fix many performance problems, without the DBA needing to use his brain at all.
Excellent exposition of a very effective SQL tuning metodology
Following a question on OTN https://community.oracle.com/message/12801175 I did another test on redo and undo, just to prove that frequent COMMIT can be bad for performance. The results surprised me. I expected that row-by-row commit would be worse then a single commit at the end of a multi-row transaction, but I hadn't expected it to be this bad. As well as being much slower, both undo and redo volumes are vastly greater.
How much undo and redo does Oracle generate for different operations? More than you might think.
Buffer busy wait and related events can cripple performance of concurrent inserts. Bad in a single instance database, far worse in a RAC (think "gc buffer busy"). Often the problem is because of a primary key populated from a sequence. Reversing the index can fix this problem.
Concurrent inserts into a table will often result in crippling buffer busy wait problems as sessions serialize on access to the last block(s) of the table segment. Using hash clusters can remove the issue.
Many people are terrified of global indexes, one reason being that partition DDLs on the table will either render them unusable, or take forever as they are updated. Deferred global index maintenance solves this, and should be an important driver for the 12c upgrade.
Why use interpreted PL/SQL when native compiled PL/SQL is so much faster? No reason at all - except that interpreted is the default, and most DBAs never change this. They should.
Can this parameter really boost performance? This simple test suggests that it can.