| Introduction | | | | database duplication. |
| This document provides you with a brief description on | | | | IV. Running Database Duplication |
| how to do refresh a Database (duplicate a database) | | | | To run database duplication we can prepare a batch |
| from the Production Database backup taken using | | | | script, or run a command to start it up. It would look |
| RMAN to tapes to any other environments. | | | | something like this:rman cmdfile <the rman script> |
| I. Introduction | | | | msglog <a file name for the logs> |
| This document describes the process of refreshing | | | | Before starting the RMAN script, the following things |
| the Test Databases from the RMAN Production | | | | need to be taken care of : |
| database backups taken to the Tapes / Disks. | | | | 1. Verify that the RMAN catalog database is |
| II. Initial Preparation Steps | | | | open. Make sure this database will be open during |
| We first need to make sure that the database is not | | | | complete duplication process, e.g. if it normally goes |
| running within Fail Safe environment, and that the disk | | | | down for backup turn off the backup procedures. If |
| space used by the old database is released, so we | | | | the connection to the database is lost during the |
| can fit the new database. Here are a few steps that | | | | duplication, the process will fail and will need recovery. |
| need to be taken cars of before starting the | | | | 2. Verify that the target database is open. |
| Database Refresh: | | | | Make sure this database will be open during complete |
| 1. If there is requirement to preserve some data | | | | duplication process, same as for RMAN database. |
| or accounts (Schema’s and other necessary | | | | 3. Verify that the Oracle services for auxiliary |
| things) from the old environment, export that data first | | | | database are running and the database is in nomount |
| before starting the refreshing from Production. | | | | state. |
| 2. If the databases are running in Fail Safe | | | | If the RMAN script is successful, it will get all the files |
| environment, shut them down through Fail Safe | | | | from the file system, place them in appropriate |
| Manager. Also shut down the Listener and the | | | | locations as specified in the script, and recover the |
| Intelligent Agent that is running for those particular | | | | database. It will also change the Database ID, and |
| databases. | | | | start the database. This is the best case scenario, |
| 3. Modify the TNSNAMES.ORA, the INIT.ORA | | | | however, if duplication script fails you might need to try |
| (and listener.ora if required) files to make sure the | | | | and recover from failure. |
| database can be started independently, using the local | | | | V. Recovering from Failure |
| listener. Try this out by starting the listener service | | | | If the RMAN duplication process fails, We might need |
| and database service manually through the Services | | | | to recover the database using the RMAN backup. The |
| screen on the Win 2000 machine, and starting | | | | Database supplication or the restore can fail because |
| database through SQL*Plus. | | | | of some reasons like : |
| 4. Shut down the database using the | | | | 1. RMAN catalog database going down for |
| FAILSAFE Manager and remove all database files | | | | backup |
| except ones from the Admin directories (e.g. init.ora). | | | | 2. Archived logs not available on the file system |
| This is required to clean space on disk to fit the new | | | | (when set until SCN was not specified in the script). |
| database. If we have enough disk space for the | | | | In those cases you might try following steps to |
| restore to happen, then we move the existing files to a | | | | recover, first run the switch clone command through |
| different directory or mount point. | | | | RMAN (After CONNECTING to the TARGET, |
| III. Preparing RMAN Duplication Script | | | | CATALOG and AUXILIARY Databases) :run{ |
| Once we are done with the above steps, we can | | | | switch clone datafile all; |
| proceed with the next step of creating the scripts for | | | | } |
| restoring the Database. An example of this script is | | | | Afterwards, try recreating the control file. RMAN first |
| given below:connect catalog rman | | | | creates a control file but does not have all data files |
| password@<RMAN Catalog database | | | | specified in there (it creates that one later). Best way |
| name>;connect target sys | | | | is to backup control file to trace on the target |
| password@<Target database>;connect auxiliary | | | | database, and modify that script to run in auxiliary |
| sys/password@<Auxiliary Database>;run { | | | | database. Changes to the script are typically: use |
| allocate auxiliary channel ch1 type 'sbt_tape' parms | | | | new filenames as the location might have changed, set |
| | | | | new database name, and use RESETLOGS clause. |
| 'ENV=(TDPO_OPTFILE=c:clustertdpo.opt)'; | | | | Once control file is created and executed, complete |
| set until scn <SCN No.> or <Date>; | | | | recovery of the database until specified SCN, the |
| set newname for datafile 1 to ‘new path for | | | | RMAN script can look something like this :run { |
| restore’; | | | | allocate auxiliary channel ch1 type 'sbt_tape' parms |
| . . . . . . | | | | 'ENV=(TDPO_OPTFILE=c:clustertdpo.opt)'; |
| . . . . . . | | | | set until scn 6899135273; |
| ... | | | | recover |
| duplicate target database to <new auxiliary | | | | clone database |
| database name> | | | | check readonly; |
| logfile group 1 (‘<location of the log | | | | release channel ch1; |
| file>’, | | | | } |
| (‘<location of | | | | This step will obtain all required archived logs from the |
| the log file>’) SIZE 100M, | | | | file system and apply them to the database. After |
| group 2 ((‘<location of the log | | | | recovery is completed you can open the |
| file>’, | | | | database:alter database open resetlogs; |
| (‘<location of | | | | That would complete the recovery. Note that when |
| the log file>’) SIZE 100M, | | | | recovered this way, the database Id is still the same |
| group 3 ((‘<location of the log | | | | as for production, thus you cannot use RMAN to |
| file>’, | | | | backup that database (unless you are using different |
| (‘<location of | | | | catalog). Consequently, one should always strive to |
| the log file>’) SIZE 100M; | | | | have the database duplicated properly through RMAN |
| } | | | | without failures. |
| The description of the above script is as follows : | | | | VI. Post Refresh Steps |
| The first part deals with connecting to required | | | | After the database is duplicated, there are few steps |
| databases: | | | | that might be required: |
| 1. catalog database where RMAN catalog is | | | | 1. In some environments , it may be required to |
| stored, | | | | change the Mode to noarchivelog mode as the |
| 2. target database which is the database we | | | | Production is mainly run in Archivelog mode. |
| want to clone, and | | | | 2. Add files to temporary tablespaces. When |
| 3. auxiliary database which is the one that we | | | | the database is restored all files and tablespaces will |
| are attempting to create. | | | | exist, however, none of the temp files will be created. |
| 4. Note that when running this script later on, both | | | | One needs to add tempfiles to temporary tablespaces. |
| catalog and target databases need to be open during | | | | 3. Drop all database links, and recreate them to |
| the process, while auxiliary database is normally in | | | | point to proper environment. After duplication, new |
| NOMOUNT state. | | | | database will have same database links as the |
| Next in the script is allocating channel used to access | | | | production, thus pointing to the production database. |
| file system through TSM. Note that to do that we will | | | | All the database links should therefore be dropped, and |
| need to change TSM configuration (dsm.opt file, | | | | new ones created to point to the new environment. |
| nodename parameter) in order for the node to appear | | | | 4. If the new database is running in the Fail |
| as the production node. | | | | Safe environment, one will need to rebuild the |
| Next in the script is set until SCN / DATE command | | | | password file on the other node (the one that was not |
| that specifies until which point the database will be | | | | used when duplicating the database). If this is not |
| duplicated. If the UNTIL SCN / DATE is not mentioned, | | | | done, the database will not start on that node and the |
| RMAN will attempt to recover until the last archived | | | | whole Fail Safe group will be moved to other node. |
| log, which can cause failure if that log is not available | | | | 5. Revert back changes to tnsnames.ora (and |
| on the tape drive (e.g. it is still on the production server | | | | listener.ora if applicable) to make sure the database |
| disk). | | | | can start within Fail Safe. |
| Next is the list of set newname for datafile commands, | | | | 6. Revert back changes done to the TSM |
| which are required when new disk structure is | | | | configuration files (dsm.opt). |
| different from production disk structure (which is case | | | | 7. Shut the database, stop local listener and |
| on all our systems). All database files should be | | | | database services, and start the listener and database |
| specified in this list (nothing is required for tempfiles). | | | | within Fail Safe. |
| The list of datafile’s can be obtained by querying | | | | 8. Make sure the database can fall-over |
| the DBA_DATA_FILES data dictionary view. | | | | correctly to another node, by moving Fail Safe group |
| Finally, the duplicate command is there to do the actual | | | | manually. |