You say: "You'll have as many issues going to 10gr2 as you would 11gr1".

Maybe, maybe not. Many DBAs would argue that the second major release is very much more stable and bug free than the initial release of a version. This has certainly been the case with 7,8,9,10 - you know it has.


I agree that before you upgrade your production system to a new release you should test the upgrade, then test the system for performance, function, load test, stress test, test everything as much as you can. But the reality is that however much you test, things that you didn't expect WILL happen once you have gone live. So, given that initial releases are always less stable and more buggy than second releases, it may be safer to go to 10gR2 than 11gR1.
It is only after rolling a release out into the world at large that the unexpected problems start occurring and there is the inevitable need for second releases. It has always happened in the past - no reason to think that 11g will be any different.

But still it may not be a wise thing to go to the first minor release of any major release

It may be a good idea to wait for a few months till that major release gets *more stable* thro' subsequent minor releases

10gR2 introduced new features. It could of easily been called 11g. Look at Apple. They have released how many different versions of OSX? They like the 10 so they just go from 10.4 to 10.5. It's billed as a brand new release but they way they do the versioning gives the impression that it's more stable.

Do you remember Oracle version 1.0? : )

There was no Oracle 1.0 release. Oracle went straight to v2, to make a impression that it wasn't a new product.

For test, I would evaluate 10gR2 if I do not plan to use any of 11g new features in my app. If I do, I'd better test on both 10gR2 and 11g to plan future upgrade seamlessly.
For prod, I'd better await 10.2.0.4 (2500+ bugs planned to fix!) and/or 11.1.0.7, then test with 10-20 users comparing statspacks,AWR to old values, then plan upgrade.

You say "Initial releases are *not* less stable - with that I very much disagree."

Maybe we aren't talking about exactly the same things, so I will share my observations.
I'm sure you'll agree, that for a DBA running a production system, database stability is of paramount importance, both for the company whose business relies upon it, and for the DBA, so that he or she can sleep easily and not expect to be woken up in the middle of the night to fix some problem or other, or restart a crashed database.
Do you agree with that, Tom? - you're a well-respected Oracle expert.
I've been around in the production DBA world for a bit myself - I know what it's like to keep airline reservation systems, nuclear installations, online banking systems, internet gaming systems up and running, around the clock. I know that the number one thing that companies want from their databases is for them to be there - up and running. (And the number one thing for the DBA is to keep the databases up and running and be sure that the databases are properly backed up and that he or she has the ability to recover them if necessary.)
I remember Oracle 6, just about, although it's all a bit hazy now. But I remember well that Oracle 7.3 was a far more reliable and stable database than 7.0, and Oracle 8.1.7 was more stable than 8.1.5 (we'll gloss over 8.0). 9.2 was more stable than 9.0 and 10.2 is more stable than 10.1. I have no experience yet, of 11g.
There's nothing surprising about any of this; it's simply what I have observed over many years of database administration. If your personal observations over the years bring you to a different conclusion, well, I would be surprised, that's all. Many brand new things are less reliable at first. RAC is another good example - it is a brilliant product now, but in the early days it was very wobbly.
It would be interesting to conduct a survey of DBAs - those who have been around for a while - to see what the majority opinion is on the stability of 7.0 compared to 7.3, 8.1.5 to 8.1.7 etc. I know what I would put my money on if I was betting on the outcome...

"9iR1 and 10gr1 were as well - they were just rapidly superseded by r2's."

Why rapidly superseded? Marketing strategy? I think not.

"Seriously - what if we never had a "major release" again - but we have 11gr42, 11gr43 and so on..."

Then 11gr43 *should* be better, more stable than 11gr42 and so on. Or is the name just marketing? Again, I think not.

I agree with much of what you say, but I think that some of your argument is a little flawed, and also that you are misinterpreting slightly, what I am saying. Maybe it was lack of clarity on my part.

