Don’t get me wrong, I have no doubt about the Exadata horsepower. I sat and watched the “Terabyte Hour” session at OpenWorld (OK it was a Exadata V1, but still very impressive). I completely agree that for most people, performance of the re-engineered app on their own kit is not comparible to the performance of the re-engineered app on Exadata. Indeed, some of the decisions on how you re-engineer the app may be affected by your kit, so there may be situations where it is sensible to re-engineer after moving to Exadata.

The point is, and you have already made it in your post, put a bad app on top great hardware and you are still left with a bad app. It seems like everyone knows this, but it gets conveniently ignored when making hardware purchasing decisions.

Cheers

Tim…

PS. If you have an Exadata V2 box going spare I could make use of it at home… :)

Instead of bulk UPDATES/DELETES, use set theory to create the compliment via CTAS (or similar). That is, for DELETE recreate what you want to keep, for UPDATE, recreate with the modifications.

There are a few reasons for this:
1) Compression – UPDATES/DELETES are more expensive with compression and they generally leave the data in a much less compressed format
2) Logging – Both UPDATE and DELETE are logging operations and a NOLOGGING CTAS or INSERT /*+ APPEND */ are not.

As a result, it is often faster and better (from a compression point of view) to recreate the segment.

The difference between SQL bulk updates/deletes and PL/SQL bulk collects is clear. The question is if you are recommending to avoid SQL bulk updates/deletes. If that’s the case, what do you recommend instead?

Is my response unclear? Bulk UPDATES and DELETES are just that — they have nothing to do with PL/SQL BULK COLLECT.

Question: Are you saying we should avoid bulk SQL updates and deletes, PL/SQL bulk collects, or both? If we do that, what else is there if not the dreaded row by row processing? Please clarify!

Also one of the reasons some developers do not use set based processing is that it requires combination of developer and DBA skills such as partition exchange loading, index handling etc. they are not familiar with. I think that tools like ODI can help a lot since they can enforce the use set based processing via the templates (knowledge modules in case of ODI).

Bulk updates and deletes using the UPDATE and DELETE SQL commands. Using BULK COLLECT in PL/SQL is a completely different topic.

Thank you
Kumar

I’m adding this to my book of quotes:

“I [Tim Hall] talk about improving PL/SQL performance by not using PL/SQL.”

Since you and the others think, and right fully so, that it may seem a bit extreme to pursue Exadata before considering re-engineering, but the rest of the picture hasn’t been filled in yet by me. You see, query performance is a big part of this as well, but as you probably know, if you have reasonable design and SQL, Oracle’s Parallel Execution (Query) engine takes over and evokes the massive parallelism behind the scenes — there’s really no way to code in slow to queries. This is a much different scenario than batch programs. In this case the current system could not even compare to the query performance they saw with Exadata. Some of the differences were so large I dare not mention them. ;)