Orace-ear Oracle Database Upgrade, Migration ... · Orace-ear / Oracle Database Upgrade, Migration...

Oracle-Regular / Oracle Database Upgrade, Migration & Transformation Tips & Techniques / Edward Whalen / 605-0

Oracle Database Upgrade, Migration & Transformation Tips & Techniques Chapter 5

Copyright © 2015 by McGraw-Hill Education

Step Operation Description Done?

1 Capture database file metadata

Capture metadata for all database files about to be migrated.

2 Verify COMPATIBLE setting

If COMPATIBLE is < 11.0.0.0, then it will be necessary to change any READ ONLY transportable tablespaces to READ WRITE mode.

3 Create INCREMENTAL LEVEL 0 image copy backups of all datafiles

Back up all datafiles as INCREMENTAL LEVEL 0 image copy backups, routing them to their eventual ASM disk group(s).

4 Create INCREMENTAL LEVEL 1 backups of all datafiles

Create INCREMENTAL LEVEL 1 differential backups for all datafiles.

CHECKLIST 5-1 Migration Preparation Operations

Checklist_Chapter 5.indd 1 18/05/15 4:55 PM





1 Archive online redo log Issue ALTER SYSTEM SWITCH LOGFILE; command to archive the most current online redo log.

2 Disable unnecessary recovery settings

Turn off BCT. Turn off Flashback Database logging. Remove any restore points.

3 Perform consistent database shutdown

Issue SHUTDOWN IMMEDIATE command to ensure no uncommitted changes remain and that all dirtied database buffers are checkpointed.

CHECKLIST 5-2 Immediate Pre-Migration Prerequisites






1 Migrate modified SPFILE to ASM

■ Build a PFILE from the current SPFILE.

■ Modify the PFILE’s initialization parameters to point to ASM disk group(s) for all files.

■ Test the PFILE.

■ Rebuild an ASM-based SPFILE.

■ Restart the instance.

2 Migrate control files to ASM

Restore the database’s control files to the chosen ASM disk group(s).

3 Mount the database Mount the database using the newly migrated control files.

4 Switch to previously migrated datafiles

Use the SWITCH DATABASE TO COPY; RMAN command to switch all datafiles to ASM-based storage.

5 Recover the database Perform complete recovery on the migrated datafiles using differential INCREMENTAL LEVEL 1 backups, archived redo logs, and currently online redo logs.

6 Open the database in RESETLOGS mode

Issue the ALTER DATABASE OPEN RESETLOGS; command to open the database.

7 Migrate online redo logs to ASM

Re-create all members for the online redo log groups on the chosen ASM disk group(s).

8 Migrate temporary tablespace temp file(s) to ASM

Create a new temp file for all temporary tablespace(s) on the chosen ASM disk group(s).

9 Switch FRA to ASM Modify DB_RECOVERY_FILE_DEST to ASM storage.

10 Restore/rebuild database backups to FRA on ASM

Optionally, restore any existing backup files to the FRA on its new ASM disk group(s).

11 Validate the migration Validate that all database files have been successfully migrated per expectations.

CHECKLIST 5-3 Complete Migration to ASM






1 Capture database file metadata

Capture metadata for all database files about to be migrated.

2 Verify COMPATIBLE setting

If COMPATIBLE is < 11.0.0.0, then it will be necessary to change any READ ONLY transportable tablespaces to READ WRITE mode.

3 Create INCREMENTAL LEVEL 0 image copy backups of datafiles for selected tablespaces

Back up selected tablespaces as INCREMENTAL LEVEL 0 image copy backups, routing them to their eventual ASM disk group(s).

4 Create INCREMENTAL LEVEL 1 backups of datafiles for selected tablespaces

Create INCREMENTAL LEVEL 1 differential backups for selected tablespaces.

5 Recover selected tablespaces to image copies

Use the SWITCH TABLESPACE <tablespace name> TO COPY; RMAN command to switch all datafiles for selected tablespaces to ASM-based storage.

6 Move non-ASM mount points to ASM disk groups

Once all database files have been moved from one or more set(s) of LUNs, those LUNs can be wiped clean of any file system and then added as new ASM disks into an existing ASM disk group. This can also be done from SQL*Plus while connected to the ASM instance via the ALTER DISKGROUP <diskgroup name> ADD <disk_name_1, disk_name_2, …> REBALANCE POWER n; command, where n can range from 1 to 1024 in Oracle 11.2.0.2.

