Oracle has a well defined Support Policy (MoS note IDs 1351163.1) and shown below is the extract for the database.
When a product moves into Extended Support you need to be on the terminal release, so for 11.1 the terminal release is 11.1.0.7
My Oracle Support Note ID 742060.1 towards the end of 2011 appeared to introduce a new policy of a 12 month grace period on databases to move to a point release. However it is referred to in the Software Error Correction Support documnet v 2.6 Oct 2009, but this may be an amendment or not enforced.
The dilemma is this Oracle policy on Patch Set Updates (PSUs). Previously these were available for any release on Premier support.
So for 11.2.0.3 which was released in Sep 2011 , Oracle state that 11.2.0.2 will get the “full” error correction PSUs (quarterly Patch Set Updates) only till Sep 2012. To add to this, the clock ticks from the date of the first release, in the case I am looking at, it is an AIX platform and that release of 11.2.0.2 was 5 weeks after, reducing this grace period to 47 weeks. This is a very large customer with development projects with long time scales. By the time a release is stable enough to start a project on, the grace period is even less. No one wants to have a database upgrade during the development cycle.
This customer does not need the added functionality offered in 11.2 over 11.1, so feature benefits are not relevant in this debate, they simply want a stable and supported product to develop their critical systems on, and to move those applications that are in a technical refresh cycle.
So their dilemma is, if they use 11.2.02 which is the most up to date and stable platform, they must do at least one upgrade during the project which is not acceptable. The alternative is to use 11.1.0.7 which is also stable and as the terminal release of 11.1 will be supported until August 2015. However, the upgrade needed then from 11.1 to 11.2 is a much more complex upgrade because in reality it is a new install to enable the new functionality (which remember they don’t need).
In this case using an old version of software gives them better mid term support. But this is only today’s issue, this grace period means that with new point releases almost every year, customers will need to upgrade every 12 months to keep within this grace period.
Why has it taken over 2 years for this to come to light or become an issue? This may be because of document management of Software Error Correction Support 2.6 (see note above)or I suspect that because people have stayed still. Many customers have only moved to 11g in the last 12 months and therefore were already in Extended Support.
I intend to take this up with Oracle Support at the IOUC meeting at the end of January but would appreciate comments or corrections from anyone.
9 comments:
Hi Deb,
I used to have an opinion of "get a good stable release and stick with it", but I'm starting to move away from that position.
The database has become that complicated a product, that ultimately, you *will* encounter some problem. It might now be a show-stopper, or a cataclysmic, but it *will* harm either function or schedule.
Its been my experience, that no matter what the level of support (error, premier, extended, etc), the only means via you get *timely* and *quality* patches is to be on the most current release.
Many of the patches we had for 11.1 (0.6 and subsequently 0.7) either did not work, or introduced other regressions, or took months (years!) to be delivered.
As much I hate to say it, the reality for customers nowadays appears to be to get on the patch cycle and stay current - and somehow work that into the business process in as painless a way as possible.
I think you know what I am going to say but heh ho. This form of forced march is not fair on the customer. It might well be worth polling your users to discover where they are at in the cycle and whether others are facing the same dilemma. If there is a strong level of concern then it is worth taking further.
I disagree with Conor because in my experience, the latest release is rarely stable enough when considered against the whole of the environment. However, if you have a complex landscape that is wholly Oracle DB dependent then you may have no choice.
As always it's a case of making sure you do the sums and have all the testing tools you can get your hands on to understand the total risk exposure in both (or all) scenarios.
All the very best is figuring out the right answer.
I tend towards the "being on the latest version" camp. This is for several reasons:
(a) support, be it via metalink or Oracles internal techies, tends to be a lot better as they are more interested. (b) older features that you will tend to be using are more likely to have had more of the bugs ironed out. (c) if you do hit bugs, any fixes are likely to arrive for the latest version first, rather than having to wait for a backport to an older version (and then see it wiped out by the next patch upgrade) (d) once you are stable and the system is reliable, you have a longer timefram before you are forced to upgrade.
The drawbacks are that you might be tempted to use a new feature and the chances are there will be bugs and there is less knowledge about the odditities of your version - such as what features have changed from being off by default to on by default.
What I think is probably more important is aiming for an environment where you have the regression testing capability, attitude and system setup where you can test patches efficiently. Patching and upgrading are always going to be required, it is the pain of the testing that tends to hold it back.
Rather than spending effort deciding which version to nail your flag to, spend it trying to move towards a better regression testing environment?
I'm with Connor.
Hello Debra,
I don't find theMoS note IDs 1351163 in MOS. Can you send it to me.
Best regards
Christian
Sorry Christian, it should have said doc id 1351163.1, I have amended blog and checked in MOS, it is there
Martin has picked up this for one of his Friday blogs, well worth reading about the more people side of this debate http://mwidlake.wordpress.com/2012/01/20/friday-philosophy-lead-or-lag-when-to-upgrade/
The staying on the latest point release effectively gives customers less than 24 months before having to apply the next point release. This will in reality be less than 18 months, considering the release date for non-Oracle platforms, engineering the software stack and testing it before intercepting in production systems. Let's not forget the PSUs (the main thing in question with the error correction) need to be applied on top, every quarter anyway.
For SMBs and agile enterprises, this might not be an issue; but for large enterprises which need a robust point release around which to engineer the rest of the software stack (before using the stack, for a few years, when the db AND other important software in this stack are fully supported and fit-for-purpose), this constant upgrade every 12 months of the "entire" estate just to stay on the path of error correction via the PSUs is impractical.
The very extent of regression testing and due diligence applied by large complex enterprises to point releases, due to the change in functionality and software behaviour, makes this constant testing not just expensive but almost impossible as well! One of our customers has version migrations and upgrades of those systems that are falling off the mainstream and extended support cycle, every 6 months. During this enterprise upgrade/migration, the PSUs are also applied to the rest of the DBs in the estate, with good regression testing applied for PSUs but a lot more exhaustive for the upgrades/migrations. This is a huge enterprise where once a business system is refreshed it is likely to remain on that point release for another 3 - 5 years, with only the PSUs that they'd receive every 6 months; or patched up to the terminal release in that version. Hence, the attractiveness of 11.1.0.7 and 11.2.0.4, for this customer (assuming 11.2.0.4 is the terminal one); as opposed to any other intermidiate ones. Even if these terminal releases have bugs that need fixing, the PSUs will cover them. In other words, there is room for manouvere whilst on a terminal release with PSUs issued every quarter, as long it is in support (mainstream and extended). This avoids expensive and risky 12-monthly upgrades of mission and business critical systems. Let's not forget all this would still be the tail wagging the dog (or the Technology leading the Business) rather than the other way around; but that's for another day.
I am on a massive and complex project where the 'path to live' is approx 2 years. The uptime is 99.999% and zero data loss guarantee. The cost of testing a single patchset is eye watering. We have a policy of not patching unless there is a overriding security concern. This is why we are still on an old (non terminal release). We have not hit a 'new' bug for years and the system continues to be very stable. There is little risk in sticking to a tried and tested configuration. Dave F
Post a Comment