So, here I am, 3 months into the job after leaving the big O (thats “Oracle” sshhhh) and now my feet are at least a little under the table I guess it’s about time I started getting through my blogging duties!
So the next question was where to start? There is so much going off with Oracle; Exadata, the acquisition of Sun, and 11g Enterprise Manager to name just a few of the things I’ll be discussing in future posts, but for now I wanted to re-visit an old favourite… Oracle 11g, or more precisely the upgrade cycle! I’m going to start this blog by discussing 11g and why to upgrade in some high level terms, and over the next few weeks I’ll post additional entries focusing on specific new features in both the 11g and newer 11gR2 release.
We’ve just run an event in Scotland for a large number of customers, and it wasn’t that surprising to see how many are still running old versions (although for once Oracle 7.3.4 only featured once). I can understand customers being locked in to older versions where a vendor refuses to support a new release, but what does surprise me though is the attitude of “if it ain’t broke, don’t fix it” that seems to persist.
Newer releases of Oracle, especially 11g, have so many new features that it’s hard to understand why organisations don’t want to take advantage of them. Perhaps some folks out there like working on versions that don’t allow them to automate (or often remove the need for) the repetitive, often boring, manual tasks, or requires downtime for operations that in later releases no outage is necessary? Perhaps it’s having a version of the database that consumes more CPU and other resources to do the same job, resulting in more servers being required and the cost associated? Or maybe it’s having a version of the database that isn’t as secure, and if it’s de-supported doesn’t received the quarterly security updates? Ok, so I’m being glib, but hopefully you see my point.
One thing I think that perhaps hasn’t helped the situation is a lot of the marketing material which states with each release the database becomes more and more self managing. I can see how some DBAs, and other Sysadmins, might be wary, perhaps even fearful, of this. After all if it’s automating what I currently do how can it be good for my job prospects? I think this is a fallacy though, because if you take the time to look at what is being automated it is virtually always the stuff that I found a bind anyway. It’s the statistics gathering tasks, it’s the partition maintenance tasks, it’s the segment management tasks etc. With these tasks taken away and automated I can get on with the stuff that I value more, and so does the business, such as tuning (you can never run stuff fast enough in most peoples eyes), creating new systems, performing migration to cheaper, faster more energy efficient platforms etc.
It’s not about laying people off, it’s about taking us techies and making us into pro-active resources and not just people who fight fires, after all no one thanks you for keeping the lights on (but they will such as heck beat you up if they go off), but they do thank you if the overnight batch runs in half the time, and that’s where upgrades come in.
By upgrading to 11gR2 you get the latest features, you get the automation and the performance improvements, you stay current and get the latest security patches (more security in a later entry), plus having done a migration or two, and shown value to the organisation looks great on the CV!
But what about the risks? Upgrades have always been problematic, right? We know all about how the optimizer changes, and we’ve all seen presentations that talk about the SQL statement that came out of left field after an upgrade and caused the system to run like the proverbial dog. Well 11g, and even more so with 11gR2, has some really cool technologies to help resolve this, and the work we’ve done with our customers who’ve taken the leap and gone to 11g really backs this up. There are automated testing tools such as Real Application Testing, that can do up to 100% regression testing for us, and what’s more put this back in our hands as database people rather than have us rely on test teams to perform incomplete, often half hearted testing. There is also some stuff in the database itself such as SQL Plan Management that help us migrate with confidence… and that’s what I’ll be writing about in my next entry very shortly.
By the way… if you are looking at 11g why not attend one of the e-DBA 11g upgrade readiness workshops that we’re running around the country? If you’re interested drop one of my colleagues an email at events@e-dba.com.
