Clone an Oracle Database using Cold Physical BackupDatabase Name: troySource Database side:
(Troy database)
Cold Backup Steps:
1. Get the file path information using below query
Select name from v$datafile;
select member from v$logfile;
select name from v$controlfile;
2. Parameter file backup If troy database running on spfile
Create pfile=’/u01/backup/inittroy.ora’ from spfile;
If database running in pfile using os command to copy the pfile and placed in backup path.
3.Taken the control file backup
Alter database backup controlfile to trace as ‘/u01/backup/control01.ora’;
4.Shutdown immediate
5.Copy all the data files/log files using os command & placed in backup path.
6.Startup the database.
Clone Database side: (Clone database)
Database Name: Clone
Clone Database Steps:
1.Create the appropriate folder in corresponding path & placed the backup files in corresponding folder.(bdump,udump,create,pfile,cdump,oradata)
2.Change the init.ora parameter like control file path, dbname, instance name etc...
3.Create the password file using orapwd utility.(Database in windows we need to create the service id using oradim utility)
4.Startup the Database in NOMOUNT stage.
5.Create the control file for cloning database.
Using backup controlfile trace to generate the create controlfile scripts.Change the Database name & files path, also change 'REUSE' needs to be changed to 'SET'.
CREATE CONTROLFILE SET DATABASE "clone" RESETLOGS FORCE LOGGING NOARCHIVELOG
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 453
LOGFILE
GROUP 1 '/U01/oradata/clone/redo01.log' SIZE 200M,
GROUP 2 '/U01/oradata/clone/redo02.log' SIZE 200M,
GROUP 3 '/U01/oradata/clone/redo03.log' SIZE 200M
DATAFILE'/U01/oradata/clone/system01.dbf',
'/U01/oradata/clone/undotbs01.dbf',
'/U01/oradata/clone/users01.dbf',
CHARACTER SET WE8ISO8859P1;
Note: placed the script in sql prompt. Now controlfile created.
6.Now open the database.
Alter database open resetlogs;
Note: Check the logfile, datafiles & instance status
**********************************************************************************
Clone an Oracle Database using Hot Physical BackupDatabase Name:
troyDatabase must be in Archive log mode.
Source Database side: (Troy database)
Hot Backup Steps:
1.Get the file path information using below query.
Select tablespace_name, file_name from dba_data_files order by 1;
2. Parameter file backup If troy database running on spfile
Create pfile=’/u01/backup/inittroy.ora’ from spfile;
If database running in pfile using os command to copy the pfile and placed in backup path.
3.Put the tablespace in begin backup mode Using os command to copy the datafiles belongs to begin backup mode tablespace & placed in backup path. (Refer below example)
4.Once copied the datafile, release the tablespace from begin backup mode to end backup
5.Repeat the steps 1-3 for all your tablespaces.
6.Taken the controlfile backup
Alter database backup controlfile to trace as ‘/u01/backup/control01.ora’;
7.Backup all your archive log files between the previous backup and the new backup as well.
Example:
steps:
2.Alter tablespace system begin backup;
To ensure the begin backup mode tablespace using below query
Select * from v$backup; (refer the Change#, Time column)
3. Host cp /u01/oracle/raja/system1.DBF /u01/backup/system01.dbf à using os command to copy the datafile.
4. Alter tablespace system end backup;
To ensure the begin backup mode tablespace using below query
Select * from v$backup;
Clone Database side: (Clone database)
Database Name: Clone
Clone Database Steps:
1.Create the appropriate folder in corresponding path & placed the backup files in corresponding folder.(bdump,udump,create,pfile,cdump,oradata)
2.Change the init.ora parameter like control file path, dbname, instance name etc...
3.Create the password file using orapwd utility.(Database in windows we need to create the service id using oradim utility)
4.Startup the Database in NOMOUNT stage.
5.Create the control file for cloning database.
Using backup controlfile trace to generate the create controlfile scripts.Change the Database name & files path, also change 'REUSE' needs to be changed to 'SET'.
CREATE CONTROLFILE SET DATABASE "clone" RESETLOGS FORCE LOGGING NOARCHIVELOG
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 453
LOGFILE
GROUP 1 '/U01/oradata/clone/redo01.log' SIZE 200M,
GROUP 2 '/U01/oradata/clone/redo02.log' SIZE 200M,
GROUP 3 '/U01/oradata/clone/redo03.log' SIZE 200M
DATAFILE
'/U01/oradata/clone/system01.dbf',
'/U01/oradata/clone/undotbs01.dbf',
'/U01/oradata/clone/users01.dbf',
CHARACTER SET WE8ISO8859P1;
Note: placed the script in sql prompt. Now controlfile created.
6.Recover the database using controlfile.
Recover database using backup controlfile until cancel;
7.Now open the database.
Alter database open resetlogs;
Note: Check the logfile, datafiles status.
Friday, September 25, 2009
Thursday, September 24, 2009
Recovering a Lost Datafile Without a Backup: Example
RMAN can handle lost datafiles without user intervention during restore and recovery. When a datafile is lost, the possible cases can be classified as follows:
The control file knows about the datafile, that is, the user backed up the control file after datafile creation, but the datafile itself is not backed up. If the datafile record is in the control file, then RESTORE creates the datafile in the original location or in a user-specified location (for example, with SET NEWNAME). The RECOVER command can then apply the necessary logs to the datafile.
The control file does not have the datafile record, that is, the user did not back up the control file after datafile creation. During recovery, the database will detect the missing datafile and report it to RMAN, which will create a new datafile and continue recovery by applying the remaining logs. If the datafile was created in a parent incarnation, it will be created during restore or recover as appropriate.
In this example, the following sequence of events occurs:
You make a whole database backup of your ARCHIVELOG mode database.
You create a tablespace history containing a single datafile called /mydb/history01.dbf.
You populate the newly created datafile with data.
You archive all the active online redo logs.
A user accidentally deletes the datafile history01.dbf from the operating system before you have a chance to back it up.
In this case, the current control file knows about the datafile. To restore and recover the datafile, start RMAN, connect to the target database, and then enter the following commands at the RMAN prompt:# take the tablespace with the missing datafile offline
SQL "ALTER TABLESPACE history OFFLINE IMMEDIATE";
# restore the tablespace even though you have no backup
RESTORE TABLESPACE history;
# recover tablespace
RECOVER TABLESPACE hisotry;
# bring the recovered tablespace back online
SQL "ALTER TABLESPACE history ONLINE";
The control file knows about the datafile, that is, the user backed up the control file after datafile creation, but the datafile itself is not backed up. If the datafile record is in the control file, then RESTORE creates the datafile in the original location or in a user-specified location (for example, with SET NEWNAME). The RECOVER command can then apply the necessary logs to the datafile.
The control file does not have the datafile record, that is, the user did not back up the control file after datafile creation. During recovery, the database will detect the missing datafile and report it to RMAN, which will create a new datafile and continue recovery by applying the remaining logs. If the datafile was created in a parent incarnation, it will be created during restore or recover as appropriate.
In this example, the following sequence of events occurs:
You make a whole database backup of your ARCHIVELOG mode database.
You create a tablespace history containing a single datafile called /mydb/history01.dbf.
You populate the newly created datafile with data.
You archive all the active online redo logs.
A user accidentally deletes the datafile history01.dbf from the operating system before you have a chance to back it up.
In this case, the current control file knows about the datafile. To restore and recover the datafile, start RMAN, connect to the target database, and then enter the following commands at the RMAN prompt:# take the tablespace with the missing datafile offline
SQL "ALTER TABLESPACE history OFFLINE IMMEDIATE";
# restore the tablespace even though you have no backup
RESTORE TABLESPACE history;
# recover tablespace
RECOVER TABLESPACE hisotry;
# bring the recovered tablespace back online
SQL "ALTER TABLESPACE history ONLINE";
Recovering a Database in NOARCHIVELOG Mode: Example
You can recover a database running in NOARCHIVELOG mode with incremental backups. Note that the incremental backups must be consistent, like all backups of a database run in NOARCHIVELOG mode, so you cannot make backups of the database when it is open.
Assume the following scenario:
You run database trgt in NOARCHIVELOG mode.
You use a recovery catalog.
You shut down the database consistently and make a level 0 backup of database trgt to tape on Sunday afternoon.
You shut down the database consistently and make a level 1 differential incremental backup to tape at 3:00 a.m. on Wednesday and Friday.
The database has a media failure on Saturday, destroying half of the datafiles as well as the online redo logs.
In this case, you must perform an incomplete media recovery until Friday, since that is the date of the most recent incremental backup. RMAN uses the level 0 Sunday backup as well as the Wednesday and Friday level 1 backups.
Because the online redo logs are lost, you must specify the NOREDO option in the RECOVER command. You must also specify NOREDO if the online logs are available but the redo cannot be applied to the incrementals. If you do not specify NOREDO, then RMAN searches for redo logs after applying the Friday incremental backup, and issues an error message when it does not find them. If the correct online logs for the restored backup had been available, then you could have run RECOVER DATABASE without specifying NOREDO. The changes in the online logs would have been applied.
After connecting to trgt and the catalog database, recover the database with the following command:
STARTUP FORCE MOUNT;
RESTORE CONTROLFILE; # restore control file from consistent backup
ALTER DATABASE MOUNT;
RESTORE DATABASE; # restore datafiles from consistent backup
RECOVER DATABASE NOREDO; # specify NOREDO because online redo logs are lost
ALTER DATABASE OPEN RESETLOGS;
The recovered database reflects only changes up through the time of the Friday incremental backup. Because there are no archived redo logs, there is no way to recover changes made after the incremental backup.
Assume the following scenario:
You run database trgt in NOARCHIVELOG mode.
You use a recovery catalog.
You shut down the database consistently and make a level 0 backup of database trgt to tape on Sunday afternoon.
You shut down the database consistently and make a level 1 differential incremental backup to tape at 3:00 a.m. on Wednesday and Friday.
The database has a media failure on Saturday, destroying half of the datafiles as well as the online redo logs.
In this case, you must perform an incomplete media recovery until Friday, since that is the date of the most recent incremental backup. RMAN uses the level 0 Sunday backup as well as the Wednesday and Friday level 1 backups.
Because the online redo logs are lost, you must specify the NOREDO option in the RECOVER command. You must also specify NOREDO if the online logs are available but the redo cannot be applied to the incrementals. If you do not specify NOREDO, then RMAN searches for redo logs after applying the Friday incremental backup, and issues an error message when it does not find them. If the correct online logs for the restored backup had been available, then you could have run RECOVER DATABASE without specifying NOREDO. The changes in the online logs would have been applied.
After connecting to trgt and the catalog database, recover the database with the following command:
STARTUP FORCE MOUNT;
RESTORE CONTROLFILE; # restore control file from consistent backup
ALTER DATABASE MOUNT;
RESTORE DATABASE; # restore datafiles from consistent backup
RECOVER DATABASE NOREDO; # specify NOREDO because online redo logs are lost
ALTER DATABASE OPEN RESETLOGS;
The recovered database reflects only changes up through the time of the Friday incremental backup. Because there are no archived redo logs, there is no way to recover changes made after the incremental backup.
Restoring When Multiple Databases in the Catalog Share the Same Name: Example
As explained in the description for SET DBID in Oracle Database Recovery Manager Reference, you must run the SET DBID command to restore the control file when the target database is not mounted and multiple databases registered in the recovery catalog share the same name. In this case, do the following steps in order:
Start RMAN and connect to the target database.
Run the STARTUP FORCE NOMOUNT command.
Run the SET DBID command to distinguish this connected target database from other target databases that have the same name.
Run the RESTORE CONTROLFILE command. After restoring the control file, you can mount the database to restore the rest of the database.
This procedure avoids the RMAN-20005 message when you attempt to restore the control file. This message occurs because more than one target database has the same name, so RMAN requires the unique DBID to distinguishes the databases from one another.
Obtaining the DBID of a Database That You Need to Restore
If you have saved the RMAN output log files, then refer to these logs to determine the database identifier. RMAN automatically provides the DBID whenever you connect to the database:% rman TARGET /
Recovery Manager: Release 10.1.0.2.0 - Production
connected to target database: RMAN (DBID=1231209694)
The output from RMAN jobs is also stored persistently in V$RMAN_STATUS and RC_RMAN_STATUS.
The DBID is also stored in the RC_DATABASE and RC_DATABASE_INCARNATION recovery catalog views.
Because the names of the databases that are registered in the recovery catalog are presumed nonunique in this scenario, you must use some other unique piece of information to determine the correct DBID. If you know the filename of a datafile or online redo log associated with the database you wish to restore, and this filename is unique across all databases registered in the recovery catalog, then substitute this fully specified filename for filename_of_log_or_df in the following queries.
Determine the DBID by performing one of the following queries:
SELECT DISTINCT DB_ID
FROM DB, DBINC, DFATT
WHERE DB.DB_KEY = DBINC.DB_KEY
AND DBINC.DBINC_KEY = DFATT.DBINC_KEY
AND DFATT.FNAME = 'filename_of_log_or_df';
SELECT DISTINCT DB_ID
FROM DB, DBINC, ORL
WHERE DB.DB_KEY = DBINC.DB_KEY
AND DBINC.DBINC_KEY = ORL.DBINC_KEY
AND ORL.FNAME = 'filename_of_log_or_df';
Restoring a Backup Control File By Using the DBID
To set the DBID, connect RMAN to the target database and run the following SET command, where target_dbid is the value you obtained from the previous step:
SET DBID = target_dbid;
To restore the control file to its default location and then mount it, run:
RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;
To restore and recover the database, run:
RESTORE DATABASE;
RECOVER DATABASE
# optionally, delete logs restored for recovery and limit disk space used
DELETE ARCHIVELOG MAXSIZE 2M;
Start RMAN and connect to the target database.
Run the STARTUP FORCE NOMOUNT command.
Run the SET DBID command to distinguish this connected target database from other target databases that have the same name.
Run the RESTORE CONTROLFILE command. After restoring the control file, you can mount the database to restore the rest of the database.
This procedure avoids the RMAN-20005 message when you attempt to restore the control file. This message occurs because more than one target database has the same name, so RMAN requires the unique DBID to distinguishes the databases from one another.
Obtaining the DBID of a Database That You Need to Restore
If you have saved the RMAN output log files, then refer to these logs to determine the database identifier. RMAN automatically provides the DBID whenever you connect to the database:% rman TARGET /
Recovery Manager: Release 10.1.0.2.0 - Production
connected to target database: RMAN (DBID=1231209694)
The output from RMAN jobs is also stored persistently in V$RMAN_STATUS and RC_RMAN_STATUS.
The DBID is also stored in the RC_DATABASE and RC_DATABASE_INCARNATION recovery catalog views.
Because the names of the databases that are registered in the recovery catalog are presumed nonunique in this scenario, you must use some other unique piece of information to determine the correct DBID. If you know the filename of a datafile or online redo log associated with the database you wish to restore, and this filename is unique across all databases registered in the recovery catalog, then substitute this fully specified filename for filename_of_log_or_df in the following queries.
Determine the DBID by performing one of the following queries:
SELECT DISTINCT DB_ID
FROM DB, DBINC, DFATT
WHERE DB.DB_KEY = DBINC.DB_KEY
AND DBINC.DBINC_KEY = DFATT.DBINC_KEY
AND DFATT.FNAME = 'filename_of_log_or_df';
SELECT DISTINCT DB_ID
FROM DB, DBINC, ORL
WHERE DB.DB_KEY = DBINC.DB_KEY
AND DBINC.DBINC_KEY = ORL.DBINC_KEY
AND ORL.FNAME = 'filename_of_log_or_df';
Restoring a Backup Control File By Using the DBID
To set the DBID, connect RMAN to the target database and run the following SET command, where target_dbid is the value you obtained from the previous step:
SET DBID = target_dbid;
To restore the control file to its default location and then mount it, run:
RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;
To restore and recover the database, run:
RESTORE DATABASE;
RECOVER DATABASE
# optionally, delete logs restored for recovery and limit disk space used
DELETE ARCHIVELOG MAXSIZE 2M;
Restoring Datafile Copies to a New Host: Example
To move the database to a new host by means of datafile copies, you must transfer the copies manually to the new machine. This example assumes that you are using a recovery catalog.
After connecting to the target database and recovery catalog, run a LIST command to see a listing of datafile copies and their associated primary keys, as in the following example:
LIST COPY;
Copy the datafile copies to the new host with an operating system utility. For example, in UNIX: % cp -r /tmp/*dbf /net/new_host/oracle/oradata/trgt
Start RMAN and then uncatalog the datafile copies on the old host. For example, enter: CHANGE COPY OF DATAFILE 1,2,3,4,5,6,7,8 UNCATALOG;
Catalog the datafile copies, using their new filenames or CATALOG START WITH (if you know all the files are in directories with a common prefix easily addressed with a CATALOG START WITH). For example, run:
CATALOG START WITH '?/oradata/trgt/';
Or this example specifies files individually:
CATALOG DATAFILECOPY
'?/oradata/trgt/system01.dbf', '?/oradata/trgt/undotbs01.dbf',
'?/oradata/trgt/cwmlite01.dbf', '?/oradata/trgt/drsys01.dbf',
'?/oradata/trgt/example01.dbf', '?/oradata/trgt/indx01.dbf',
'?/oradata/trgt/tools01.dbf', '?/oradata/trgt/users01.dbf';
Perform the restore and recovery operation described in "Performing Disaster Recovery".
After connecting to the target database and recovery catalog, run a LIST command to see a listing of datafile copies and their associated primary keys, as in the following example:
LIST COPY;
Copy the datafile copies to the new host with an operating system utility. For example, in UNIX: % cp -r /tmp/*dbf /net/new_host/oracle/oradata/trgt
Start RMAN and then uncatalog the datafile copies on the old host. For example, enter: CHANGE COPY OF DATAFILE 1,2,3,4,5,6,7,8 UNCATALOG;
Catalog the datafile copies, using their new filenames or CATALOG START WITH (if you know all the files are in directories with a common prefix easily addressed with a CATALOG START WITH). For example, run:
CATALOG START WITH '?/oradata/trgt/';
Or this example specifies files individually:
CATALOG DATAFILECOPY
'?/oradata/trgt/system01.dbf', '?/oradata/trgt/undotbs01.dbf',
'?/oradata/trgt/cwmlite01.dbf', '?/oradata/trgt/drsys01.dbf',
'?/oradata/trgt/example01.dbf', '?/oradata/trgt/indx01.dbf',
'?/oradata/trgt/tools01.dbf', '?/oradata/trgt/users01.dbf';
Perform the restore and recovery operation described in "Performing Disaster Recovery".
Recovering Blocks Listed in V$DATABASE_BLOCK_CORRUPTION
The V$DATABASE_BLOCK_CORRUPTION view indicates which blocks in a datafile were marked corrupt since the most recent BACKUP or BACKUP VALIDATE command was run. After a corrupt block is repaired, the row identifying this block is deleted from the view.
You can check for logical corruption in the database by running the BACKUP (with or without VALIDATE option) with the CHECK LOGICAL command. If RMAN finds corrupt blocks, then it populates V$DATABASE_BLOCK_CORRUPTION. The backup will stop if the number of corrupt blocks exceeds MAXCORRUPT. A historical record of block corruptions in RMAN backups is kept in V$BACKUP_CORRUPTION and V$COPY_CORRUPTION.
In this scenario, you identify the blocks that require recovery by querying V$DATABASE_BLOCK_CORRUPTION, and then instruct RMAN to recover all blocks listed in this view by means of the CORRUPTION LIST keyword.
To recover datablocks while limiting the type of backup:
Query V$DATABASE_BLOCK_CORRUPTION to determine whether corrupt blocks exist in the most recent backups of the datafiles: SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
Assuming that you have preallocated automatic channels, recover all blocks marked corrupt in V$DATABASE_BLOCK_CORRUPTION by running the BLOCKRECOVER CORRUPTION LIST command. For example, this command restores blocks from backups created more than 10 days ago: BLOCKRECOVER CORRUPTION LIST
RESTORE UNTIL TIME 'SYSDATE-10';
You can check for logical corruption in the database by running the BACKUP (with or without VALIDATE option) with the CHECK LOGICAL command. If RMAN finds corrupt blocks, then it populates V$DATABASE_BLOCK_CORRUPTION. The backup will stop if the number of corrupt blocks exceeds MAXCORRUPT. A historical record of block corruptions in RMAN backups is kept in V$BACKUP_CORRUPTION and V$COPY_CORRUPTION.
In this scenario, you identify the blocks that require recovery by querying V$DATABASE_BLOCK_CORRUPTION, and then instruct RMAN to recover all blocks listed in this view by means of the CORRUPTION LIST keyword.
To recover datablocks while limiting the type of backup:
Query V$DATABASE_BLOCK_CORRUPTION to determine whether corrupt blocks exist in the most recent backups of the datafiles: SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
Assuming that you have preallocated automatic channels, recover all blocks marked corrupt in V$DATABASE_BLOCK_CORRUPTION by running the BLOCKRECOVER CORRUPTION LIST command. For example, this command restores blocks from backups created more than 10 days ago: BLOCKRECOVER CORRUPTION LIST
RESTORE UNTIL TIME 'SYSDATE-10';
Performing Disaster Recovery
If you are in a disaster recovery scenario, then presumably you have lost the target database, the recovery catalog database, all control files, all online redo logs, and all parameter files.
To perform a disaster recovery, the minimum required set of backups is backups of some datafiles, some archived redo logs generated after the time of the backup, and at least one autobackup of the control file.
See Also:
"Control File and Server Parameter File Autobackups"
The basic procedure for disaster recovery is found in "Performing Recovery with a Backup Control File", with an additional first step of restoring an autobackup of the server parameter file as described in Oracle Database Backup and Recovery Basics. After the instance is started, you can restore an autobackup of the control file, mount it, then restore and recover the datafiles. Because you are restoring to a new host, you should review the considerations described in "Restoring the Database to a New Host".
The following scenario restores and recovers the database to the most recently available archived log, which in this example is log 1124 in thread 1. It assumes that:
You are restoring the database to a new host with the same directory structure.
You have one tape drive containing backups of all the datafiles and archived redo logs through log 1124, as well as autobackups of the control file and server parameter file.
You do not use a recovery catalog.
In this scenario, perform the following steps:
If possible, restore all relevant network files such as tnsnames.ora and listener.ora by means of operating system utilities.
Start RMAN and connect to the target database. If you do not have the Oracle Net files, then connect through operating system authentication.
Specify the DBID for the target database with the SET DBID command, as described in "Performing Recovery with a Backup Control File and No Recovery Catalog".
Run the STARTUP NOMOUNT command. RMAN attempts to start the instance with a dummy server parameter file.
Allocate a channel to the media manager and then run the RESTORE SPFILE FROM AUTOBACKUP command.
Run STARTUP FORCE NOMOUNT mode so that the instance is restarted with the restored server parameter file.
Allocate a channel to the media manager and then restore a control file autobackup (refer to"Performing Recovery with a Backup Control File and No Recovery Catalog").
Mount the restored control file.
Catalog any backups not recorded in the repository with the CATALOG command (refer to"Removing Recovery Catalog Records with Status DELETED").
Restore the datafiles to their original locations. If volume names have changed, then run SET NEWNAME commands before the restore and perform a switch after the restore to update the control file with the new locations for the datafiles (refer to"Performing Disaster Recovery").
Recover the datafiles. RMAN stops recovery when it reaches the log sequence number specified.
Open the database in RESETLOGS mode. Only complete this last step if you are certain that no other archived logs can be applied. # Start RMAN and connect to the target database
% rman TARGET SYS/oracle@trgt
# Set the DBID for the target database
RMAN> SET DBID 676549873;
RMAN> STARTUP FORCE NOMOUNT; # rman starts instance with dummy parameter file
RUN
{
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
RESTORE SPFILE FROM AUTOBACKUP;
}
# Restart instance with restored server parameter file
RMAN> STARTUP FORCE NOMOUNT;
RMAN> RUN
{
# Manually allocate a channel to the media manager
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
# Restore autobackup of the control file. This example assumes that you have
# accepted the default format for the autobackup name.
RESTORE CONTROLFILE FROM AUTOBACKUP;
# The set until command is used in case the database
# structure has changed in the most recent backups, and you wish to
# recover to that point-in-time. In this way RMAN restores the database
# to the same structure that the database had at the specified time.
ALTER DATABASE MOUNT;
SET UNTIL SEQUENCE 1124 THREAD 1;
RESTORE DATABASE;
RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS; # Reset the online logs after recovery
completes
The following example of the RUN command shows the same scenario except with new filenames for the restored datafiles:RMAN> RUN
{
# If you need to restore the files to new locations, tell Recovery Manager
# to do this using SET NEWNAME commands:
SET NEWNAME FOR DATAFILE 1 TO '/dev/vgd_1_0/rlvt5_500M_1';
SET NEWNAME FOR DATAFILE 2 TO '/dev/vgd_1_0/rlvt5_500M_2';
SET NEWNAME FOR DATAFILE 3 TO '/dev/vgd_1_0/rlvt5_500M_3';
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
SET UNTIL SEQUENCE 124 THREAD 1;
RESTORE DATABASE;
SWITCH DATAFILE ALL; # Update control file with new location of datafiles.
RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS;
To perform a disaster recovery, the minimum required set of backups is backups of some datafiles, some archived redo logs generated after the time of the backup, and at least one autobackup of the control file.
See Also:
"Control File and Server Parameter File Autobackups"
The basic procedure for disaster recovery is found in "Performing Recovery with a Backup Control File", with an additional first step of restoring an autobackup of the server parameter file as described in Oracle Database Backup and Recovery Basics. After the instance is started, you can restore an autobackup of the control file, mount it, then restore and recover the datafiles. Because you are restoring to a new host, you should review the considerations described in "Restoring the Database to a New Host".
The following scenario restores and recovers the database to the most recently available archived log, which in this example is log 1124 in thread 1. It assumes that:
You are restoring the database to a new host with the same directory structure.
You have one tape drive containing backups of all the datafiles and archived redo logs through log 1124, as well as autobackups of the control file and server parameter file.
You do not use a recovery catalog.
In this scenario, perform the following steps:
If possible, restore all relevant network files such as tnsnames.ora and listener.ora by means of operating system utilities.
Start RMAN and connect to the target database. If you do not have the Oracle Net files, then connect through operating system authentication.
Specify the DBID for the target database with the SET DBID command, as described in "Performing Recovery with a Backup Control File and No Recovery Catalog".
Run the STARTUP NOMOUNT command. RMAN attempts to start the instance with a dummy server parameter file.
Allocate a channel to the media manager and then run the RESTORE SPFILE FROM AUTOBACKUP command.
Run STARTUP FORCE NOMOUNT mode so that the instance is restarted with the restored server parameter file.
Allocate a channel to the media manager and then restore a control file autobackup (refer to"Performing Recovery with a Backup Control File and No Recovery Catalog").
Mount the restored control file.
Catalog any backups not recorded in the repository with the CATALOG command (refer to"Removing Recovery Catalog Records with Status DELETED").
Restore the datafiles to their original locations. If volume names have changed, then run SET NEWNAME commands before the restore and perform a switch after the restore to update the control file with the new locations for the datafiles (refer to"Performing Disaster Recovery").
Recover the datafiles. RMAN stops recovery when it reaches the log sequence number specified.
Open the database in RESETLOGS mode. Only complete this last step if you are certain that no other archived logs can be applied. # Start RMAN and connect to the target database
% rman TARGET SYS/oracle@trgt
# Set the DBID for the target database
RMAN> SET DBID 676549873;
RMAN> STARTUP FORCE NOMOUNT; # rman starts instance with dummy parameter file
RUN
{
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
RESTORE SPFILE FROM AUTOBACKUP;
}
# Restart instance with restored server parameter file
RMAN> STARTUP FORCE NOMOUNT;
RMAN> RUN
{
# Manually allocate a channel to the media manager
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
# Restore autobackup of the control file. This example assumes that you have
# accepted the default format for the autobackup name.
RESTORE CONTROLFILE FROM AUTOBACKUP;
# The set until command is used in case the database
# structure has changed in the most recent backups, and you wish to
# recover to that point-in-time. In this way RMAN restores the database
# to the same structure that the database had at the specified time.
ALTER DATABASE MOUNT;
SET UNTIL SEQUENCE 1124 THREAD 1;
RESTORE DATABASE;
RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS; # Reset the online logs after recovery
completes
The following example of the RUN command shows the same scenario except with new filenames for the restored datafiles:RMAN> RUN
{
# If you need to restore the files to new locations, tell Recovery Manager
# to do this using SET NEWNAME commands:
SET NEWNAME FOR DATAFILE 1 TO '/dev/vgd_1_0/rlvt5_500M_1';
SET NEWNAME FOR DATAFILE 2 TO '/dev/vgd_1_0/rlvt5_500M_2';
SET NEWNAME FOR DATAFILE 3 TO '/dev/vgd_1_0/rlvt5_500M_3';
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
SET UNTIL SEQUENCE 124 THREAD 1;
RESTORE DATABASE;
SWITCH DATAFILE ALL; # Update control file with new location of datafiles.
RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS;
Subscribe to:
Posts (Atom)