7 Rebalance ASM disk groups

Once old mount points are added via Step 6 to the ASM disk groups, ASM should automatically rebalance them, thus spreading all ASM AUs across all available ASM disks. This can also be done from SQL*Plus while connected to the ASM instance via the ALTER DISKGROUP <diskgroup name> REBALANCE POWER n; command.

CHECKLIST 5-1A Phased Migration from Non-ASM to ASM Storage: Preparations






1 Migrate modified SPFILE to ASM

■ Build a PFILE from the current SPFILE.

■ Modify the PFILE’s initialization parameters to point to ASM disk group(s) for all files.

■ Test the PFILE.

■ Rebuild an ASM-based SPFILE.

■ Restart the instance.

2 Migrate control files to ASM

Restore the database’s control files to the chosen ASM disk group(s).

3 Mount the database Mount the database using the newly migrated control files.

4 Create INCREMENTAL LEVEL 0 image copy backups of datafiles for remaining tablespaces

Back up datafiles for any remaining tablespaces—that is, SYSTEM, UNDOTBS, SYSAUX, and any others—as INCREMENTAL LEVEL 0 image copy backups, routing them to their eventual ASM disk group(s).

5 Switch to remaining datafiles

Use the SWITCH DATABASE TO COPY; RMAN command to switch all remaining datafiles to ASM-based storage.

6 Recover the database Perform complete recovery on the migrated datafiles using differential INCREMENTAL LEVEL 1 backups, archived redo logs, and currently online redo logs.

7 Open database In RESETLOGS mode

Issue the ALTER DATABASE OPEN RESETLOGS; command to open the database.

8 Migrate online redo logs to ASM

Re-create all members for the online redo log groups on the chosen ASM disk group(s).

CHECKLIST 5-3A Phased Migration from Non-ASM to ASM Storage: Completion

(Continues)

Checklist_Chapter 5.indd 5 20/05/15 11:33 AM





9 Migrate temporary tablespace temp file(s) to ASM

Create a new temp file for all temporary tablespace(s) on the chosen ASM disk group(s).

10 Switch FRA to ASM Modify DB_RECOVERY_FILE_DEST to ASM storage.

11 Restore/rebuild database backups to FRA on ASM

Optionally, restore any existing backup files to the FRA on its new ASM disk group(s).

12 Validate the migration Validate that all database files have been successfully migrated per expectations

CHECKLIST 5-3A Phased Migration from Non-ASM to ASM Storage: Completion (Continued)






1 Determine source and destination platform endianness

Verify source and platform endianness.If different endianness is detected, decide where the RMAN CONVERT command will be executed.

2 Verify transportability of selected tablespace set

Confirm that

■ Tablespaces selected are indeed part of self-contained set.

■ Database character set is identical (or at least that the destination database’s character set is a superset of the source database).

3 Create transportability infrastructure

Build any directories needed for temporary storage of Data Pump Export and Import parameter files and dump sets and grant appropriate permissions to directory objects.Build a database link to permit transmission of files via DBMS_FILE_TRANSFER.Prepare Data Pump Export and Import scripts and parameter files for metadata capture and transport.

CHECKLIST 6-1 TTS Pre-Migration Preparations






1 Switch selected tablespaces to READ ONLY mode on source database

From SQL*Plus on the source database, issue ALTER TABLESPACE <tablespace name> READ ONLY; for each tablespace about to be transported.

2 Capture source tablespace metadata via Data Pump

Via Data Pump Export, capture the metadata for all objects in each tablespace about to be transported.

3 Transport datafiles and metadata from source platform to destination platform

Use DBMS_FILE_TRANSFER to copy all datafiles and Data Pump dump set from source to destination platform.

4 Perform endian conversion at destination

If necessary, convert the tablespace’s datafiles to the endian format on the destination OS platform.

5 Import source tablespace metadata via Data Pump Export

Via Data Pump Import, import the metadata for each transported tablespace.

6 Switch transported tablespaces to READ WRITE mode at destination

Issue ALTER TABLESPACE <tablespace name> READ WRITE; for each tablespace that has been incorporated into the destination database.

