8i to 9i Upgrade Path

From: Ken Payton <Ken.Payton_at_choicepointprg.net>
Date: Fri, 7 May 2004 07:52:59 -0400
Message-ID: <91E3FFBB780D6945B8A5D90569A74461CA2F64@bobwpmsg001.choicepoint.net>

I am looking for feedback to a plan I've conceptually put together for = implementing a 8i to 9i database upgrade. I'm hoping others will be = able to identify holes/gaps in my plan that I may not see, and hopefully = spark ideas for others.

Background
This is a multi-terabyte database that is primarily read-only and = updated via transportable tablespaces. A few application tables are = being updated but this is a very small portion of the database and = isolated to their own tablespace.

Requirements
o A series of regression tests will be performed in a QA environment = with a subset of the database. This regression testing will span across = a couple weeks.
o A scheduled "GO/NO GO" test will occur starting on a Friday night = and last throughout the weekend. The goal is to stress the system and = measure multiple performance measurements. In the event the "NO GO" = decision is made the database needs to be reversed to it's state on = Friday, otherwise it will be left up :)

Problems to Overcome
o Oracle's limited ability to rollback an upgrade o Time constraints for backup/recovery of multi-terabyte environment o Inability to build complete copy of the database for complete = QA/stress tests.
o Inability to house two copies of the database on the same machine

something to keep in mind is we have two copies of the production = database that are in use. We require both database during production in = order to sustain load and for fail-over situations and do not desire for = either to be down during normal business hours.

Plan
  o Perform sanity tests in QA environment with subset of database.
=20

  o Upgrade procedure
    o build a new 9i database(9iDB) on the same machine with similar = configuration as 8i version(8iDB).

o halt all activity on 8iDB
o use tt(transportable tablespace) to migrate copies of the = application tables from 8iDB to 9iDB

o use tt to create export dmp's of the read only tablespaces in 8iDB o create file listings from 8iDB to correspond with the tt exports = taken

o shut down the 8iDB, preserving it's current configuration o import the 8iDB datafiles using the tt dmp's. o ** DO NOT READ WRITE ANY TABLESPACES ** o Multiple exchange commands will occur and some partitioning will = be changed in 9iDB but only at a logical level. The data is never = manipulated and the tablespaces are never put into READ WRITE mode.

o Perform stress testing/performance review("GO" / "NO GO")

      o if "GO"
        o Leave up for production use
        o After one week of use, Read write all tablespaces and cleanup =
8iDB.
      o if "NO GO"
        o shut down 9iDB
        o startup 8iDB
        o leave 8iDB up Monday morning ** Since no changes have been =

made to the 8iDB structures, no data has been manipulated, and = tablespaces have not been put into READ WRITE mode, 8iDB should be in = exact state as before test.

o review issues, identify work around, reschedule upgrade for = next window

Thanks in advance for any feedback.

Kenny Payton
Choicepoint Public Records Group
Sr. Database Administrator
ken.payton_at_choicepointprg.net

=09
=09

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Fri May 07 2004 - 06:50:32 CDT