Moving on
July 14th, 2007 by Peter Scott
Doug Burns once said to me (and I am sure I am making up his words here, but the sentiment is probably right) that data warehouse folks are always using the latest features on the latest releases of databases. It is true that we do use less common, newer features, we are early adopters but to say we always use the latest releases is perhaps going a tiny bit too far.
Now that the next release of Oracle is just about to hit the streets, one of my DW customers is about to make the move to 10gR2 from 9.2. I have a feeling that the upgrade to his production system will happen the day before the Solaris version of 11 comes out. I have been pushing the customer towards this release since Oracle 10gR2 first came out, but the database upgrade had to sit at the end of queue of other interdependent upgrades. At last our time has come, and we can commence work on upgrading the test system. The upgrade itself is trivial, the step that takes time is running through all of the tests of the ETL processes, representative user queries and the like to prove that nothing is broken, and to find the differences in how things work; we expect that some queries will improve, but others will degrade in performance. Our testing is to show us what we need to do implement the upgrade on the day with the minimum of downtime and to make sure we get no unpleasant surprises.
July 15th, 2007 at 7:41 am
“upgrade itself is trivial, the step that takes time is running through all of the tests of the ETL processes, representative user queries and the like to prove that nothing is broken, and to find the differences in how things work”
Pete: this is the main, single and most oustanding reason I have been complaining to Oracle about their quarterly patches and some of the cumulative and point release upgrades.
Their folks just don’t realize that it’s got NOTHING to do with reluctance of dbas to do the actual upgrade, but you listen to them and it’s as if it’s the dbas that are causing the problems!
And quite frankly: I’ve seen nothing in the new 11g that will help with this. No, the workload thing completely sidetracks the issue.
It’s not the overall performance of the database that is the problem! It’s the instability of new releases of the optimizer and SQL engine that causes odd performance blowout problems or just plain bad results from SQL.
These must be tested for, one by one, exaustively, for every single new patch and point release! And that costs a LOT of moolah and time, as you note and I’ve been meowing about for years!
July 16th, 2007 at 9:13 pm
Dammit, I’m sick of seeing blog subjects I’m *about* to cover appearing elsewhere! I suppose we all suffer the same painful issues.
Oh, well, patching is still in my queue …