John Watson's blog
Submitted by John Watson on Sat, 2016-03-05 06:04
DB Time is the time spent by the database server executing user calls. What is this composed of? CPU time, waiting time, and IO time.
Submitted by John Watson on Sat, 2015-10-10 06:01
Proxy authentication has been around since release 9i, but it isn't widely used. It can be a very useful facility for giving certain users access to high privileges without having to give them any direct grants or roles, and avoids many of the problems of using shared accounts. It is of course fully audited.
Submitted by John Watson on Mon, 2015-09-07 10:46
Standard Edition release 188.8.131.52 is now available. Download it from the usual locations. But along with the great news, comes some news that is not so great: the licensing model has changed.
Submitted by John Watson on Sat, 2015-07-25 10:00
Following previous blog re BASIC compression, here are a couple of simple tests with Advanced Compression - which is supposed to survive conventional DML.
Submitted by John Watson on Thu, 2015-07-09 11:59
BASIC table compression is included with Enterprise edition, and can achieve respectable compression ratios. But beware! Subsequent DML may be disastrous.
Submitted by John Watson on Sat, 2015-04-25 13:56
The ability to quiesce the database was introduced in release 9, but to this day I find that many people are not aware of it. It can be really useful - so let's describe it. I'll begin by positioning the quiesce capability: when is it useful. Then detail how to do it, then reverse engineer the mechanism.
Submitted by John Watson on Wed, 2015-04-08 11:50
Excellent book - I've just posted this review on Amazon:
Submitted by John Watson on Sat, 2015-02-21 08:12
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.
Submitted by John Watson on Sun, 2015-02-08 07:48
Excellent exposition of a very effective SQL tuning metodology
Submitted by John Watson on Sun, 2015-01-18 08:59
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.