Duplicate database from non ASM to ASM to a different host [ID 382669.1]

Duplicate database from non ASM to ASM (vise versa) to a different host [ID 382669.1]
		修改時間 13-JUL-2011 型別 HOWTO 狀態 PUBLISHED

In this Document

Assumed database names:
1. Backup of the primary database.

---

Applies to:

Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 10.2.0.5 - Release: 10.1 to 10.2
Information in this document applies to any platform.
Add ***Checked for relevance on 18-Dec-2010***

Goal

This note demonstrates how to duplicate database from host A to host B and at the same time converting a database from a file system to ASM or ASM to filesystem depending on the requirements. The example in this document uses catalog database, however this task can also be performed without a catalog.

Solution

Assumed database names:

Primary Database SID: PROD
Duplicate Database SID: AUX
RMAN Catalog SID: RMAN

====================================================================================

Steps

1. Backup the primary database.

2 Determine how much disk space will be required.

3 Ensuring you have enough space within your ASM instance.

4 Making the backup available for the duplicate process.

5 Creating the init.ora & administration directories for the duplicate database.

6. Ensuring SQL*NET connections to primary database and RMAN catalog are working.

7. Prepare RMAN duplicate script.

8. Execute the RMAN script.

=====================================================================================

1. Backup of the primary database.

Host A (Target)

Prior to creating a duplicate database you must have a backup of the target database. In this example we assume the backup media is disk. Find appropriate disk space on Host A and take a full backup including archive logs and current controlfile (Figure 1a). If you are planning to duplicate a subset of the database refer to (Figure 1b) this illustrates the RMAN command to backing up certain tablespaces.

Figure 1a - This command will perform. a full database backup including archivelogs and the current controlfile. If backup pieces are on ASM, then a new backup to filesystem is required.


Figure 1b- This command will perform. a tablespace backup (SYSTEM, SYSAUX, UNDO & USERS) including archive logs
and the current controlfile.

2 Determine how much disk space will be required.

Host A(Target)

After deciding what you will be duplicating, calculate the entire space this will require on the new Host. The full database calculation (Figure 2a) will calculate the entire space required whereas (figure 2b) allows you to enter the tablespace names in order to calculate the space required. Figure 2c provides a sample output.

Figure 2a - Calculate total space for all datafiles within database.

Figure 2b - Calculate space for list of datafiles within primary database.


Figure 2c - Sample output of space calculation.

3. Ensuring you have enough space within your ASM instance.

Host B (AUX)

Prior to starting the duplicate process you must ensure you have enough disk space within ASM to hold the duplicate database.

Figure 3a - Sample output showing the space available with the ASM diskgroup.


Compare the result received from this query with the output from 2a or 2b and ensure you have enough disk space for your duplicate database.

If you do not have enough disk space within your ASM instance ensure you must add it prior to continuing.

Keep in mind you may also be storing archive logs and/or the recovery area within the ASM instance so ample room must be available.

If you are duplicating from ASM to a filesystem ensure you have enough disk space on the source file system.

4. Making the backup available for the duplicate process.

If your backup resides on disk you will need to copy this back up from Host A to Host B. Ensure you place it in the same directory as where it was created. In the example below (figure 4a) the backup piece resides in â/backups/ORA102â these files need to be copied into the same directory on host B.

Furthermore also ensure than all archive log backups have also been moved and any archive logs in the archive log directory that may be require for the recovery. The archive logs required will depend on the point in time of the recovery.

Figure 4a - A list backup showing the backup pieces that need to be copied across Host B

5. Creating the init.ora & administration directories for the duplicate database.

Host B(Target)

Create the pfile [initAUX.ora] parameter file in the $ORACLE_HOME/dbs directory for the auxiliary database. An example is shown below (figure 5a) with bare minimum settings. Note you may require to set parameters which are the same as your production database (refer to you primary init.ora)

Figure 5a - Sample initAUX.ora with minimal settings

Following the creation of the initAUX.ora startup nomount the auxiliary instance.

Figure 5b - startup nomount the AUX instance.

6. Ensuring SQL*NET connections to primary database and RMAN catalog are working.

Host B(Target)

Ensure the production target database is open or at least mounted. If using a catalog database this must also be open. Test your SQL*NET connections: From Host B you must be able to connect to the primary DB as sysdba and make an rman connection to RMAN. Perform. a basic test using sqlplus. When you have successfully connected exit sqlplus and move onto the next step.

Figure 6a - SQL*NET connections

7. Prepare RMAN duplicate script.

In a working directory on Host B create an RMAN script. file cr_duplicate.rcv. The example below (figure 7a) shows the command for a partial duplicate.

Figure 7a - Sample standby creation command.

8. Execute the RMAN script.

Start RMAN, connect to the production target, the catalog instance and also the auxiliary clone. Run the RMAN duplicate script. as shown below. Before doing this ensure that the Oracle SID environment variable is set to the duplicate clone database.

Figure 8a - Execute the RMAN duplicate script.