I had a full session (300+ in attendance with 120 wait-listed). There was a gentleman from the organizing team who was trying to let in people flow in to the room as unobtrusively as possible. He was the same one for my other two sessions (which happend to be in the same room - full and and some 100+ wait listed) and he was visibly flustered to conduct the same routine. "You must be quite popular" - he exasperated! I took it as a compliment. For those who attended, thank you for taking the time to spend with me. I truly feel honored. For those who couldn't come in, I assume you have found some other helpful session.
Here is the abstract:
How do you decide which partitioning schemes to use, which column to partition on, or whether or not to use more than one column for partitioning keys? These are questions you must answer to develop a good strategy. Too many architects and DBAs choose a wrong strategy, making partitioning a failure. In this session, you will *not* learn the syntax or types of partitioning but how to decide the best strategy, presented through real-life case studies and examples. This session covers Oracle 11g features in partitioning.
If you haven't already done so from the Oracle Open World site, you can download here: http://www.proligence.com/OOW08_Part_ppt.pdf
By the way, I have also written an article on the same presentation, which you can find here: http://www.proligence.com/OOW08_Part_doc.pdf
Please leave your comments on these two documents. As always, thank you visiting and offering your feedback.
Confessions of an Oracle Database Junkie - Arup Nanda The opinions expressed here are mine and mine alone. They may not necessarily reflect that of my employers and customers - both past or present. The comments left by the reviewers are theirs alone and may not reflect my opinion whether implied or not. None of the advice is warranted to be free of errors and ommision. Please use at your own risk and after thorough testing in your environment.
Sunday, September 28, 2008
OOW'08 Partitioning - Why, When, What and How
Subscribe to: Post Comments (Atom)
Regarding "Reference" (Equi) partitioning. There is a trade off because you introduce extra I/O
Extra I/O, hmmm... why? Is it because the child record inserted will have to check the parent table to see which partition it belongs to? Yes, it will need to check; but it will need that check anyway, due to the foreign key constraint. So, why would there be an extra I/O? Same thing goes for deletes/updates as well.
sorry, you are correct. I mixed things up.
Post a Comment