Upgrade 10g to 11i with Logical Standby Database

This procedure does involve installing the 10g software on the Rehost Operational Environment (ROE) severs because you have to create a physical standby database initially which must be on the same software version as the primary database. The big plus to this type of setup is that for as long as you have room to store archivelogs and flashback files you can continually test on the new servers until you are ready to cut over to the new database. Under the right conditions the downtime involved can be limited to the amount of time it takes to switch where the applications are pointing.

Benefits

•  Downtime of database can be less than 2 minutes
•  Continual testing until satisfied with configuration
•  Test system can continually use flashback database and transactions reran until satisfied with performance.  (Just need space to keep archivelogs and flashback files)
•   Standby database does not have to be recreated

Limitations

•   Logical standby database has known restrictions on Data Type support
• T here is substantial setup involved on both OE and ROE environments 
•  The 10g software must be installed in the ROE environment.

Assumptions:

• Network connectivity between OE (Operational Environment) and ROE.
• Enough space exists to build standby database in ROE environment
• Enough space exists for archive logs and flashback files to continually rollback database for testing.

High Overview

1. Run Pre-Upgrade scripts and check for issues to be fixed before upgrade.
2. Build Physical Standby
3. Convert Physical Standby to Logical Standby
4.  Stop log apply
5.  Test System Performance by upgrading running test transactions and FLASHBACK DATABASE
6. Between tests catch system backup by applying redo logs
7. Upgrade logical Standby
8. Catch system backup by applying redo
9. Switchover to Standby

Visual Overview

 

Figure 6 : Initial Physical Standby Database setup

 Figure 7 : Conversion to Logical Standby and Upgrade

 

 

 Figure 8 : Start applying redo until caught up

Figure 9 : Final cut over

Crash Restore Repeat - Edge of Tomorrow's Recovery (Part 1)

11g Upgrade Option Transportable Tablespaces

This is the third Blog on 11g upgrade options when you are moving to new hardware on both the production and standby instances. 

This procedure is involves building a new database and pointing it to the old database files that hold the application data. Since the database is prebuilt as an 11g database there is no upgrade needed it is just the movement of data. There is a limited amount data that will be exported/imported but it relates to mainly to users and grants. This type of migration works best with smaller data sets. If there is limited network connectivity then enough space for some small dump files will need to exist and be moved between servers.

Benefits

• Works cross-platform and cross-Endians since Oracle 10g
•  Faster than exporting/importing 
• Tablespaces can be mounted from both databases simultaneously as long as they are READ ONLY as soon as a tablespace is set READ WRITE on the target database it will be be "lost" to the source

Limitations

•  Additional steps necessary to move views, synonyms, grants
•  System and sysaux tables can’t be transported
•  Databases must have identical charactersets

Assumptions:

1.       Method exists to move/copy files (datafiles/dumpfiles) between servers.

High Overview

Source System	Destination
Prepare SOURCE system	Install software and patches
Run Pre-Upgrade scripts	Create ‘empty’ database
Gather Source Database Information	Create USERs
Create USER scripts
Create EMP/IMP scripts
Set tablespace READ ONLY
Export TS metadata
Export non-segment obj.
Shutdown immediate
Copy datafiles	Import Tablespace metadata
	Import non-segment user objects*
	READ-WRITE tablespace
	Run ALTER USER script
	Recompile INVALID OBJECTS

Visual Overview