Upgrading to Oracle Database 11g
This month’s question came to us from a customer:
“Should we upgrade our databases to 11g?”
Director of Managed Services Terry Sutton thoughtfully responds:
We are frequently asked this question. Oracle Corporation’s communications understandably promote using the latest version, and tout its new features. The answer to the question isn’t a simple one, and (like so much else in our world), “it depends.”
One of the traditional answers given by people in the Oracle community (outside of Oracle Corporation) is not to use the first release of any Oracle major version. There is some logic to this, but it oversimplifies. As pointed out by Tom Kyte, the major version first releases aren’t necessarily huge changes from the latest release of the previous version, and the second release may even have bigger changes from the first release than the first release had from the previous version. And, as Jonathan Lewis has pointed out, since Oracle 9, much behavior (including default settings for some important optimizer parameters and other optimizer behavior) can change significantly between smaller releases (such as 184.108.40.206 to 220.127.116.11).
Our preference is to offer a slight variation on the “no first release” rule. We try to avoid any major version or release upgrade until it has been publicly available for a year or two. The reasoning behind this view is that every Oracle version/release/patchset is going to have some bugs or unexpected issues, no matter how well Oracle has tested it. The bugs may or may not be showstoppers. But if you rush to upgrade your production database to the newest version, you get to be the company which discovers some of these bugs. If, however, you wait a while, more bugs are likely to be discovered by other users. Oracle Support learns about these bugs and creates bug fixes. By the time you come across the bug, it’s easy to find information on the bugs and issues, and there may already be a solution.
Another consideration is the concept of “if it ain’t broke, why fix it?” If your database is serving your application well now, and you don’t have need of the new features of 11g (which are described in Arup Nanda’s series on the Oracle Technology Network) then why rush to a new version? Or why move to a new version at all?
One reason to move to the new version would be because Oracle is desupporting the version you are on. Premier support for Oracle 10gR2 ends in July 2010, for 11gR1 in August 2012. Premier support generally ends five years after a release’s general availability date. So if 11gR2 is released late this year, it will have premium support until late 2014. Most companies do not want a version which has been desupported.
But even that is not a hard and fast rule. If your company is using a packaged application which has been working perfectly well for years, and which you are not making any changes to, you may not care about support. We have clients running quite happily on Oracle 8i or 9i. The database meets their needs and they’re not changing anything.
One factor that is critical in upgrading (as Tom Kyte says several times in the posting referenced above) is that you must test, test, test. And test some more. Before you even think of putting a new version into production you need to hammer on it, stress it, try to break it, in a test environment. You need to put loads greater than you’re likely to see in production, and you need to use all of the application code that is used in production. That is the only way to see if the new version is problematic. And this is a reason why some companies are slow to adopt a new version. Testing isn’t free. It consumes resources of personnel, hardware, and cash.
So our advice can be summarized as follows: Check to see if any of the new features of 11g will significantly help your application and if you have the appropriate license; some new features may only be available with Enterprise Edition or may be extra-cost options. If so, consider upgrading. If not, wait a while to upgrade (while keeping desupport dates in mind). And whatever you do, test, test, test.
I hope this answer helps you. Best of luck.