That was an absolute statement. Perhaps “The DBA’s I come across lack …..”
By saying in the manner you have, its unfair.

Consider this ….do you know that speeds of HDD matter a lot in latency and I/O.
If you do then good. However in the end what really matters is the absolute result.
Please allow me to give you an example.

Consider a 15K rpm HDD.
Now its obvious a 20K rpm would be faster. But then is it ?
Please do the maths and you shall agree to the below.
In order to shave off latency of just 1ms off a 15K rpm drive, the drive has to run at speed of 30K rpm. That’s twice for a measly 1ms.
And the technology is not advanced enough for that drive speed.

Absolute results matter. if 15K gives me what I want then 20K is really not up to it.
The time taken for a job or query is the best unit of judgement.

Basically I am trying so say :
A Performance Tuning DBA is knowledgeable of all aspects of the domain.
I would not generalise an absolute comment.

Thanks,
W.

Thanks for the comment and glad you have found the blog a good learning tool. That’s my intent ;)

Exadata is modular, scalable, intelligent storage for Oracle databases. I guess one could call it shared nothing but it is no more (or no less) shared nothing than any modular scalable non-Exadata storage. Exadata storage does not require Oracle RAC, it just happens to be paired with RAC in the Oracle Database Machine, but it can be used with any Linux host (RAC or not).

Point your browser to http://oracle.com/exadata and expand the right hand columns (Technical Information, Data Sheets & FAQ, etc.) for numerous papers.

Good blog and i have learned quite a few things over here. I have couple of questions. Is Exadata just Oracle RAC ? I think its not. Is it a shared nothing architecture ? Please guide me to some documentation.

Thanks
Krish

That’s exactly why that paper is listed in the Oracle Documentation References section! :)

There will always be times where tables need to be updated (e.g. SCD), however, with compression bulk update operations should be avoided. Updates 1) don’t mix well with compression and 2) are logging operations and thus slower than nologging inserts. IMO updatable facts are a symptom poor design (as you mention “sadly”) – events in the past don’t change, new events take place and should be appended to the table of events.

Sometimes what to the quick glance is an insert only table may in fact be updated – take slowly changing dimension tables where the “old” record needs to be closed off (updated) when a new record for the same dimensional key comes in. But the inventive mind can always come up with ways to get around that :-) – and without resorting to advanced compression.
Sadly, “updateable” facts are quite common – for example processes that run through multiple steps (e.g support calls changing states (open, call back, resolve, close)) or stock movement tracking, but again there are ways to avoid the need to locate and update, for example the 11g pivot operator can be used to rotate a sequence of state changes for a call_id, and this is surprisingly efficient – especially so if table design (indexing and partitioning for example) can minimise the blocks accessed to pivot the result set

Based on your questions it seems you do not understand how Oracle’s row major compression works. I would suggest you first read Table Compression in Oracle9i Release 2: A Performance Analysis and see if that answers your questions.