On Unix for upgrading from 9.2.0 TO 10.2 (64-bit), request experienced
Folks who have done such migrations to confirm the following basic Steps
& if i am missing something?


2 create a SYSAUX tablespace
3 SQL> @catupgrd.sql

4 Run utlu102s.sql to display the results of the upgrade:

Don't need to run olstrig.sql as Oracle Label Security does NOT exist
seemingly (NOT sure what this means either)

5 Run utlrp.sql to recompile any remaining stored PL/SQL and Java code.)

O.S. = Solaris 10

Database = Non-RAC

Thanks indeed

CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

Search Discussions

  • David Sharples at Oct 17, 2006 at 4:23 pm
    what did the migration guide say when you read it?
    On 17/10/06, VIVEK_SHARMA wrote:


    On Unix for upgrading from 9.2.0 TO 10.2 (64-bit), request experienced
    Folks who have done such migrations to confirm the following basic Steps &
    if i am missing something?
  • Mark Strickland at Oct 17, 2006 at 6:51 pm
    I can't address the 9.2 to 10.2 upgrade steps other than to say TEST
    TEST TEST and document the steps carefully down to the keystroke.
    What I CAN talk about is the Upgrade From Hell that I and my co-DBA
    did this past weekend. We upgraded production from to Just a patchset, so a rather minor upgrade, really. In
    theory, at least. This is on Solaris 9, Veritas, Hitachi SAN, 3-node
    RAC, Data Guard with physical and logical standbys, and an RMAN
    catalog. We had carefully tested and documented everything very
    carefully and were expecting a 3-hour cakewalk (but ready for
    anything, of course). Well. It took from noon Saturday until 9:00
    Sunday night to get stable again. The upgrade itself took close to 4
    hours. However, for some so-far inexplicable reason, Oracle decided
    to switch the VIPs to a different network interface on each RAC
    server. We re-booted the 3 servers, then Veritas couldn't mount all
    the file systems. My co-DBA knows Veritas well and got that cleaned
    up and after another re-boot, the servers couldn't NFS-mount the file
    system that is used for DB_FILE_RECOVERY_DEST. That required a
    static-IP fix from our network engineer. So, once we got everything
    restarted, the instances started crashing after 20-40 minutes. The
    rest of the weekend was spent on the phone with Oracle Support. We
    went through three staff shifts at Oracle Support and each handoff
    required the support engineer going through the logs and trace files
    and getting up to speed on the issue. We were about to punt and
    switch to single-node and turn on more CPUs when an engineer in either
    India or Australia (can't remember which...the engineer is Sandeep
    Singla...BRILLIANT!) was able to identify the cause of the problem in
    the VIP trace file. It was occasionally timing out while checking the
    default gateway. The timeout threshold was 2 seconds and the engineer
    had us change that to 10. The timeouts were causing the instances on
    the node to crash. After 36 hours with 1 hour of sleep on a company
    sofa for each of us and working with three shifts at Oracle Support,
    our Production environment was stable again, just in the nick of time.
    I'm almost caught up on sleep and I'm starting to unclench.

    As you might guess, I'm now even more motivated to understand RAC
    inside and out.

    Other than using this forum to b***h about our upgrade experience, I
    hope to have provided useful information.

    Vivek, if you'd like a copy of our upgrade plan, I'd be happy to send
    it. It won't be directly applicable to your upgrade, of course, but
    it might be useful.

    Mark Strickland
    Seattle, WA
  • Rjamya at Oct 17, 2006 at 7:48 pm
    I think we are still doing a 9.2 to 10104 upgrade as we refresh a
    database, everyday. My felowe dba, included the upgrade scripts as
    part of our refresh scripts.

    so, we bring over raws, using create control file, instantiate the db,
    recover it using archivelogs, shut down, bring up in migrate mode,
    upgrade the db to 10g and then shutdown. Startup in open mode.

    Works fine, we almost always test migrations like this whenever
    possible, so developers can mess around the db, which gets destroyed
    at the end of the day.

    Now, we are not doing 9.2 to 10.2, but (as described above) we also do
    10104 to 10202, so it is almost painless too.

    However, the initial part of crs etc was a buit painful, once it is
    done, rest is almost mechanical.



Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
postedOct 17, '06 at 7:00a
activeOct 17, '06 at 7:48p



site design / logo © 2022 Grokbase