You say, "I just wish we'd stop the major releases and just have 11g release 42 in the future. It would end the discussion.", and also "I'm saying for overall stability - take a system running on version X (where X < 9ir2) and upgrade the database (don't change the application, don't change 5,000 other things, just upgrade the database) - and do the test."
Well, here is where I think your argument is flawed. We have major versions (and by that I mean 7, 8.0, 8i, 9i, 10g and so on) because we are introducing major new functions - we are "changing 5,000 things", right at the heart of the Oracle rdbms, and it is when we make such major changes that we are most likely to run into problems - it's commonsense. Your point about everyone skipping testing applies equally to the developers and designers and testers of the Oracle database - they are no different from the rest of us. So a major version, by the very nature of the scope of the changes is almost bound to be more problematic than the interim versions where things are tweaked and fixed and fine-tuned. Going from 11g1 through to 11g release 42, or whatever, would be simple, but it would blur those obvious distinctions that we have between each "major" release and it would make it appear more as though the release process is a steady stream of changes that are all much of a muchness. There IS something in a name. When we say 8i, we are putting a stake in the ground and saying at this point there is a major change, we put x new features into our database and it is a markedly different thing from what went before. Before 9i comes out we will refine, and tune, and stabilize 8i - 8.1.7 won't look hugely different from 8.1.5, but it will be a more solid thing. And then somewhere down the line we will introduce 9i, with another 5,000 new things (which we will tell you have been tested, but the testing won't have been as thorough as it might have been, because we all know that it never is).

You say, "We used the major releases internally to run our systems before you run yours on them." Well of course you do - your customers would expect nothing less. But the real test of something like the Oracle database is when it is released into the big outside world. When Oracle are happy that a release is sufficiently robust to give to its customers does that mean that problems and bugs won't appear any more? Of course not, and that is because Oracle could not have been expected to test every eventuality and every scenario.

You say, "Was 7.3.0 more or less 'stable' than 7.0.16 - depends on what you were doing, honest, depends on what you were doing." I agree; of course it depends. But overall, 7.3 is a better thing than 7.0. Take 500 applications that ran on both (applications that didn't change - they just ran the same applications on both version), and see whether the 7.0 databases were as reliable as the 7.3.

I said that you misinterpret slightly what I am saying. What I mean by that is this: you say, "10.1 - more or less 'stable' then 9ir2?", and also "for you see - using your method, N+1 is always better than N, therefore you should never upgrade because the better release is always coming."
I DO think that the terminal release of a version tends to be more stable than the first release of the next version. I do not think that "N+1 is always better than N, therefore you should never upgrade because the better release is always coming."
You care not a whit for opinion? Well, I think that opinions are very valuable; it depends upon how you treat them and whose opinion it is. Is that person in a good position to give an opinion on a particular topic? We all have opinions, and like you my opinion on Oracle is based partly upon my observations.
My observations were that 7.3.4 was more stable than 8.0.
And 8.1.7 was more stable than 9.0. No doubt about it - in my opinion. One of the things I like about your site is how you always make your points by example and demonstration - you don't just make assumptions, and say well this is probably what will happen. You actually demonstrate what happens - where you can. But not everything is demonstrable and that's where it is wise to take people's opinion into account. You shouldn't be too dismissive of opinion if it is based on years of experience and observation. We don't have the time to record everything we do and observe, but over the years we build up a store of knowledge based on what have done and seen, and we call on that store to help shape our opinion, and to help us make decisions. If I say to you that I'm going on a trip to New York, and I'd like your opinion on a good restaurant to visit - your opinion may or may not be of value to me. But if I am your employer and I employ you as my head DBA and I say to you, "I've heard that we should upgrade our live database from 8.1.7 to 9.0, can I have your opinion on that?", well then your opinion is probably the single most important thing that will affect my decision - I have trust in your opinion on Oracle matters - that's why I employed you."

So do we upgrade to 11gR1 or 10gR2? - it's all a matter of opinion.

Anyway, that's enough for now; Merry Christmas to you, Tom. It's almost upon us and it's time for me to go and dig some carrots for Santa's reindeer.

Tom said: What is in a name.... I always wondered why Sybase for example went from version 4 to..... System 10 way back when.

Way back then, I was working on a Sybase project when the version changed so dramatically - we were told that it was so that Sybase's version number was much "bigger" than Oracle's, so it sounded like Sybase was ahead technically. Brochure-ware at it's best! We were also getting 2-3 Sybase engines with different fixes delivered daily for us to try out. They'd fix a problem that we'd reported, then something that had worked before, stopped working. We'd call, and they'd say "Oh yeah, there was something that I wanted you to test for us" :-)

Merry Christmas to all! Unless you prefer something different ...

Here is my take¿.

Most of Oracle R2 releases are more stable than N+1 R1 releases if you don¿t care about new features.

When you plan for any new version 9/10/11 etc., you will add lot of new features along with fixing existing bugs. Those new features will add new problems to the database.

Do you think Oracle testers can test all possible tests by simulating each and every real world database? Why do they fix 1000¿s of bugs in patches if they can identify all the bugs in their R1 tests? So, they conduct as many tests as they can and release a new feature (in R1) once they are satisfied with it. It is really tested in the real world once the users started using that feature¿.then they send the bugs back to Oracle¿there you will have minor and next major patches¿ That¿s why I feel R2 is more stable than R1. Of course N+1 R1 is better for a new feature that was added in Release N R1 as they use same code base and fix any new major bugs as they don¿t have time to fix them in Release N R2. BUT, you do add more features in that N+1 R1 and you will have lot more bugs due to these new features¿.so, if you put more weight on Stability (less weight on new features) then R2 is always better¿that is just my Opinion.

You can do all the possible testing, still there is a huge chance to miss some of the cases and they will appear only on Production. At least I have 2 ORA problems and they only happen in Production, we contacted support and they have no solution except upgrading it to next major release. We tried 3 months to reproduce that in our test environment and there is no luck.

Of course, I do test thoroughly before upgrading the database. It is not sufficient sometimes. That is the reason for asking suggestions from Industry exports. I don¿t just jump blindly with the suggestions¿.they give more confidence during the process as these people are exposed to various environments and better to gather the knowledge from them.

I don¿t have firsthand experience between 9iR2 vs 10gR1¿¿Do you have some results? What is your take on that? Which one is more stable? If you had to upgrade from Oracle 8 when Oracle released 10gR1 (let¿s say its 1-2 months old)¿if you are not worried with new 10gR1 features¿.would you go to 10gR1 if both tests (9i and 10g) don¿t show any breakdowns in the database?

From my experience, if you are upgrading from say 8i and contemplating which version to move to, i.e. 9i, 10g, or 11g, as Tom said, you simply test and whichever has the best pass mark, go with that version. I don't think it matters much beyond that (I'm assuming there are no version specific features which you need now or in the near term) since any version is going to have it's share of issues which didn't show up in your testing.

However, what I don't think anyone has mentioned is licensing. 9i is already desupported unless you have purchased extended or lifetime support. Including this factor, that now limits your choices to either 10g (supported until 2008 or 2009 I think), or 11g.

I moved on from dba/developer to JAVA and I can see why people don't like stored procs. They are seriously slow and data can't be cached without reading after execution.

hahaha.

thank you, you've opened my Eyes! I trashed all my java and moving back to oracle, I don't want to be stupid! ;)

