RE: Upgrade to 10G from 9.2.0.7

Here is a summary for 10.2.0.2

5415881 WRONG SORT ORDER RETURNED BY QUERY
4748222 UPDATE COLUMN WITH TDE CAUSES OERI: [ZTSMDWL FAILED] IF THERE IS A 
TRIGGER
5117016 LIBSERVER10.A INCORRECTLY LOCATED IN $ORACLE_HOME/RDBMS/LIB/
5380055 ORA-01555 ON ALL INSTANCES AFTER SWITCHOVER AND SWITCHBACK.
5752399 10203 SOLARIS64 IOCTL VERITAS

Some are applicable for 10.1.0.5 and 10.2.0.1; Verify with the "Patch" page on 
Metalink.

HTH

GovindanK

On Mon, 22 Jan 2007 10:23:13 -0700, "Allen, Brandon" 
<Brandon.Allen@xxxxxxxxxxx> said:

I strongly agree with Dennis' recommendation, but would also recommend to take 
it a step further and do that before/after benchmarking on your TEST system, 
long before you even consider upgrading production - and test it thoroughly, 
not just a hand full of your favorite queries.  Do a full test of all 
business-critical functionality - multiple times, and good load testing 
(mimicking real production load as closely as possible) too.  Keep a copy of 
your 9i database online after the upgrade if possible so you can compare 
explain plans and other differences after the upgrade if necessary, and keep a 
couple statspack level 6 snapshots around from your 9i database during typical 
work loads also.

Yes, I think the general consensus is that 10.2.0.2 is safe for production - 
not so sure about 10.2.0.3, and not sure about Solaris (I'm only running 
10.2.0.2 on AIX so far).  You might want to plan on feeding it a bit more RAM 
for the shared pool to account for all the automagic stuff, but that of course 
depends on many things.

Read the 10g docs and get very familiar with the new features, especially the 
auto_gather_stats job, Database Console/Grid Control & AWR (unfortunately only 
available to you with Diag Pack license, legally anyway).

Regards,
Brandon
  ____________________________________________________________

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Dennis Williams



   The key suggestion was to have the users agree on key performance indicators 
BEFORE the upgrade. Then run some benchmarks BEFORE the upgrade and document 
the performance. Then, after the upgrade, confirm those benchmarks and this 
will help you pinpoint where your performance issues are.

Other related posts: