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@xxxxxxxxxxxxxxxxxx =09 =09 ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------