7 Revert selected tablespaces to READ WRITE mode at source

If desired, issue ALTER TABLESPACE <tablespace name> READ WRITE; for each tablespace transported from the source platform.

CHECKLIST 6-2 Example TTS Operation





CHECKLIST 6-3 Point-in-Time TTS


1 Create Transportable Tablespace Set as of specific point in time

Use RMAN TRANSPORTABLE TABLESPACE command to build a TTS for a specific point in time.

2 Transport datafiles and metadata from source platform to destination platform

Use DBMS_FILE_TRANSFER to copy all datafiles and Data Pump dump set from the source to the destination platform.


If necessary, convert the tablespace’s datafiles to the endian format on the destination OS platform.

4 Import source tablespace metadata via Data Pump Export

Via Data Pump Import, import the metadata for each transported tablespace.


Issue ALTER TABLESPACE <tablespace name> READ WRITE; for each tablespace that has been incorporated into the destination database

6 Revert tablespaces to READ WRITE mode at source







1 Perform consistent shutdown of source database

From SQL*Plus on the source database, issue SHUTDOWN IMMEDIATE; and wait for shutdown to complete cleanly.

2 Reopen source database in READ ONLY mode

From SQL*Plus on the source database, issue STARTUP READ ONLY; to open the database in READ ONLY mode.

3 Verify database transportability

Execute procedures to verify the database is in the proper state for transportability:

■ DBMS_TTS.CHECK_DB

■ DBMS_TTS.CHECK_EXTERNAL

4 Prepare source database for transport to destination

Prepare for conversion:

■ If conversion is done on the source platform, then RMAN generates and retains appropriate converted versions on the source platform for eventual transport to the destination.

■ If conversion is done on the destination, then RMAN generates a conversion script that is shipped to the destination database for eventual execution there.

5 Transport source database to destination database OS platform

Ship all necessary scripts and database files to the destination server via either scpy, sftp, or the DBMS_FILE_TRANSFER utility.

6 Open destination database

From SQL*Plus on the destination database, issue ALTER DATABASE OPEN RESETLOGS; to open the database in a new incarnation.

CHECKLIST 6-4 TDB Migration: A Practical Example






1 Identify tablespace sets Identify which tablespace set(s) will be migrated from source to destination databases.

2 Identify source and destination database versions and desired migration method(s)

Determine which migration method(s) are possible between the source and destination OS platforms.

3 Download XTTS scripts and modules

See MOS Note 1389592.1 for the link to rman_xttconvert_ 1.4.zip.

4 Create supporting database objects/staging areas on source and destination platforms

■ If the DBMS_FILE_TRANSFER method is selected, create the required directory objects and database link.

■ If the RMAN method is selected, create staging areas at the destination.

5 Decompress and install XTTS scripts

Save rman_xttconvert_1.4 .zip contents to the staging directory on the source and destination database platforms.

6 Configure XTTS properties and environment variables

Set up an xtt.properties file and establish a TMPDIR directory.

CHECKLIST 9-1 Preparing for Migration (XTTS)






1 Prepare tablespace sets for transport

■ Check that all selected tablespaces on the source database are ready for XTTS migration.

■ Stage image copies of all selected tablespaces’ datafiles on the source platform.

■ If required, build an RMAN command script for eventual datafile conversion on the destination database.

2 Push datafile copies from source platform to destination platform

Use OS commands to push all datafile copies from the source platform to the destination platform.


If necessary, convert the tablespaces’ datafiles to the endian format on the destination OS platform.

CHECKLIST 9-2A Initial Migration Using RMAN






1 Prepare tablespace sets for transport

■ Check that all selected tablespaces on the source database are ready for XTTS migration.

■ Prepare the getfile.sql script and xttnewdatafiles .txt parameter file.

■ Copy the script and parameter file to the destination platform.

2 Pull transport datafiles from source platform to destination platform

Invoke DBMS_FILE_TRANSFER to pull all datafiles and Data Pump dump set from the source platform to the destination platform.

CHECKLIST 9-2B Initial Migration Using DBMS_FILE_TRANSFER






1 Create incremental backups via RMAN

Build INCREMENTAL LEVEL 1 backups for XTTS tablespaces on the source database and create parameter files for later synchronization steps.

2 Push incremental backups from source platform to destination platform

