Problems that can ocuur while upgrading from 9i 1o 10g
Jenny
I want to know what all problem i will face during upgradation..
Mark D Powell
> Our company is planning to uprage from oracle 9i to 10g.
> I want to know what all problem i will face during upgradation..
First, 9i and 10g are marketing labels and not real Oracle version
numbers.
Second, upgrade how? Using which method/path? Upgrade in place on
same platform, Exp/Imp, New platform, etc ....
As long as you are following the directions in the Oracle
Installation and Migration Guide you should be fine. Pay attention to
the OS patch requirements in the manual and be sure to visit the
referenced web site for updates to the upgrade process.
The real fun is after you upgrade and you have to re-tune your
applications. How much of this you have to do will depend on your
application. Some sites have few if any performance issues after
upgrading while others have more work than the shop can handle. Based
on conversations with other DBA's who have upgraded most sites have
only a few issues.
HTH -- Mark D Powell --
sybr...@hccnet.nl
<Mark....@eds.com> wrote:
>
> As long as you are following the directions in the Oracle
>Installation and Migration Guide you should be fine.
The OP was hoping to avoid reading this document.
--
Sybrand Bakker
Senior Oracle DBA
sri...@hotmail.com
upgrade using the manual method.
I had to create a SYSAUX tablespace in 9i before starting the database
with 10g binaries.
By mistake i created the SYSAUX tablespace without segment space
management AUTO and started the database with 10g.
I then could not drop the SYSAUX tablespace with 10g or go back to 9i
and had to start from the beginning
Just posting so that someone doesnt do the same mistake i did.
regards
srivenu
joel garry
> Our company is planning to uprage from oracle 9i to 10g.
> I want to know what all problem i will face during upgradation..
See http://www.oracle.com/technology/products/bi/db/10g/pdf/twp_bidw_optimizer_10gr2_0208.pdf
I just completed one this weekend (plus a hardware change and app
upgrade). Since the app upgrade part of this was very involved, I had
the luxury of taking my time with the oracle side of it, and barely
remember the difficulties, except for a few very recently.
So just off the top of my head:
Justify all init.ora changes and settings. My app is profligate with
cursors, so the vendor recommends 8000. I had gone much lower when I
went to 9 because of the advent of session_cached_cursors, but now had
to go back up. Had problems with shared pool when I ramped up to full
usage, so had to increase it (app uses bind variables). Was a
problem, because I had set sga_max_size to allow similar sga size to
my previous system (D'Oh!), and until I could bounce had to reduce
buffer cache so I could increase the shared pool. Log buffer sizing
is different, Oracle uses memory granules (read the docs), so you wind
up with many megs, it can be quite different than what you set. Be
especially vigilant if you have any underscore parameters set. Be
sure you understand the issues about async I/O for your configuration,
it varies a lot. Be sure you understand sort area parameters and the
pga_aggregate thingie.
The EM advisors seem pretty good, within limits. One shortcoming is
some things seem to just want more and more. I think the performance
pack is worth the cost, assuming you don't use it to avoid learning
how things really work. Google for ASH simulation if you are standard
edition.
I've been told optimizer_index_caching may be more trouble than it is
worth, so I removed that from init.ora. I've found
index_optimizer_cost_adj appears to be useful.
RMAN is getting pretty sophisticated, but I still haven't figured out
how to get it to do exactly what I want entirely within Oracle, but I
haven't finished setting up the repository for it yet either. I'm
quite impressed with it's compression and speed, and am mostly happy
with the EM interface, though obviously if I had written it I would
have done some things different. Then again, why think I am smarter
than Oracle developers? :-) I'm still seeing strange unexplained
usage spikes, and EM tells me the OS is swapping when I don't see
it...
I did have problems with patching to 10.2.0.4, most stemming from me
not being paranoid enough (!) and checking to see dbconsole shut down
when it said it did. I'm still having some issues with subsequent
instances starting up dbconsoles, haven't had time to figure it out.
Be sure and understand all parts of the technology stack, especially
if you haven't had much experience with apache or oracleAS type
things.
So far the automatic jobs appear to be doing the right thing, but you
might want to google around for the interminable discussions about
things like how often to calculate statistics. The right way is site-
dependent. My own view on that has turned 180.
It made sense to use exp/imp due to the app. One of the advisors told
me which objects had row chaining and wasted space due to the
subsequent app upgrade, which I found very helpful, don't know when I
would have gotten to it if I had to do it manually.
"Private strand flush not complete" is generally ignorable.
And I second everyone about reading the upgrade manual, as well as the
new features docs.
jg
--
@home.com is bogus.
International talk like a pirate day, Sept. 19. RRRRRRRR, man!
phil_h...@yahoo.com.au
> Our company is planning to uprage from oracle 9i to 10g.
> I want to know what all problem i will face during upgradation..
Read the upgrade guide. Then read it again. Look in Metalink - it
covers things that have happened elsewhere.
Problems will depend on your specific site. We only found one minor
change in PL/SQL that broke one of our packages; the rest went
smoothly, but we'd done functional and load tests on an exact copy of
our production DB, so we knew what to expect. Many sites don't have
that luxury.
From what I've heard, having a lot of non-default init.ora settings
can also cause you grief. During our upgrade I took the opportunity to
restore a whole lot of parameters to their defaults in 10g, as well as
enabling ASMM. Joel wrote "Justify all init.ora changes and settings",
and I agree - a lot of init.ora files have settings added years ago
and never touched subsequently. A thorough review will probably show
up a lot that just aren't required under 10g.
-- Phil
Jenny
Actually we have to upgrade Oracle and we are also changing platform
from TRU64 UNIX to HP-UX
what we have planned is
firstly we will upgrade oracle on the TRU64 Unix and tune the
application
and then we will change the platform from TRU64 to HP-UX
Shakespeare
"Jenny" <jjoh...@gmail.com> schreef in bericht
news:5e0012e6-37a2-47a0...@q26g2000prq.googlegroups.com...
> Our company is planning to uprage from oracle 9i to 10g.
> I want to know what all problem i will face during upgradation..
Adding to all other useful comments:
Don't forget to recalculate all appropriate schema statistics after
upgrading, even sys and system. We found we were left with some old
statistics, because 10g calculates stats only when (it thinks) it is
necessairy (stale indexes etc). After recalculating statistics, performance
went up. Our problem MAY have been caused by using a bucket size of 1 in 9i
(we set it to 'auto' in 10g). Also calculate system statistics.
(GATHER_SYSTEM_STATS).
One sql statement is not allowed in 10 where it was in 9: select level from
<table> (without connect by) . I don't know why anyone would do so, but we
had a third party app that did.. There is an init parameter to allow this,
but I think it would be better to remove the statement from your app (if
possible).
You may encounter performance problems. We found high parse times for some
statements (higher than in 9i), and a lot more cpu usage (mainly due to not
using bind variables; we tried to set cursor_sharing_mode to similar, but
that gave a lot of errors in our queries), and we had to tune some of the
worst statements. It looks like 10g is evaluating a lot more execution paths
before deciding what's best, specially when using (complex) views within a
complex query. In our case, we had to hint the queries to avoid long parse
runs. (6 sec parse, 31 msec execution time when not hinted, 33 msec total
when hinted), But again: this was caused mainly by bad programming in a
third party app.
Shakespeare