Will I be stupid if I don't go to Oracle Education ?

Please Tom, why don't you just implement your fair warning and just delete those stupid follow-ups about "stored procs" or whatever from a real interesting thread ?

Someone once said: "Oracle software is like wine, it gets better when it ages".

One thing to consider when making upgrade decision in PRODUCTION environments is how much other use there has been for that version. Are You going to be among the first users ? If (and I said if) problems occur, has someone else already dealt with it and there might be a solution/workaround easily available in metalink.

However one should remember that if everybody would live according this method, then there would not be any progress.

We hit a bug in 10.2 that did not exist in 10.1. The 10.2 bug returned an incomplete result set (ex: 10 rows returned instead of 20). This SQL did not use any new features in 10.2.

Tom's original answer is the right answer - TEST. Test until it hurts and then test more.

The other factor to consider when upgrading is looking at the entire software stack and making sure it is certified on 10g/11g. The OS, the middleware, backup software, etc.

Tom is an Oracle man and much as I enjoy his astounding knowledge and his website, there is always going to be some bias. Tom is not exactly going to say, don't go to 11g, because it's a load of garbage, is he now?

Of course people can test and teat and test, but many sites don't have the resource to do Oracle's testing for them. Sure there will be a migration plan and strategy, and sure there will be some testing. But that testing won't be infinite.

