11g or 10g - still need to be wary.
December 22, 2007 - 9am Central time zone
Reviewer: Peter Clark from 54° 39' 42" N, 2° 45' 51" W
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.
Followup December 22, 2007 - 12pm Central time zone:
8.1.5 was *very stable* and is heavily used (still).
7.0 was the only game in town for a long while - but the industry was still a bit young back then - 7.1 and 7.3 were heavily taken up
9iR1 and 10gr1 were as well - they were just rapidly superseded by r2's.
Initial releases are *not* less stable - with that I very much disagree. Brand new features in them - perhaps - but from a pure upgrade perspective? No.
They are all incremental improvements - what if we would have called 11gr1 10gr3 instead? What would your opinion be then? Maybe we need to freeze the 11 part and just have release 1, 2, 3, 4, 5, ... 42 and so on.
December 22, 2007 - 2pm Central time zone
Reviewer: A reader
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
Followup December 22, 2007 - 4pm Central time zone:
why.
it may be a good thing to only upgrade when it is sunny.
it may be a good thing to only turn on the computer after 6am.
it may be a good thing to never walk under ladders.
it may be a good thing to not cross a black cats path.
Seriously - what if we never had a "major release" again - but we have 11gr42, 11gr43 and so on...
I agree
December 22, 2007 - 8pm Central time zone
Reviewer: Tom
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? : )
Followup December 23, 2007 - 5pm Central time zone:
Hah, there was no version 1.0
version 2.0 was the first :)
the running joke is "there was never a version 1.0 because no one would buy a 1.0 product...."
sort of fitting for this thread I believe.
Tricky question
December 22, 2007 - 11pm Central time zone
Reviewer: A reader
There was no Oracle 1.0 release. Oracle went straight to v2, to make a impression that it wasn't a
new product.
Review future app plans?
December 23, 2007 - 6am Central time zone
Reviewer: Maxim from SPb, Russia
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.
Thoughts from a cold Cumbria
December 23, 2007 - 10am Central time zone
Reviewer: Peter Clark from Cumbria, UK
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...
Followup December 23, 2007 - 6pm Central time zone:
... I'm sure you'll agree, that for a DBA running a production system, database
stability is of paramount importance ..
agreed.
but what you don't say in your list was....
10.1 - more or less 'stable' then 9ir2?
Wait - before you answer - I know, I know everyone has their favorite bug they hit from 9ir2 to 10gr1 - but, they will have the same for 10gr2 over 10gr1 and so on. 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. You'll hit issues in both (undoubtedly). You will workaround said issues - in whatever fashion.
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 care not a whit for opinion. Much of opinion is based on hearsay and "the really big one that got away" stories. I've got DBA's that are of the opinion that views are evil, that stored procedures are bad, that locally managed tablespaces and system allocated extents *must* be bad (because we always sized things so precisely before) that automatic undo management is evil - we heard of someone that heard from someone that overhead a conversation at a happy hour about a bad experience with automatic undo management.... In fact, any feature released after version 6 is evil - you just need indexes, select, insert, update and delete.
If you want stability - you will have tested - load, scale, functionality. And you know what (in my experience) almost everyone skips....
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.
We used the major releases internally to run our systems before you run yours on them.
I would not be able to file a bug against a new release if the new release was inherently unstable - because the bug database is one of the first to go.
I agree with Peter Clark
December 23, 2007 - 12pm Central time zone
Reviewer: A reader from FL
"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.
Followup December 23, 2007 - 6pm Central time zone:
In 14 years that I've been at Oracle there have been 14 production major releases.
That is why "rapidly superseded"
And we tend to support that which people used - the uptakes (because of exactly this mindset here) of the "dot zero" releases are less than the "dot not-zero"
I just wish we'd stop the major releases and just have 11g release 42 in the future. It would end the discussion.
What is in a name.... I always wondered why Sybase for example went from version 4 to ....... System 10 way back when. Or why Microsoft names their stuff after years. What is in a name....
It's all a matter of opinion
December 24, 2007 - 8am Central time zone
Reviewer: Peter Clark from Cumbria
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.
Followup December 24, 2007 - 9am Central time zone:
How can I misinterpret you comparing
9ir1 to 9ir2
10gr1 to 10gr2
but not 9ir2 to 10gr1?
... Is that person in a good position to give an opinion on a particular topic? ...
right and polls get us there how?
we'll have to agree to not agree.
December 24, 2007 - 10am Central time zone
Reviewer: Greg from Reston
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 ...
December 26, 2007 - 2pm Central time zone
Reviewer: A reader
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?
Followup December 26, 2007 - 10pm Central time zone:
... I don¿t have firsthand experience between 9iR2 vs 10gR1¿ ...
nuff said I guess.
... 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. ...
more than nuff said...
Differences between versions
December 26, 2007 - 2pm Central time zone
Reviewer: Stuart from Iselin, NJ USA
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.
stored procedures are really bad
January 3, 2008 - 1pm Central time zone
Reviewer: A reader
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.
Followup January 3, 2008 - 3pm Central time zone:
hahahaha
wow, that has to be the stupidest thing I've seen written by anyone on this site *ever*.
everything you say is wrong, and nothing but nothing is backed up with anything.
seriously slow = code you write. I can write slow stored procedures, I can write slow java. Java is not "faster" than a stored procedure. You write bad code, you have bad code, period. You want to process a transaction - then you best use a stored procedure (but only if you want it fast)
Data cannot be cached? Now I know you just never ever read the documentation. Ever.
stored procedures
January 3, 2008 - 4pm Central time zone
Reviewer: A reader
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 ?
Followup January 3, 2008 - 5pm Central time zone:
when you open my eyes - I'll gladly open yours.
give us a "for example" - go for it, something that did database stuff (a transaction) that works "so incredibly fast" in java.
Else yes, you are speaking "trash".
I spend lots of time backing up things I say with examples, the proof is in the pudding. I challenge you - back up what you say - else yes, you look "not smart"
the stupid comment goes to you saying
"x is slow, y is faster"
that - that is the "not smart" comment. Go ahead, prove your point - tell us what you mean, tell us what was so so so so fast in java that wasn't fast in plsql. Maybe what you were doing is so obviously inappropriate for a stored procedure that doing it in java made sense. Maybe you just did it so entirely wrong in plsql and compared really bad plsql code to better java (your caching comment leads me to believe that is at least part of the problem).
"Only comments on the original question will be accepted." ?
January 4, 2008 - 3am Central time zone
Reviewer: Sokrates
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 ?
Followup January 4, 2008 - 11am Central time zone:
Because I tend to never delete in real life.
"Someone may have found a solution before"
January 4, 2008 - 6am Central time zone
Reviewer: lh from emea
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.
Followup January 4, 2008 - 12pm Central time zone:
who said that?
I have a presentation that says "this is software, not wine" (so apparently, I beg to differ).
January 4, 2008 - 9am Central time zone
Reviewer: A reader
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.
Let's be realistic please.
January 4, 2008 - 11am Central time zone
Reviewer: Bill. from Brussels.
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.
Followup January 4, 2008 - 12pm Central time zone:
you better test test test with 10gr2 - as much as 11gr1. Period. You are not going to test MORE or LESS with 11gr1 versus 10gr2. No one is asking you to do our testing for us, anyone running a production system knows you need to test with the smallest of changes (and 11g is all about testing, with many features JUST FOR testing).
I'm still in favor of never advancing the major release, everything is a patch...
Things to consider
January 4, 2008 - 4pm Central time zone
Reviewer: lh from finland
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.
Pants down
January 9, 2008 - 4pm Central time zone
Reviewer: Dana from Phoenix, AZ USA
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?
January 16, 2008 - 4pm Central time zone
Reviewer: Joe PInegar from Andover, MA USA
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.
Real world example
February 20, 2008 - 2pm Central time zone
Reviewer: A reader
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.
Followup February 20, 2008 - 3pm Central time zone:
but 10gr2 has as many new features over 10gr1 as 11gr1 did over 10gr2...
That fact is rather not relevant. 11gr1 could have been called 10gr3, would that have changed anything in anyones mind?
February 20, 2008 - 4pm Central time zone
Reviewer: A reader
"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?
Followup February 20, 2008 - 4pm Central time zone:
...Doesn't that increase the possibility that it is inherently less stable than 10gr1...
not unless you believe in entropy of software.
I don't see how you could make that comparison. Using that logic, we obviously should be using version 2.0 (because there was no version 1 - someone knew that no one buys version 1 - so they went straight to 2.0, perception...)
Do you think that a bulk of 11gr1 might have been bug fixes for 10gr2?
February 20, 2008 - 5pm Central time zone
Reviewer: A reader
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.
Followup February 20, 2008 - 8pm Central time zone:
that is the silliest comment I've seen to date.
Have you read the new features guide for these products since 8i Release 1?
If you think the addition of new features "jeopardizes" people, well, ok. whatever.
11g
February 20, 2008 - 10pm Central time zone
Reviewer: Zahir M from Monroe , NJ
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 .
11g upgrade
September 29, 2008 - 12am Central time zone
Reviewer: sam
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.
upgrade
October 4, 2008 - 8pm Central time zone
Reviewer: A reader
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.
Followup October 6, 2008 - 2pm Central time zone:
you read the upgrade guide - then you follow the documented instructions and just upgrade.
you do not use export/import.
upgrade
October 7, 2008 - 9am Central time zone
Reviewer: A reader
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
November 7, 2008 - 10am Central time zone
Reviewer: Huy from UK
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.
Upgrade to 11g
December 22, 2008 - 5am Central time zone
Reviewer: Lise from Scotland
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.
Followup December 29, 2008 - 2pm Central time zone:
... Would you advice going straight to 11g? ...
sure. Look back on asktom closer to the date - under the files tab..
12g
April 8, 2009 - 4am Central time zone
Reviewer: Atul Gupta from Finland
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
Followup April 13, 2009 - 1pm Central time zone:
well, the next major one will likely be called "11g release 2" - and yes, 12 (and beyond even) is in the works.
I cannot really discuss futures here however... sorry.
|