Restore RMAN backup into different directories
When we backup the database on one machine, sometimes it is required that we need to restore on different servers or different directories. Here I am explaining how to restore rman backup into different directory structure.
1. First, we need to restore controlfiles either from autobackup or any controlfile backup piece.
RMAN. restore controlfile from ‘/oradata/backup/FXPROD_RMAN_BK20100305/s_714092907.4880.714095989′;
2. Mount the database and register database backup pieces into controlfile.
RMAN> alter database mount;
RMAN> catalog backuppiece ‘/oradata/backup/FXPROD_RMAN_BK20100305/nnndf0_DB_20100305_0.2647.712885159′;
RMAN> catalog backuppiece ‘/oradata/backup/FXPROD_RMAN_BK20100305/nnndf0_DB_20100305_0.3793.712885155′;
3. Restore datafiles to new locations
RMAN> run {
set newname for datafile 1 to ‘/oradata/FXPROD/datafile/system.275.690583539′;
set newname for datafile 3 to ‘/oradata/FXPROD/datafile/sysaux.276.690583523′;
set newname for datafile 5 to ‘/oradata/FXPROD/datafile/users.271.690583547′;
set newname for datafile 4 to ‘/oradata/FXPROD/datafile/db_idx_1.296.690582851′;
set newname for datafile 6 to ‘/oradata/FXPROD/datafile/db_1.295.690582851′;
restore database;
switch datafile all;
recover database;
alter database open resetlogs;
}
RMAN – Backup & Restore database using Tag
Sometimes, it is necessary to backup a snapshot of a database and may need to restore exactly at that point in a real life. For example, even in my case, I had many chances that I had to backup a database before the software upgrade and had to restore exactly at the point of the backup if it fails.
The easiest way to do it is to backup the whole database directory to other name after the database shutdown and simply rename it if you need to rollback when you run oracle database on file system. But this option may not be available when you use ASM since ASM doesn’t support copy or move command from asmcmd utility. So, Rman would be the only case to do any work in this case.
We can use RMAN’s Tag function to accomplish this type of task and here are the backup and restore command that you can make use of Tag command.
|
RMAN> BACKUP DATABASE TAG ‘BACKUP_2010_01_27′;
To get the information of a specific entities, you can use rman’s list command like below. RMAN> LIST BACKUP OF DATABASE; RMAN> RESTORE DATABASE FROM TAG ‘BACKUP_2010_01_27′; |
Block Media Recovery(BMR)
Block Media Recovery is very useful when you have block corruption(s). Instead of restoring and recovering entire file(s), you can use Block Media Recovery(BMR) to restore and recovery from block level.
You can query V$BACKUP_CORRUPTION and V$COPY_CURRPITION or just check alert.log file.
RMAN> BLOCKRECOVER DATAFILE 1 BLOCK 101,102,103 DATAFILE 2 BLOCK 201,202,203;
- You can only perform a complete recovery of a block
- You can only perform a block media recovery from a full backup; you cannot do this from incremental backups.
Useful RMAN commands
1. Remove a configuration
- To reset default device type to default.
RMAN> CONFIGURE DEFAULT DEVICE TYPE CLEAR;
2. Exclude read-only tablespace
RMAN> CONFIGURE EXCLUDE FOR TABLESPACE My_tblsp;
- To reset excluded tablespac
RMAN> CONFIGURE EXCLUDE FOR TABLESPACE My_tblsp CLEAR;
3. Restartable Backups
- Backup files which are not backed up since 7 days ago
RMAN> BACKUP DATABASE NOT BACKED UP SINCE TIME ‘sysdate – 7′;
- Backup files which are not backed up ever.
RMAN> BACKUP DATABASE NOT BACKED UP;
4. Report
- Report obsolete backups that are not required to keep the database recoverable within a particular window of time.
RMAN> REPORT OBSOLETE RECOVERY WINDOW 7 DAYS;
- Report files which need to be backed up to keep particular recovery window.
RMAN> REPORT NEED BACKUP RECOVERY WINDOW 7 DAYS;
5. List
By backup is default.
RMAN> LIST BACKUP [BY BACKUP];
RMAN> LIST BACKUP BY FILE;
RMAN – ARCHIVELOG DELETE POLICY
The 10g RMAN-Data Guard(attached) paper states that ‘archive log deletion policy applied on standby’ only checks that a log has been applied on all mandatory standby databases.
However, Data Guard best practice for Max Performance and Max Availability modes is to *not* use mandatory standby (so that primary does not hang in the event of online logs filling up). Therefore, the following parameter must be set:
SQL> alter system set "_log_deletion_policy"=ALL scope=spfile sid='*';
NOTE: attempt to set this configuration in RMAN without this parameter setting may result in error:
RMAN> configure archivelog deletion policy to applied on standby;
new RMAN configuration parameters:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
What are the various % format code used during RMAN backups
RMAN format codes are evaluated at RMAN execution time, these are typically used to generate unique backup set attributes (TAG, FORMAT, etc). The entire “FORMAT ” string is processed in a port-specific manner by the target instance to derive the final backup piece name. The following substitution variables are available to aid in generating unique filenames. The formatting of this information varies by platform.
Format Explanation
%a ———— Specifies the activation ID of the database
%c ———— Specifies the copy number of the backup piece within a set of duplexed
backup pieces. If you did not duplex a backup, then this variable is 1 for
backup sets and 0 for proxy copies. If one of these commands is enabled, then
the variable shows the copy number. The maximum value for %c is 256.
%d ———— Specifies the name of the database
%D ———— Specifies the current day of the month from the Gregorian calender in format DD
%e ———— Specifies the archived log sequence number
%f ———— Specifies the absolute file number
%F ———— Combines the DBID, day, month, year, and sequence into a unique and
repeatable generated name. This variable translates into c-IIIIIIIIII-YYYYMMDD-
QQ, where: IIIIIIIIII stands for the DBID. The DBID is printed in decimal so that it can
be easily associated with the target database. YYYYMMDD is a time stamp in the Gregorian calendar of the day the backup is generated QQ is the sequence in hexadecimal number that starts with 00 and has a maximum of FF (256)
%h ———— Specifies the archived redo log thread number
%I ———— Specifies the DBID
%M ———— Specifies the month in the Gregorian calendar in format MM
%N ———— Specifies the tablespace name
%n ———— Specifies the name of the database, padded on the right with x characters
to a total length of eight characters. For example, if the prod1 is the
database name, then the padded name is prod1xxx.
%p ———— Specifies the piece number within the backup set. This value starts at 1
for each backup set and is incremented by 1 as each backup piece is created
%s ———— Specifies the backup set number. This number is a counter in the control
file that is incremented for each backup set. The counter value starts at 1 and
is unique for the lifetime of the control file. If you restore a backup control
file, then duplicate values can result. Also, CREATE CONTROLFILE initializes
the counter back to 1
%t ———— Specifies the backup set time stamp, which is a 4-byte value derived as the
number of seconds elapsed since a fixed reference time. The combination of %s
and %t can be used to form a unique name for the backup set
%T ———— Specifies the year, month and day in the Gregorian calendar in this format: YYYYMMDD
%u ———— Specifies an 8-character name constituted by compressed representations of
the backup set or image copy number and the time the backup set or image copy
was created
%U ———— Specifies a system-generated unique filename (default). The meaning of %U
is different for image copies and backup pieces.
For a backup piece %U specifies a convenient shorthand for %u_%p_%c that
guarantees uniqueness in generated backup filenames.
If you do not specify a format when making a backup, then RMAN uses %U by default.
For an image copy of a datafile %U means the following:
data-D-%d_id-%I_TS-%N_FNO-%f_%u
For an image copy of an archived redo log %U means the following:
arch-D_%d-id-%I_S-%e_T-%h_A-%a_%u
For an image copy of a control file %U means the following:
cf-D_%d-id-%I_%u
%Y ———— Specifies the year in the format YYYY
%% ———— Specifies the ‘%’ character. For example, %%Y translates to the string %Y
Flashback database
1. Configuration
Initialization Parameters required: -
a) DB_RECOVERY_FILE_DEST (dynamically modifiable) –> Physical location where RVWR background process
writes flashback logs.
b) DB_RECOVERY_FILE_DEST_SIZE (dynamically modifiable) –> Maximum size flashback logs can occupy in
DB_RECOVERY_FILE_DEST.
c) DB_FLASHBACK_RETENTION_TARGET (dynamically modifiable) –> upper limit in minutes on how far back
one can flashback the database.
After setting these parameters in parameter file(init.ora) or spfile.
Note:- Clean shutdown is mandatory.
SQL> Startup mount;
SQL> Alter database flashback on;
SQL> Alter database open;
SQL> select flashback_on from v$database;
FLASHBACK_ON
————
YES
2. How to Flashback
2-1. Get the current milestone before process
Get either current_scn or current timestamp
SQL> SELECT CURRENT_SCN FROM V$DATABASE;
CURRENT_SCN
———–
1768133
SQL> SELECT TO_CHAR(SYSDATE,’yyyy/mm/dd hh24:mi:ss’) CURRENT_TIME
FROM DUAL;
CURRENT_TIME
—————-
2006/08/30 17:40:30
2-2. Process Deployment
2-3. In case of failure, capture the timestamp or scn again
so that in case if we need to come to this point we can use it.
SQL> SELECT CURRENT_SCN FROM V$DATABASE;
CURRENT_SCN
———–
1782638
SQL> SELECT TO_CHAR(SYSDATE,’yyyy/mm/dd hh24:mi:ss’) CURRENT_TIME
FROM DUAL;
CURRENT_TIME
—————-
2006/08/30 18:40:30
SQL> shutdown immediate;
SQL> startup mount
SQL> flashback database to scn 1768133;
or
SQL> flashback database to timestamp(to_date(’2006/08/30 17:40:30′,’yyyy/mm/dd hh24:mi:ss’));
SQL> alter database open read only
–> Verify if the database is fine.
SQL> shutdown
SQL> startup mount
SQL> alter database open resetlogs;
Note : Once the alter database open resetlogs command has been issued, the database changes cannot be altered.
3. Manage space on flashback area
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
Method 4:
–> Check available space from flashback recovery area
SQL> select * from v$recovery_file_dest;
3-1. Delete backupset from flashback area
$ rm *
RMAN> crosscheck backupset;
RMAN> delete expired backupset;
3-2. Delete archivelog logs
$ rm *
RMAN> crosscheck archivelog all;
RMAN> delete expired archivelog all;
–> Check available space from flashback recovery area
SQL> select * from v$recovery_file_dest;
SQL> select sum(PERCENT_SPACE_USED) flashback_area_used from v$flash_recovery_area_usage
/
USEFUL VIEWS
v$recovery_file_dest
v$flash_recovery_area_usage
v$flashback_database_stat
v$flashback_database_log
v$flashback_database_logfile
Recovery Manager
Benefits of RMAN Backups vs. Scripted Backups
- RMAN will detect corrupted blocks and report them to you
- RMAN can backup your database online without having to put the tablespace in hot backup mode. Thus, the additional redo generated during a hot backup is reduced.
- RMAN will automatically track new datafiles and tablespaces for you, which means you no longer have to add new tablespaces or datafiles to scripts.
- RMAN will only backup used data blocks(up to the high water mark(HWM). Thus, RMAN backup images typically are smaller than those of online backup scripts.
- See the current default value
RMAN> show default device type;
RMAN> show maxsetsize;
RMAN> show retention policy;
RMAN> show all;
- Configure/ Change default value
RMAN> configure default device type to disk;
RMAN> configure default device type to sbt;
RMAN> configure device type disk parallelism 2 ;
RMAN> configure channel 1 device type disk format ‘/db/backup/FXPROD/backup_%u’;
RMAN> configure channel 2 device type disk format ‘/db/backup/FXPROD/backup_%u’;
RMAN> configure maxsetsize to 8192M;
Backup optimization will cause Oracle to skip backups of files that already have identical backups on the device being backuped up to.
RMAN> configure backup optimization on;
- Automated Backups of the Control file and the database parameter file
RMAN> configure controlfile autobackup on;
RMAN> configure controlfile autobackup off;
RMAN> configure controlfile autobackup format for device type disk to ‘/home/backup/control_%F’;
When this option is used, the Oracle RDBMS will automatically back up the control file during database structure changes that impact the control file.
- Backup Retention Policy
RMAN> configure retention policy to redundancy 3;
If you want to disable the retention policy, you use the command configure retention policy to none, and no retention policy will be applicable. Use the configure retention policy clear command to reset the retention policy to the default value.
RMAN> report obsolete;
RMAN> delete obsolete;
If any of the listed objects are not available to be removed, then you will need to run the crosscheck command.
- Offline RMAN Database Backups
Example1: Cold backup
|
RMAN> shutdown immediate RMAN> startup mount RMAN> run { Backup database Backup current controlfile; } |
Example2: Hot backup
|
RMAN> run { backup database; sql “alter system archive log current”; backup archivelog all skip inaccessible; backup current controlfile; }
crosscheck backup crosscheck archivelog all;
delete noprompt obsolete; delete noprompt expired backupset; delete expired archivelog all; delete noprompt archivelog until time ‘SYSDATE-5’; |
- Crash Recovery Scenario
Below are the most common three scenario which we can think of in a normal recovery case. All these scenario is verified on our environment and below are the procedures of crash and recovery case.
6.1 Recover a datafile
Since we have only one datafile damaged the database can still be up and running and serve other application area which doesn’t not use table on damaged datafiles. Recovery can also be done while the database is running and serving other sessions.
|
1) Deleted 1 datafile from the OS to simulate datafile crash scenario # rm /home/app/oracle/oradata/FXPROD/tools_FXPROD01.dbf
2) We got below error when we tried to query table on the file. SQL> SELECT COUNT(*) FROM TEST; ERROR at line 1: ORA-01116: error in opening database file 6 ORA-01110: data file 6: ‘/home/app/oracle/oradata/FXPROD/tools_FXPROD01.dbf’ ORA-27041: unable to open file Linux Error: 2: No such file or directory Additional information: 3
3) Check if backupset of that datafile is available from RMAN à From below output we noticed that we have backupset 17 which was taken on March 17th and it has full copy datafile 6.
RMAN> list backup of datafile 6; List of Backup Sets ===================
BS Key Type LV Size Device Type Elapsed Time Completion Time ——- —- — ———- ———– ———— ————— 11 Full 988M DISK 00:04:55 13-MAR-07 BP Key: 6 Status: AVAILABLE Tag: TAG20070313T124005 Piece Name: /home/backup/backup_0cicgs0f List of Datafiles in backup set 11 File LV Type Ckp SCN Ckp Time Name —- — —- ———- ——— —- 6 Full 1783682409 13-MAR-07 /home/app/oracle/oradata/FXPROD/tools_FXPROD01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time ——- —- — ———- ———– ———— ————— 17 Full 988M DISK 00:04:56 13-MAR-07 BP Key: 12 Status: AVAILABLE Tag: TAG20070313T141929 Piece Name: /home/backup/backup_0iich1n2 List of Datafiles in backup set 17 File LV Type Ckp SCN Ckp Time Name —- — —- ———- ——— —- 6 Full 1783687547 13-MAR-07 /home/app/oracle/oradata/FXPROD/tools_FXPROD01.dbf
4) Make the datafile offline and restore datafile 6 from the backup staging area. RMAN> sql ‘alter database datafile 6 offline’; RMAN> restore datafile 6; Starting restore at 14-MAR-07
allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=19 devtype=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: sid=11 devtype=DISK channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00006 to /home/app/oracle/oradata/FXPROD/tools_FXPROD01.dbf channel ORA_DISK_1: restored backup piece 1 piece handle=/home/backup/backup_0iich1n2 tag=TAG20070313T141929 params=NULL channel ORA_DISK_1: restore complete Finished restore at 14-MAR-07
5) Recover datafile 6 using existing archived logfiles and make the datafile 6 online; RMAN> recover datafile 6; Starting recover at 14-MAR-07 using channel ORA_DISK_1 using channel ORA_DISK_2
starting media recovery media recovery complete
Finished recover at 14-MAR-07
RMAN> sql ‘alter database datafile 6 online’;
5) Verify if the datafile is recoverd SQL> SELECT COUNT(*) FROM TEST; COUNT(*) ———- 2010000 |
6.2 Recover a tablespace
Recovering database from a tablespace level is practically same as “Datafile Level Recovey” but if you want to recover from the tablespace level and block the access to the tablespace which has damaged datafile then you can perform tablespace level recovery.
|
1) Deleted 1 datafile from the OS to simulate datafile crash scenario # rm /home/app/oracle/oradata/FXPROD/tools_FXPROD01.dbf
2) We got below error when we tried to query table on the file. SQL> SELECT COUNT(*) FROM TEST; ERROR at line 1: ORA-01116: error in opening database file 6 ORA-01110: data file 6: ‘/home/app/oracle/oradata/FXPROD/tools_FXPROD01.dbf’ ORA-27041: unable to open file Linux Error: 2: No such file or directory Additional information: 3
3) Check if backupset of a tablespace if you know the tablespace name that it involved. à From below output we noticed that we have backupset 17 which was taken on March 17th and it has full copy datafile 6.
RMAN> list backup of tablespace tools;
List of Backup Sets ===================
BS Key Type LV Size Device Type Elapsed Time Completion Time ——- —- — ———- ———– ———— ————— 11 Full 988M DISK 00:04:55 13-MAR-07 BP Key: 6 Status: AVAILABLE Tag: TAG20070313T124005 Piece Name: /home/backup/backup_0cicgs0f List of Datafiles in backup set 11 File LV Type Ckp SCN Ckp Time Name —- — —- ———- ——— —- 6 Full 1783682409 13-MAR-07 /home/app/oracle/oradata/FXPROD/tools_FXPROD01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time ——- —- — ———- ———– ———— ————— 17 Full 988M DISK 00:04:56 13-MAR-07 BP Key: 12 Status: AVAILABLE Tag: TAG20070313T141929 Piece Name: /home/backup/backup_0iich1n2 List of Datafiles in backup set 17 File LV Type Ckp SCN Ckp Time Name —- — —- ———- ——— —- 6 Full 1783687547 13-MAR-07 /home/app/oracle/oradata/FXPROD/tools_FXPROD01.dbf
4) Put the datafile(s) offline and Restore datafile(s) which has involved in TOOLS tablespace. RMAN> sql ‘alter database datafile 6 offline’; RMAN> restore tablespace tools Starting restore at 14-MAR-07
using channel ORA_DISK_1 using channel ORA_DISK_2 channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00006 to /home/app/oracle/oradata/FXPROD/tools_FXPROD01.dbf channel ORA_DISK_1: restored backup piece 1 piece handle=/home/backup/backup_0iich1n2 tag=TAG20070313T141929 params=NULL channel ORA_DISK_1: restore complete Finished restore at 14-MAR-07
5) Recover tools tablespace using existing archived logfiles and make the datafile 6 online; RMAN> recover tablespace tools Starting recover at 14-MAR-07 using channel ORA_DISK_1 using channel ORA_DISK_2
starting media recovery media recovery complete
Finished recover at 14-MAR-07
RMAN> sql ‘alter database datafile 6 online’;
4) Verify if the datafile is recoverd SQL> SELECT COUNT(*) FROM TEST; COUNT(*) ———- 2010000 |
6.3 Recover database
Database level recovery can be performed in case if you damaged majority of datafiles from a database. In case of full database recovery we may have 3 cases based on how much damage the database has. First you may still have control file(s) or online redo logfiles while you lost majority of the datafiles. Second you may still have control files while you have damaged your online redo log files and datafiles. In this case you are not able to fully recover your database up to the point of failure and you may lose some transactions which has not been archived but in the online redo log files. Third, you may be damaged all the control files , online redo log files and even datafiles. In this case you need to restore controlfiles in addition to the datafiles. Because of lack of online redo log files you are not able to fully recover your database and some of the transactions which was not archived at the time of failure will be lost in this case.
6.3.1 Restore control file from autobackup if you lost them.
|
1) Startup the database with nomount mode SQL> startup nomount
2) Identify your DBID from the control file auto backup # cd /home/backup # ls –l con* -rw-r—– 1 oracle dba 1671168 Mar 13 14:43 control_c-2909669370-20070313-02 -rw-r—– 1 oracle dba 1671168 Mar 13 14:43 control_c-2909669370-20070313-03 -rw-r—– 1 oracle dba 1671168 Mar 14 10:26 control_c-2909669370-20070314-00 -rw-r—– 1 oracle dba 1671168 Mar 14 11:39 control_c-2909669370-20070314-01 * Your DBID is 2909669370
3) Restore your control from controlfile auto backup # rman target / RMAN> set DBID=2909669370 RMAN> run { set controlfile autobackup format for device type disk to ‘/home/backup/control_%F’; restore controlfile from autobackup; }
executing command: SET CONTROLFILE AUTOBACKUP FORMAT using target database controlfile instead of recovery catalog
Starting restore at 14-MAR-07
allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=13 devtype=DISK channel ORA_DISK_1: looking for autobackup on day: 20070314 channel ORA_DISK_1: autobackup found: /home/backup/control_c-2909669370-20070314-01 channel ORA_DISK_1: controlfile restore from autobackup complete replicating controlfile input filename=/home/app/oracle/oradata/FXPROD/control01.ctl output filename=/home/app/oracle/oradata/FXPROD/control02.ctl output filename=/home/app/oracle/oradata/FXPROD/control03.ctl Finished restore at 14-MAR-07
4) Mount the database and Restore database files RMAN> sql ‘alter database mount’; RMAN> restore database; Starting restore at 14-MAR-07
allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=11 devtype=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: sid=8 devtype=DISK channel ORA_DISK_2: starting datafile backupset restore channel ORA_DISK_2: specifying datafile(s) to restore from backup set restoring datafile 00018 to /home/app/oracle/oradata/FXPROD/trade_1_FXPROD01.dbf restoring datafile 00025 to /home/app/oracle/oradata/FXPROD/trade_idx_2_FXPROD01.dbf channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00002 to /home/app/oracle/oradata/FXPROD/undotbs_FXPROD01.dbf restoring datafile 00004 to /home/app/oracle/oradata/FXPROD/example_FXPROD01.dbf restoring datafile 00005 to /home/app/oracle/oradata/FXPROD/indx_FXPROD01.dbf restoring datafile 00008 to /home/app/oracle/oradata/FXPROD/xdb_FXPROD01.dbf restoring datafile 00012 to /home/app/oracle/oradata/FXPROD/currenex_idx_1_FXPROD01.dbf restoring datafile 00019 to /home/app/oracle/oradata/FXPROD/trade_1_FXPROD02.dbf channel ORA_DISK_1: restored backup piece 1 piece handle=/home/backup/backup_0fich0jh tag=TAG20070313T141929 params=NULL channel ORA_DISK_1: restore complete channel ORA_DISK_2: restored backup piece 1 piece handle=/home/backup/backup_0eich0jh tag=TAG20070313T141929 params=NULL channel ORA_DISK_2: restore complete channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00001 to /home/app/oracle/oradata/FXPROD/system_FXPROD01.dbf restoring datafile 00007 to /home/app/oracle/oradata/FXPROD/users_FXPROD01.dbf restoring datafile 00013 to /home/app/oracle/oradata/FXPROD/currenex_lob_1_FXPROD01.dbf restoring datafile 00014 to /home/app/oracle/oradata/FXPROD/cust_settle_1_FXPROD01.dbf restoring datafile 00022 to /home/app/oracle/oradata/FXPROD/trade_1_FXPROD03.dbf channel ORA_DISK_2: starting datafile backupset restore channel ORA_DISK_2: specifying datafile(s) to restore from backup set restoring datafile 00003 to /home/app/oracle/oradata/FXPROD/drsys_FXPROD01.dbf restoring datafile 00010 to /home/app/oracle/oradata/FXPROD/bank_settle_idx_1_FXPROD01.dbf restoring datafile 00011 to /home/app/oracle/oradata/FXPROD/currenex_1_FXPROD01.dbf restoring datafile 00015 to /home/app/oracle/oradata/FXPROD/cust_settle_idx_1_FXPROD01.dbf restoring datafile 00016 to /home/app/oracle/oradata/FXPROD/ips_data_FXPROD01.dbf restoring datafile 00023 to /home/app/oracle/oradata/FXPROD/trade_idx_1_FXPROD01.dbf channel ORA_DISK_1: restored backup piece 1 piece handle=/home/backup/backup_0gich15r tag=TAG20070313T141929 params=NULL channel ORA_DISK_1: restore complete channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00006 to /home/app/oracle/oradata/FXPROD/tools_FXPROD01.dbf restoring datafile 00009 to /home/app/oracle/oradata/FXPROD/bank_settle_1_FXPROD01.dbf restoring datafile 00017 to /home/app/oracle/oradata/FXPROD/rptdata_FXPROD01.dbf restoring datafile 00020 to /home/app/oracle/oradata/FXPROD/trade_2_FXPROD01.dbf restoring datafile 00021 to /home/app/oracle/oradata/FXPROD/website_1_FXPROD01.dbf restoring datafile 00024 to /home/app/oracle/oradata/FXPROD/trade_idx_1_FXPROD02.dbf channel ORA_DISK_2: restored backup piece 1 piece handle=/home/backup/backup_0hich18h tag=TAG20070313T141929 params=NULL channel ORA_DISK_2: restore complete channel ORA_DISK_1: restored backup piece 1 piece handle=/home/backup/backup_0iich1n2 tag=TAG20070313T141929 params=NULL channel ORA_DISK_1: restore complete Finished restore at 14-MAR-07
5) Recover database and open it with resetlogs option RMAN> recover database; Starting recover at 14-MAR-07 using channel ORA_DISK_1 using channel ORA_DISK_2
starting media recovery
archive log thread 1 sequence 348 is already on disk as file /home/app/oracle/admin/FXPROD/archive/archive_1_348.arc archive log thread 1 sequence 349 is already on disk as file /home/app/oracle/admin/FXPROD/archive/archive_1_349.arc archive log filename=/home/app/oracle/admin/FXPROD/archive/archive_1_348.arc thread=1 sequence=348 archive log filename=/home/app/oracle/admin/FXPROD/archive/archive_1_349.arc thread=1 sequence=349 unable to find archive log archive log thread=1 sequence=350 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 03/14/2007 13:13:52 RMAN-06054: media recovery requesting unknown log: thread 1 scn 1783687800
RMAN> sql ‘alter database open resetlogs’;
6) Verify it SQL> SELECT COUNT(*) FROM TEST; COUNT(*) ———- 2010000 |
leave a comment