I would think that few business critical systems will be going to Oracle 11g, first release, any time soon. A major release always has by definition more new functionality, and therefore more potential for bugs.

I would truly think that few IT managers are going to risk their careers by suggesting a move now to 11g, without some really compelling business case, before 11g beds down.

Making decisions of software upgrades is not easy. Some things to consider

- are there new features, corrections, performance enhancements that You might benefit. Is someone willing to
make those changes that application would benefit from new features. If application is developed, should it use newest major version, so that there wouldn't be so fast need to do version upgrade.
- making major upgrades is expensive (someone here has already mentioned testing). Then it might be cost effective to leap over some major version.
- does current version prevent usage of new hardware, are there some limitations with operating systems, tools, third party application software. Some application vendors do not test their software against first versions of majors database releases.
Some require specific versions.

I think it is fear that keeps management away from release 1 of anything. And in my opinion the same management will have just as many problems during release 2. Appropriate testing is the core of competency. When appropriate testing is not done, does it matter what release it is?

The "first release is unreliable" mindset goes way back before Oracle. Stop and think about car discussions you've had. How many times have you been told (or told others) not to buy the first year of a new model?

The problem comes with the expectation that a version number indicates a "new model" while the revisions indicate service releases. I think what Tom's trying ever-so-gently to tell us is that hasn't been true for a while now.

Here is a real world example where the first revision of the latest product was not ready for production.

Vista. The first release of this could barely render the screen.

This is not an attribute of software that is isolated to Oracle. Any vendor or project will suffer from instability when new features are added. It is an unavoidable facet of a development life cycle.

Your point is well taken. Whatever version a team chooses that team better do extensive testing otherwise they are setting themselves up for failure. On the other hand, I doubt that team can be guaranteed they can utilize the new version without some new feature being enabled. That fact alone implies N+1 R1 will be less stable than N R100.

"but 10gr2 has as many new features over 10gr1 as 11gr1 did over 10gr2..."

Which implies 11gr1 has twice as many new features over 9i than 10gr1. Doesn't that increase the possibility that it is inherently less stable than 10gr1? Besides some or a bulk of 10gr2 must have been bug fixes for 10gr1. If not isn't Oracle's naming convention doing a disservice to its customer base?

From Oracle documentation:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/dba.htm#sthref94
"Major Database Release Number
The first digit is the most general identifier. It represents a major new version of the software that contains significant new functionality.

Database Maintenance Release Number
The second digit represents a maintenance release level. Some new features may also be included."

No need for a follow-up Tom. It is clear now that Oracle will jeopardize its customers in any fashion it feels necessary. By your own admonitions Oracle will put as many new features into any "binary" it wants to regardless of what the documentation states.

I would upgrade to 11g ... Per Oracle docs, it reduces the real world TESTING by greater magnitude via Database Replay, et al.( I hope to get an opportunity to use this feature very soon) .

Every version of the software has own share of features / bugs ,... Is that why we have Support Services , user forums , so on and so forth ?

When I pay for a software , I would (like to ) use to the fullest extent and squeeze to its last drop .

Tom:

1. Can we upgrade the database from 9i directly to 11g. would there be any issues? Any links for how to migrate.

2. I assume you set up an 11g test box and then export the 9i web application/database to the 11g and test it.

Do you have an idea on how long it would take to test a 50 web page mod_plsql application? any idea on how to estimate.

