I first came across partitioning with release 7, when it didn't exist. Like many DBAs, I simulated it by writing a lot of application code. You can still do this – and you may have to if you haven't bought Enterprise Edition plus the partitioning option. Here's another way to do it, with partitioned views.
The cost based optimizer makes decisions that can be hard to understand. One of the hardest may be why it chooses indexed or scan access paths: a burning question for many DBAs.
I would like to share something about ORACLE_SID registry parameter.
I had a chance to restore (RMAN) a database on a new Windows server. The restoration/recovery was completed and there was no issue in logging to the database from the server.
The only thing I had to do was to set the ORACLE_SID variable everytime using the statement "set ORACLE_SID=abcd". I will encounter the error "ORA-12560: TNS:protocol adapter error".
This was the only database running on the server.
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.
Following previous blog re BASIC compression, here are a couple of simple tests with Advanced Compression - which is supposed to survive conventional DML.
BASIC table compression is included with Enterprise edition, and can achieve respectable compression ratios. But beware! Subsequent DML may be disastrous.
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.
Excellent book - I've just posted this review on Amazon:
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.