Invoke OS commands to push all incremental backups from the source platform to the destination platform.

3 Convert and apply incremental backups to destination database

If necessary, convert the incremental backups to the endian format on the destination OS platform.Apply the converted incremental backups to the destination database.

4 Capture FROM_SCN for next incremental backup

Determine and record the starting SCN for the next INCREMENTAL LEVEL 1 backup.

CHECKLIST 9-3 Synchronizing Iteratively via Incremental Backups






1 Switch tablespaces to READ ONLY mode at destination

Issue ALTER TABLESPACE <tablespace name> READ ONLY; for selected tablespace(s) on the source database.

2 Create incremental backups via RMAN

Build INCREMENTAL LEVEL 1 backups for XTTS tablespaces on the source database and create parameter files for later synchronization steps.

3 Push incremental backups from source platform to destination platform

Use OS commands to push all incremental backups from the source platform to the destination platform.

4 Convert and apply incremental backups to destination database

If necessary, convert the incremental backups to the endian format on the destination OS platform.Apply converted incremental backups to the destination database.

5 Import source tablespace metadata via Data Pump Import

Generate and execute Data Pump Import commands to import the source database tablespaces’ metadata into the destination database.


Issue ALTER TABLESPACE <tablespace name> READ WRITE; for each tablespace that has been incorporated into the destination database.

7 Revert tablespaces to READ WRITE mode at source


8 Redirect applications to destination database

Create and start appropriate database services and/or network connectivity on the new destination database.

9 Clean up staging directories

Remove unneeded files from the source and destination systems.

CHECKLIST 9-4 Final Synchronization and Migration






1 Clone a New Empty PDB from PDB$SEED

Create a new empty PDB by cloning it from the PDB$SEED PDB

2 Transfer Data into New PDB

Transfer data from the source database into the new PDB using the most appropriate migration method

CHECKLIST 13-1 Cloning a New Empty PDB from PDB$SEED and Transferring Data Into It






1 Determine destination directory for new PDB

Determine where the new PDB tablespaces’ datafiles should reside on the destination platform.

2 Quiesce source PDB Bring the source PDB into READ ONLY mode to guarantee transactional consistency before and after data transference.

3 Clone new PDB Copy the source PDB’s contents to a new PDB at the destination CDB.

4 Reactivate source PDB Return the source PDB to READ WRITE mode.

CHECKLIST 13-2 Cloning a New PDB from an Existing PDB






1 Quiesce source PDB Bring the source database into READ ONLY mode to guarantee transactional consistency before and after data transference.

2 Unplug PDB from source CDB

Issue the ALTER PLUGGABLE DATABASE … UNPLUG command to unplug the source PDB from its current CDB.

3 Drop unplugged PDB from source CDB

Issue the DROP PLUGGABLE DATABASE command to drop the source PDB.

4 Verify compatibility of unplugged PDB with its destination CDB

Run the CHECK_PLUG_COMPATIBILITY procedure of the DBMS_PDB package to verify the PDB’s compatibility with the destination CDB.

5 Replug PDB into destination CDB

Issue CREATE PLUGGABLE DATABASE command to replug source PDB into its new destination CDB.

6 Reactivate replugged PDB

Issue ALTER DATABASE OPEN; to open the replugged PDB at its new CDB location.

CHECKLIST 13-3 Unplugging and Replugging a PDB






1 Quiesce source Non-CDB

Bring source non-CDB into READ ONLY mode to guarantee transactional consistency before and after data transference.

2 Construct PDB metadata Build corresponding metadata for the new PDB.

3 Shut down source non-CDB

Close non-CDB database.

4 Plug in PDB Use previously captured metadata to plug non-CDB into CDB as new PDB.

5 Resolve extraneous metadata in new PDB

Execute noncdb_to_pdb.sql script to eliminate redundant metadata in new PDB.

6 Open new PDB in READ WRITE mode

Bring new PDB into READ WRITE mode.

CHECKLIST 13-4 Transforming a Non-CDB into a PDB


Orace-ear Oracle Database Upgrade, Migration ... · Orace-ear / Oracle Database Upgrade, Migration...

Documents

Transcript of Orace-ear Oracle Database Upgrade, Migration ... · Orace-ear / Oracle Database Upgrade, Migration...