Tom:

to upgrade from 9 to 11g do you do a news install for 11g and then export/import teh DB or you apply an upgrade script on the existing 9i server.

Do you have a link on how to upgrade.

Tom:

This what i am trying to find. is this the correct link

http://download.oracle.com/docs/cd/B28359_01/network.111/b28528/appd.htm

It's a trade off:

Going to 11g means you will have access to better features (whether the project needs them is a different matter), you get the chance to learn and use the latest technology, what you learn will be relevant for longer, 11g will be supported for longer.

Going to 10g means you you might have to learn "new" stuff that will be out of date sonner. However, if you come across a problem, more people will have come across it, so it's quicker to find the solution. This might sound selfish because it relies on other people breaking the path, but each project/person has their priorities.

We are currently on 9i, and hopefully will be upgrading to 11g in 2009. Would you advice going straight to 11g?

We first need to convince the 'business people', that it would be worth spending the money on the upgrade.
I can see that you are running a workshop in Seattle on the 13th of Jan about the benefits to the business of upgrading to 11g. That would have been ideal for me, but since I am in Scotland there is no way I can attend.
Would it therefore be possible to receive a copy of your presentation please? I am sure it would be very helpful to have.

Hi Tom,
Thanks for your wonderful work for oracle community... Do you have visibility of another major release after 11g ? Do we have 12g coming in future say 1 year ?
What major changes/features can be expected in new release (12g?) ?

br
atul

Hi Tom - We have a bunch of 10g databases and we are planning on upgrading them to 11g in the next six months or so. According to you, what are the best 11g features that we should absolutely try ? What is the best approach for the upgrade of 10g - 11g? These are databases that are about 100gb each.

We have a lot of small databases that we are planning to upgrade from 10g to 11g at the same time. They about 20g - 50g. Could we just do a simple schema export / import from 10g home to 11g home ? Will that work or do we need to run some special checks ? We also have databases that are about 200 gb. What will be the best way to upgrade them ?

When you say just UPGRADE => is that using database upgrade advisor ? We are moving from one server to another, can I still use dbua ? Is there a document on how to use this ?

We are also planning a 10g - 11g upgrade. What we are doing is some consolidation as well, like it is not going to be a one to one database mapping betwen 10g and 11g. So we would doing schema moves more than database moves. What is the best way to achieve this ?

Also, we have some loader jobs that run in the current 10g database. If we want to capture the workload and run it against a 11g database using Real Application Testing how can we achieve that ? Would we register the 10g database in a 11g oem environment and capture the workload and then run it in the 11g database ?

Tom

We are looking to upgrade some of our databases from 10.1.0.5 to 11.2.

In the process we are planning to perform Tablespace encryption on the majority of tablespaces in the database.

We are initially going to build an 11g database alongside the 10.1 database to perform application testing.

What would be the best way of achieving this migration

Have a question on your followup above


"As long as it is the same OS - you can move machines, just

a) backup old
b) install software on new
c) restore to new
d) run dbua on new, the database upgrade assistant.
"

Just need some clarification..

a. when you say backup old, does that need to be using rman ? Because our dev and QA environments do not have archive log enabled, so I am wondering how that will work...

b. install software on new => is that 10g software or 11g software ?

We are planning to upgrade one of our core application databases from 10g on Solaris to 11g on Linux. I have recently heard about the sql plan baselines. Looking for some pointers there. Would we do something like - turn on something to capture the plans for a month or so in the 10g database, save them, what do we do on the 11g database ? would we just need to apply those plans from 10g in case of any performance issues ? can you also point me to some good documentation on this topic ?

We could use STS and capture existing plans (for abt a month or so) in existing 10g database. Would we then load the sql tuning sets into the 11g database ? When we do that, do all the SQLs automatically start using the stored plans ?

Hi Tom,

Can you provide us some pointers where the Features (or functionality) that work in Oracle 10g and that do no work on Oracle 11g.

Apart from testing the application end to end. Is there any documentation that can point the above..?