Rman - rolling foward with archive logs during recovery

Database: 9.2.0.6; OS Windows 2003, Rman Backups performed through OEM 10g.
I have been a long time "write your own scripts" for backups but now I'm learning rman. Purchased the Oracle Database 10g RMAN Backup and Recovery book, but it doesn't have all the answers.
I have previously recovered a database using my "scripts" and rolled the database forward using archive files, but how is this done with rman? Rman seems to rely on the control file and backup pieces, where the scripts allowed me to just specify "recover database until cancel".
I have successfully recovered a database. It stopped once it could no longer find the next scn number. I then thought I could copy over the archive logs I have and try it again, try to roll forward, however, during the recover process there were two archive files created which were the next sequence, so I have dupes.
How do I perform a recover, and apply any archives which were not part of the rman backup?
The following is what I performed. I copied all my rman backup pieces to a new server. I created a clone of the directory structure,
oradim -new -sid <dbname>
orapwd file=<file_name> password=tiger
set oracle_sid=<dbname>
rman target /
startup force nomount
restore spfile from <file_name>
shutdown immediate
startup nomount
restore controlfile from <file_name>
restore database
-- NOTE: It ran and then stopped when it could no longer file the next log sequence
alter database reset logs;
The database opened and I can access it, but I really need to roll the logs forward.
thanks in advance.

If these are archive logs that RMAN doesn't know about, you'll need to CATALOG these archivelogs before RMAN can use them.

Similar Messages

RMAN: How to apply Archive Logs after recoverying of all physical files

Hi;
I am using RMAN Oracle10g; my test database has being corrupted. I have already taken 0 level backup through this command
run {
allocate channel c1 type disk;
backup incremental level 0 tag = Test_Weekly_database format 'O:\rman\backup\Full_Weekly_%d_%s_%p_%t'(database);
release channel c1;
configure controlfile autobackup format for device type disk to 'O:\rman\backup\Auto_Ctrl_weekly_%F';
allocate channel c1 type disk;
sql 'alter system archive log current';
BACKUP tag = Test_Weekly_Arch ARCHIVELOG UNTIL TIME 'SYSDATE-7' format 'O:\rman\backup\Archive_weekly_%d_%s_%p_%t';
DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7';
release channel c1;
After backing up I inserted few records in TEST123 table. And switch current log file.
Then my database has been corrupted. Now I have last 0 level backup (RMAN) and archive logs files on OS level.
I am recovering my database with the following commands; but archive logs have not being applied. And my inserted records were not presented in TEST123 table.
Kindly guide me
SQL> startup nomount
CMD> RMAN target=/
RMAN>set DBID 1168995671
RMAN>RUN {
SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'O:\rman\backup\Auto_Ctrl_weekly_%F';
RESTORE CONTROLFILE from autobackup;
RMAN> ALTER DATABASE MOUNT;
RMAN> RESTORE DATABASE CHECK READONLY;
RMAN> RECOVER DATABASE NOREDO;
RMAN> restore archivelog all;
SQL> startup mount
SQL> alter database backup controlfile to trace;
SQL> shut immediate
SQL> startup nomount
SQL> CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS ARCHIVELOG................;
SQL> alter database open resetlogs
---Database altered.
SQL> select * from TEST123;
Not record found
regards;
Asim

Dear Khurram;
Kindly advise where i m worrg???????
C:\>RMAN target=/
RMAN> set DBID 1168995671
executing command: SET DBID
RMAN> RUN {
2> SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'O:\rman\backup\Auto_Ctrl_weekly_%F';
3> RESTORE CONTROLFILE from autobackup;
4> }
executing command: SET CONTROLFILE AUTOBACKUP FORMAT
Starting restore at 27-DEC-07
using channel ORA_DISK_1
recovery area destination: O:\rman\backup
database name (or database unique name) used for search: ORCL
channel ORA_DISK_1: no autobackups found in the recovery area
channel ORA_DISK_1: looking for autobackup on day: 20071227
channel ORA_DISK_1: autobackup found: O:\rman\backup\Auto_Ctrl_weekly_c-11689956
71-20071227-04
channel ORA_DISK_1: control file restore from autobackup complete
output filename=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL01.CTL
output filename=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL02.CTL
output filename=D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL03.CTL
Finished restore at 27-DEC-07
RMAN> ALTER DATABASE MOUNT;
database mounted
released channel: ORA_DISK_1
RMAN> RESTORE DATABASE CHECK READONLY;
Starting restore at 27-DEC-07
Starting implicit crosscheck backup at 27-DEC-07
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: sid=154 devtype=DISK
Crosschecked 9 objects
Finished implicit crosscheck backup at 27-DEC-07
Starting implicit crosscheck copy at 27-DEC-07
using channel ORA_DISK_1
using channel ORA_DISK_2
Finished implicit crosscheck copy at 27-DEC-07
searching for all files in the recovery area
cataloging files...
no files cataloged
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 00001 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
restoring datafile 00002 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
restoring datafile 00003 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
restoring datafile 00004 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
restoring datafile 00005 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEST.DBF
restoring datafile 00006 to D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEST2
channel ORA_DISK_1: reading from backup piece O:\RMAN\BACKUP\FULL_WEEKLY_ORCL_3_
1_642420573
channel ORA_DISK_1: restored backup piece 1
piece handle=O:\RMAN\BACKUP\FULL_WEEKLY_ORCL_3_1_642420573 tag=Test_WEEKLY_DATAB
ASE
channel ORA_DISK_1: restore complete, elapsed time: 00:00:46
Finished restore at 27-DEC-07
RMAN> restore archivelog all;
archive log thread 1 sequence 1 is already on disk as file O:\ARCHIVE\ARC00001_0642356125.001
archive log thread 1 sequence 2 is already on disk as file O:\ARCHIVE\ARC00002_0642356125.001
archive log thread 1 sequence 3 is already on disk as file O:\ARCHIVE\ARC00003_0642356125.001
archive log thread 1 sequence 4 is already on disk as file O:\ARCHIVE\ARC00004_0642356125.001
archive log thread 1 sequence 5 is already on disk as file O:\ARCHIVE\ARC00005_0642356125.001
archive log thread 1 sequence 6 is already on disk as file O:\ARCHIVE\ARC00006_0642356125.001
archive log thread 1 sequence 7 is already on disk as file O:\ARCHIVE\ARC00007_0642356125.001
archive log thread 1 sequence 8 is already on disk as file O:\ARCHIVE\ARC00008_0642356125.001
archive log thread 1 sequence 9 is already on disk as file O:\ARCHIVE\ARC00009_0642356125.001
archive log thread 1 sequence 10 is already on disk as file O:\ARCHIVE\ARC00010_0642356125.001
archive log thread 1 sequence 11 is already on disk as file O:\ARCHIVE\ARC00011_0642356125.001
archive log thread 1 sequence 12 is already on disk as file O:\ARCHIVE\ARC00012_0642356125.001
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=15
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=16
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=17
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=18
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=19
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=20
channel ORA_DISK_1: reading from backup piece O:\RMAN\BACKUP\ARCHIVE_WEEKLY_ORCL_5_1_642420630
channel ORA_DISK_1: restored backup piece 1
piece handle=O:\RMAN\BACKUP\ARCHIVE_WEEKLY_ORCL_5_1_642420630 tag=Test_WEEKLY_ARCH
channel ORA_DISK_1: restore complete, elapsed time: 00:00:08
Finished restore at 27-DEC-07
RMAN> ALTER DATABASE OPEN;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 12/27/2007 10:27:10
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF'
Regards;
Asim

How do I setup RMAN not to delete archive log files on the source database so GoldenGate can process DDL/DML changes?

I want to setup RMAN not to delete any archive log files that will be used by GoldenGate.   Once GoldenGate is completed with the archive log file, the archive log file can be backup and deleted by RMAN.   It's my understanding that I can issue the following command "REGISTER EXTRACT <ext_name>, LOGRETENTION" to enable to functionally.   Is this the only thing I need to do to execute to enable this functionally?

Hello,
Yes this is the rigth way using clasic capture.
Using the command : REGISTER EXTRACT Extract_name LOGRETENTION.
Create a Oracle Streams Group Capture (Artificial) that prevent RMAN archive deletion if these are pending to process for Golden Gate capture process.
You can see this integration doing a SELECT * FROM DBA_CAPTURE; after execute the register command.
Then, when RMAN try to delete a archive file pending to process for GG this warning appear AT RMAN logs:
Error:     RMAN 8317 (RMAN-08317 RMAN-8317)
Text:     WARNING: archived log not deleted, needed for standby or upstream capture process.
Then , this is a good manageability feature. I think is a 11.1 GG new feature.
Tip. To avoid RMAN backup multiples times a archive pending to process, there is a option called BACKUP archivelog not backed 1 times.
If you remove a Capture process that is registered with the database you need to use this comand to remove the streams capture group:
unREGISTER EXTRACT extract_name LOGRETENTION;
Then if you query dba_capture, the artificial Streams group is deleted.
I hope help.
Regards
Arturo

Are there any possible reason RMAN generates some corrupt archive log files

Dear all,
Are there any possible reason RMAN generates some corrupt archive log files?
Best Regards,
Amy

Because I try to perform daily backup at lunch time and found out it takes more than 1 hour had no any progress. Normally we take around 40 minus. The following is the log file:
RMAN> Run
2> {
3> CONFIGURE CONTROLFILE AUTOBACKUP ON;
4> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u03/db/backup/RMAN/%F.bck';
5> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 1 DAYS;
6> allocate channel ch1 type disk format '/u03/db/backup/RMAN/backup_%d_%t_%s_%p_%U.bck';
7> backup incremental level 1 cumulative database plus archivelog delete all input;
8> backup current controlfile;
9> backup spfile;
10> release channel ch1;
11> }
12> allocate channel for maintenance type disk;
13> delete noprompt obsolete;
14> delete noprompt archivelog all backed up 2 times to disk;
15>
16>
using target database controlfile instead of recovery catalog
old RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored
old RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u03/db/backup/RMAN/%F.bck';
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u03/db/backup/RMAN/%F.bck';
new RMAN configuration parameters are successfully stored
old RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 1 DAYS;
new RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 1 DAYS;
new RMAN configuration parameters are successfully stored
allocated channel: ch1
channel ch1: sid=99 devtype=DISK
Starting backup at 31-MAR-09
current log archived
After that I go to archive log directory "/u02/oracle/uat/uatdb/9.2.0/dbs" and use ls -lt command to see how many archive logs and my screen just hang. After we found out that we cannot use ls -lt command to read arch1_171.dbf
archive log, the rest of archive logs able to use ls -lt command.
We cannot delete this file as well. We shutdown database abort and perform check disk...... and fix the disk error and then open database again. Everything seems back to normal and we can use ls -lt command to read arch1_171.dbf.
The strange problem is we have the same problem in Development and Production..... one ore more archive logs seems to be corrupted under the same directories /u02/oracle/uat/uatdb/9.2.0/dbs.
Does anyone encounter the same problem?
Amy

RMAN-08591: WARNING: invalid archived log deletion policy

Hi,
My database is 11.2.0.1 running on OEL 5.
We have stndby database running on other server, i have configured rman like this
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
But while running db backup, getting the error
RMAN-08591: WARNING: invalid archived log deletion policy.
RMAN retention policy is set to redundancy 1.
The archive files are deleting even though they are not applied on standby.
Thanks,

kkrm333 wrote:
Hi,
My database is 11.2.0.1 running on OEL 5.
We have stndby database running on other server, i have configured rman like this
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
But while running db backup, getting the error
RMAN-08591: WARNING: invalid archived log deletion policy.
RMAN retention policy is set to redundancy 1.
The archive files are deleting even though they are not applied on standby.
Thanks,
bcm@bcm-laptop:~$ oerr rman 8591
8591, 3, "WARNING: invalid archived log deletion policy"
// *Cause: An invalid ARCHIVELOG DELETION POLICY was supplied. The archived
//         log deletion policy was APPLIED but there was no mandatory
//         archived log destinations.
// *Action: One of the following:
//          1) Change archived log deletion policy using CONFIGURE command
//          2) Make one or more of standby destination as MANDATORY.

COLD BACKUP을 받은 후 ARCHIVE LOG로 변환하여 사용한 경우 INCOMPLETE RECOVERY.

제품 : ORACLE SERVER
작성날짜 : 2002-04-09
COLD BACKUP을 받은 후 ARCHIVE LOG로 변환하여 사용한 경우 INCOMPLETE RECOVERY.
======================================================================
PURPOSE
COLD BACKUP을 받은 후 ARCHIVE LOG MODE로 변환하여 사용한 경우의 RECOVERY
과정을 TEST로 확인하여 본다.
Examples
No Archive log mode.
SQL> select * from tab ;
TNAME TABTYPE CLUSTERID
EMP TABLE
EMP1 TABLE
EMP2 TABLE
EMP3 TABLE
EMP4 TABLE
10 rows selected.
SQL> select count(*) from emp3 ;
COUNT(*)
0
SQL> select count(*) from emp4 ;
COUNT(*)
0
Cold backup을 받은후 Archive log mode 변경한 경우
SVRMGR> startup mount
SVRMGR> archive log list
Database log mode No Archive Mode
Automatic archival Enabled
Archive destination D:\Oracle\oradata\SNAP\archive
Oldest online log sequence 26
Current log sequence 28
SVRMGR> alter database archivelog ;
SVRMGR> alter database open ; => archive log mode 변경.
SQL> select * from tab ;
TNAME TABTYPE CLUSTERID
EMP TABLE
EMP1 TABLE
EMP2 TABLE
EMP3 TABLE
EMP4 TABLE
10 rows selected.
SQL> insert into emp3 select * from emp ;
14 rows created.
SQL> commit ;
Commit complete.
SQL> insert into emp4 select * from emp1 ;
71680 rows created.
SQL> commit ;
Commit complete.
SQL> select count(*) from emp3 ;
COUNT(*)
14
SQL> select count(*) from emp4 ;
COUNT(*)
71680
## log switch 발생.
SVRMGR> alter system switch logfile ;
SQL> insert into emp3 select * from emp ; -- current log에 반영.
14 rows created.
SQL> commit ;
SQL> select count(*) from emp3 ;
COUNT(*)
28
SQL> select count(*) from emp4 ;
COUNT(*)
71680
# ALL DATABASE CRASH #
# recover 과정... #
1. Restore Cold-backup
2. modify initSID.ora
log_archive_start = true
log_archive_dest_1 = "location=D:\Oracle\oradata\SNAP\archive"
log_archive_format = %%ORACLE_SID%%T%TS%S.ARC
3. svrmgrl
Statement processed.
SVRMGR> startup mount
ORACLE instance started.
Total System Global Area 40703244 bytes
Fixed Size 70924 bytes
Variable Size 23777280 bytes
Database Buffers 16777216 bytes
Redo Buffers 77824 bytes
Database mounted.
SVRMGR> archive log list
Database log mode No Archive Mode
Automatic archival Enabled
Archive destination D:\Oracle\oradata\SNAP\archive
Oldest online log sequence 26
Current log sequence 28
SVRMGR> alter database archivelog ;
Statement processed.
SVRMGR> recover database using backup controlfile until cancel ;
ORA-00279: change 340421 generated at 04/29/2001 23:42:20 needed for thread 1
ORA-00289: suggestion : D:\ORACLE\ORADATA\SNAP\ARCHIVE\SNAPT001S00028.ARC
ORA-00280: change 340421 for thread 1 is in sequence #28
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Log applied.
ORA-00279: change 340561 generated at 04/29/2001 23:47:29 needed for thread 1
ORA-00289: suggestion : D:\ORACLE\ORADATA\SNAP\ARCHIVE\SNAPT001S00029.ARC
ORA-00280: change 340561 for thread 1 is in sequence #29
ORA-00278: log file 'D:\ORACLE\ORADATA\SNAP\ARCHIVE\SNAPT001S00028.ARC' no longe
r needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Log applied.
ORA-00279: change 340642 generated at 04/29/2001 23:47:35 needed for thread 1
ORA-00289: suggestion : D:\ORACLE\ORADATA\SNAP\ARCHIVE\SNAPT001S00030.ARC
ORA-00280: change 340642 for thread 1 is in sequence #30
ORA-00278: log file 'D:\ORACLE\ORADATA\SNAP\ARCHIVE\SNAPT001S00029.ARC' no longe
r needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Log applied.
ORA-00279: change 340723 generated at 04/29/2001 23:47:40 needed for thread 1
ORA-00289: suggestion : D:\ORACLE\ORADATA\SNAP\ARCHIVE\SNAPT001S00031.ARC
ORA-00280: change 340723 for thread 1 is in sequence #31
ORA-00278: log file 'D:\ORACLE\ORADATA\SNAP\ARCHIVE\SNAPT001S00030.ARC' no longe
r needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Log applied.
ORA-00279: change 340797 generated at 04/29/2001 23:48:01 needed for thread 1
ORA-00289: suggestion : D:\ORACLE\ORADATA\SNAP\ARCHIVE\SNAPT001S00032.ARC
ORA-00280: change 340797 for thread 1 is in sequence #32
ORA-00278: log file 'D:\ORACLE\ORADATA\SNAP\ARCHIVE\SNAPT001S00031.ARC' no longe
r needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SVRMGR> alter database open resetlogs ;
Statement processed.
SVRMGR>
SQL> connect scott/tiger
SQL> select count(*) from emp3 ;
COUNT(*)
14
SQL> select count(*) from emp4 ;
COUNT(*)
71680
# 결론...... #
따라서 current log file에 기록된 14 row에 대한 부분은 recover가 될수
없지만 archive log file에 적용된 log에 대한 data는 정상적으로 복구가
가능하다.
# 주의 사항 #
cold backup을 restore한 후 database open후 shutdown 한 다음 archive
log mode로 변경하여 recover를 진행하는 경우 SCN number가 변경되기
때문에 ora-600 error가 발생하며 media recovery를 필요로 하기 때문에
주의하여야 한다.
SVRMGR> startup
ORACLE instance started.
Total System Global Area 40703244 bytes
Fixed Size 70924 bytes
Variable Size 23777280 bytes
Database Buffers 16777216 bytes
Redo Buffers 77824 bytes
Database mounted.
Database opened.
SVRMGR> shutdown
Database closed.
Database dismounted.
ORACLE instance shut down.
SVRMGR> startup mount
ORACLE instance started.
Total System Global Area 40703244 bytes
Fixed Size 70924 bytes
Variable Size 23777280 bytes
Database Buffers 16777216 bytes
Redo Buffers 77824 bytes
Database mounted.
SVRMGR> alter database archivelog ;
Statement processed.
SVRMGR> recover database using backup controlfile until cancel ;
ORA-00279: change 339542 generated at 04/29/2001 23:30:57 needed for thread 1
ORA-00289: suggestion : D:\ORACLE\ORADATA\SNAP\ARCHIVE\SNAPT001S00003.ARC
ORA-00280: change 339542 for thread 1 is in sequence #3
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00283: recovery session canceled due to errors
ORA-00600: internal error code, arguments: [3020], [8390146], [1], [3], [143], [
240], [], []
SVRMGR> exit
Server Manager complete.
Rederence Documents
---------------------

DB Back to a Specific Time with Archive Logs (Until cancel or time?)

I'll try to be as clear as possible with my intended goals and the limitations of the system I'm working with:
1. We have a test instance of our Oracle DB that I would like to be able to refresh with data from the production instance at any time, without having to shut down the production database or put tablespaces into hot backup mode.
2. Both systems are HP Itanium boxes with differing numbers of CPUs and RAM. Those differences have been taken into account in the init.ora file for the DB instances.
3. The test and production instances are using a SAN to hold the following file systems: ora_redo1, ora_redo2, ora_archlog, oradata10g. The test instance is using SAN snapshots (HP EVA series SAN) of the production file systems to pull the data over when needed. The problem is that the only window to do this is when the production system is down for nightly maintenance which is about a 20 minute period. I want to escape this limitation.
What I've been doing is using the HP SAN to take snapshots of the file systems on the production system mentioned above. I do this while the production DB is up and running. I then import those snapshots into the test system, run an fsck to ensure file system integrity, then start up the Oracle instance as follows:
startup mount
Then I run the following query I found on line to determine the current redo log:
select member from v$logfile lf , v$log l where l.status='CURRENT' and lf.group#=l.group#;
Then I attempt to run a recovery as follows:
recover database using backup controlfile until cancel;
When prompted, I enter the path to the first of the current redo logs and hit enter. After waiting, sometimes it says that the recovery completed, other times it stops saying there was an error and that more files are needed to make the DB consistent.
I took the above route because doing a recover until time (which is what I really want to do) kept prompting me for the next archive log in sequence that didn't yet exist when I took the SAN snapshot. Here was my recover until time command:
recover database until time 'yyyy-mm-dd:hh:mm:ss' using backup controlfile;
What I would like to do is take the SAN snapshot and then recover the database to about a minute before the snapshot using the archive logs. I don't want to use RMAN since that seems to be overkill for this purpose. A simple recovery to a specific point in time seems to be all that is needed and I have archive logs which, I assume, SHOULD help me get there. Even if I have to lose the last hour's worth of transactions I could live with that. But my tests setting the specific time of recovery to even 12 hours earlier still resulted in a prompt for the next, non-existent archivelog.
I will also note that I even tried copying the next archive log over once it did exist and the recovery would then prompt me for the next archive log! I will admit right now that I really don't know a whole lot about Oracle or DBs, but it's my task to try and make it possible to "refresh" the test DB with the most recent data with no impact on the production DB.
The reason I don't want to use hot backup mode is that I don't know the DB schema other than there are probably 58 or more tablespaces. The goal is to use SAN snapshots for their speed instead of having to take RMAN files and copy them to the test instance. I'm sure I'm not the only person who has ever tried this. But most of what I've found on line refers to RMAN, hot backup mode, or down time. The first two don't take advantage of SAN snapshots for a quick swap of all the Oracle file systems and I can't afford downtime other than that window at night. Is there some reason that the recover to time didn't work even though I have archive logs?
One final point. The recover until cancel actually worked a couple of times, but it seems to be sporadic. It likely has something to do with what was happening on the production DB when I created the SAN snapshots. I actually thought I had a solution with recover until cancel last week until it didn't work three times in a row.

I haven't completely discounted it but it seems like I would need to back up to files, then restore from files. I don't want to do that. I want a full file system level SAN snapshot that I can just drop into place. The does work when the production base is shut down. However, considering that I do have archive logs, shouldn't it be possible to use them to recover to a specific scene without having to do an RMAN backup at all? It seems that doing an RMAN backup/recovery would just make this whole process a lot longer since the DB is 160 gigs in size (not huge, but the dump would take more time than I would like). With a SAN snapshot, if I can get this to work, I'm looking at about a 15-20 minute period of time to move the production DB over to test.
Since you are suggesting that RMAN may be a better approach I'll provide more details about what I'm trying to do. Essentially this is like trying to recover a DB from a server that had its power plug pulled. I was hoping that Oracle's automatic recovery would do the same thing it would do in that instance. But obviously that doesn't work. What I want to do is bring over all the datafiles, redo logs, and archive logs using the SAN snapshot. Then if possible use some aspect of Oracle (RMAN if it can do it) to mount the database, then recover to a specific time or SCN if using RMAN. However, when I tried using RMAN to do it, I got an error saying that it couldn't restore the data file because it already existed. Since I don't want to start from scratch and have RMAN rebuild files that I've already taken snapshots of (needless copying of data), I gave up on the RMAN approach. But, if you know of a way to use RMAN so that it can recover to a specific incarnation without needing to runm a backup first, I am completely open to trying it.

Backup with Exp, Can It used in DB with Archive Log Mode ??

I need information about if When I activate Archive log mode in my database ,after This I will use all before backups with Exp in full,Table,user ...recovery mode .
any advice are welcome
thanks
Jimmy

If you are using archive log mode, you should back up your database by regularly backing up
your data files. If you lose a tablespace due to a defecitve disk or need to do a point-in-time recovery due to a user error, you restore your latest copy (if doing point-in-time the latest copy before the
user error) of the relevant data files an then roll forward using the archived log.
You can not restore your database from an export and then roll forward using the archived
logs.
HTH
Marcus Geselle

RMAN,Data Guard and Archive log deletion

Our DG environment is running Oracle 11g R2
we have a 3 node DG environment with
A being the Primary
B and C being Active Data Guard Standbys
Backups are taken off of B and go directly to tape.
Standby Redo Logs and Fast Recovery Area are being used
Taking recommendation from "Using Recovery Manager with Oracle Data Guard in Oracle Database 10g"
RMAN Setting on Primary ("A")
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY
RMAN Setting on Standby ("B") where Backup is done
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE
RMAN Setting on other Standby ("C")
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY
How can we know what archive logs are eligible to be deleted from "A" and "C" ?
When does the delete take place?
How can we tell when the archive logs are being deleted from "A" and "C" ?

Dear user10260925,
The documentation that you have read is reliable but insufficient.
The Oracle can manage the archivelog directory and knows which one is eligible for the deletion. Those stuff you have posted in here has been taken from the online documentation and is supported and can be used when the Oracle knows and manages the archivelogs. That is simply called the flash recovery area. Please read about the FRA in this very moment.
Under normal circumstances people in the industry uses some scripts to achive the archivelog deletion on the standby system.
Here is a useful example to you;
# Remove old archivelogs
00,30 * * * * /home/oracle/scripts/delete_applied_redo_logs_OPTSTBY.sh
vals3:/home/oracle#cat /home/oracle/scripts/delete_applied_redo_logs_OPTSTBY.sh
export ORACLE_SID=optstby
export ORACLE_HOME=/oracle/product/10.2.0/db_1
cd /db/optima/archive/OPTPROD/archivelog
/oracle/product/10.2.0/db_1/bin/sqlplus "/ as sysdba" @delete_applied_redo_logs.sql
grep arc delete_applied_redo_logs.lst > delete_applied_redo_logs_1.sh
chmod 755 delete_applied_redo_logs_1.sh
sh delete_applied_redo_logs_1.sh
rm delete_applied_redo_logs_1.sh
rm delete_applied_redo_logs.lst
vals3:/home/oracle#cd /db/optima/archive/OPTPROD/archivelog
vals3:/db/optima/archive/OPTPROD/archivelog#cat delete_applied_redo_logs.sql
set echo off
set heading off
spool /db/optima/archive/OPTPROD/archivelog/delete_applied_redo_logs.lst
select 'rm -f ' || name from v$archived_log where applied = 'YES';
spool off
exit
vals3:/db/optima/archive/OPTPROD/archivelog#Hope That Helps.
Ogan

RMAN- unable to find archive log

Hi All,
I am facing this problem while i am recovering my database. I have checked this archive file and it is present on the location where it should be. So what can be the solution.
Pls help...
Thanks and Regards
Amit Raghuvanshi

Hi Dear,
The location is on the disk and the error is...
released channel: ORA_DISK_1
allocated channel: dev2
channel dev2: sid=12 devtype=DISK
Starting recover at 08-AUG-07
starting media recovery
archive log thread 1 sequence 54266 is already on disk as file /erpp/erppdata/log01a.dbf
archive log thread 1 sequence 54267 is already on disk as file /erpp/erppdata/log02a.dbf
unable to find archive log
archive log thread=1 sequence=54259
released channel: dev2
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/08/2007 11:33:57
RMAN-06054: media recovery requesting unknown log: thread 1 scn 5965732883373
Regards
Amit Raghuvanshi

How to recover a database with archive log

how to recover database with archivle log

Hi,
With in information no one can tell the answer.
Kindly post your qusetion in details information, you want to recover the database in archive log mode, what type of error you get, bcoz depending up on the errors you recover your database,
please mention all about your database
cheers
Senthil Kumar

Good One - "ORA-00308: cannot open archived log", No Recovery Going On

Folks,
Oracle 11gR1 SE cluister in archive log mode. Every hour I scp old logs over to a different server and nuke the ones so archived. I always switch the log destination to a new directory before moving and nuking, so I'm not touching logs being written to. Every once in a while I get;
Thu Nov 11 22:08:13 2010
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x0] [PC:0x3201E53, _intel_fast_memcmp()+27]
Errors in file /u01/oracle/diag/rdbms/dekopd78/DEKOPD781/trace/DEKOPD781_ora_30937.trc (incident=805592):
ORA-07445: exception encountered: core dump [_intel_fast_memcmp()+27] [SIGSEGV] [ADDR:0x0] [PC:0x3201E53] [Address not mapped to object] []
Incident details in: /u01/oracle/diag/rdbms/dekopd78/DEKOPD781/incident/incdir_805592/DEKOPD781_ora_30937_i805592.trc
Thu Nov 11 22:09:42 2010
Errors in file /u01/oracle/diag/rdbms/dekopd78/DEKOPD781/incident/incdir_805592/DEKOPD781_ora_30937_i805592.trc:
Linux-x86_64 Error: 2: No such file or directory
Thu Nov 11 22:09:42 2010
Errors in file /u01/oracle/diag/rdbms/dekopd78/DEKOPD781/incident/incdir_805592/DEKOPD781_ora_30937_i805592.trc:
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-00308: cannot open archived log '/u01/oracle/ARCHIVE_LOG_DEST/DEKOPD78/archive2/2_2043_716773164.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-00308: cannot open archived log '/u01/oracle/ARCHIVE_LOG_DEST/DEKOPD78/archive2/2_2044_716773164.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-00308: cannot open archived log '/u01/oracle/ARCHIVE_LOG_DEST/DEKOPD78/archive1/2_2045_716773164.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-00308: cannot open archived log '/u01/oracle/ARCHIVE_LOG_DEST/DEKOPD78/archive1/2_2046_716773164.dbf'
ORA-27037: unable to obtain file status
This seems to happen after a core dump (memory leak?). No recovery is going on and the database functions normally afterwards.
Why would the database try to access old log filles when not recovering?
Thanks,
Scott Uhrick
General Reinsurance

After some errors database instance tries to access redo data for the last 12 hours: see My Oracle Support note:
+Oracle Alert Log Is Reporting Archive Log Status Is Not Available For Logs That Have Long Been Backed Up [ID 1161573.1]+
Edited by: P. Forstmann on 15 nov. 2010 21:34

What order are Archive logs restored in when RMAN recover database issued

Ok, you have a run block that has restored your level-0 RMAN backup.
Your base datafiles are down on disc.
You are about to start recovery to point in time, lets say until this morning at 07:00am.
run { set until time "TO_DATE('2010/06/08_07:00:00','YYYY/MM/DD_HH24:MI:SS')";
allocate channel d1 type disk;
allocate channel d2 type disk;
allocate channel d3 type disk;
allocate channel d4 type disk;
recover database;
So the above runs, it analyses the earlies SCN required for recovery, checks for incremental backups (none here), works out the archivelog range
required and starts to restore the archive logs. All as expected and works.
My question: Is there a particular order that RMAN will restore the archive logs and is the restore / recover process implemented as per the run block.
i.e Will all required archive logs based on the run block be restored and then the database recovered forward. Or is there something in RMAN that says restore these archive logs, ok now roll forwards, restore some more.
When we were doing this the order of the archive logs coming back seemed to be random but obviously constrained by the run block. Is this an area we need to tune to get recoveries faster for situations where incrementals are not available?
Any inputs on experience welcome. I am now drilling into the documentation for any references there.
Thanks

Hi there, thanks for the response I checked this and here are the numbers / time stamps on an example:
This is from interpreting the list backup of archivelog commands.
Backupset = 122672
==============
Archive log sequence 120688 low time: 25th May 15:53:07 next time: 25th May 15:57:54
Piece1 pieceNumber=123368 9th June 04:10:38 <-- catalogued by us.
Piece2 pieceNumber=122673 25th May 16:05:18 <-- Original backup on production.
Backupset = 122677
==============
Archive log sequence 120683 low time: 25th May 15:27:50 Next time 25th May 15:32:24 <-- lower sequence number restored after above.
Piece1 PieceNumber=123372 9th June 04:11:34 <-- Catalogued by us.
Piece2 PieceNumber=122678 25th May 16:08:45 <-- Orignial backup on Production.
So the above would show that if catalogue command you could influence the Piece numbering. Therefore the restore order if like you say piece number is the key. I will need to review production as to why they were backed up in different order completed on production. Would think they would use the backupset numbering and then piece within the set / availability.
Question: You mention archive logs are restored and applied and deleted in batches if the volume of archivelogs is large enough to be spread over multiple backup sets. What determines the batches in terms of size / number?
Thanks for inputs. Answers some questions.

RMAN backup of archive logs

I am sort of new to RMAN, I've been playing with it for a while but that's about as far as I've taken it. My question is does RMAN automatically backup any archive logs needed for recovery when I run "backup database" command or do I have to issue "backup database plus archive log" in order to insure recovery.

Backup database also backups archivelogs.No,it does not. From documentation:
backup database;
Creates a backup set (AS BACKUPSET) or group of image copies (AS COPY) for all datafiles in the database. If generating a backup set, then RMAN can include only datafiles and control files: it cannot include archived redo logs.
Werner

RMAN9I HOW TO RESTORE ARCHIVE LOGS WITH LIMITED DISK SPACE

제품 : RMAN
작성날짜 : 2002-12-09
RMAN9I HOW TO RESTORE ARCHIVE LOGS WITH LIMITED DISK SPACE
==========================================================
PURPOSE
이 자료는 Oracle 9.2 이상의 RMAN에서 사용 가능한 MAXSIZE 기능에 대하여
설명할 것이다.
How to restore archive logs with limited disk space
Old Backup을 사용하여 RMAN으로 database를 recvoery할때, 모든 archived
redo logfile들을 Restore할 destination의 disk space가 모자란 경우를 종종 만난다.
이러한 경우 여러 개의 restore and recovery job으로 나누어 수행한다.
즉, 첫 번째 restore and recovery job이 끝나면 archived redo logfile들을 지우고
다음 적용될 것들을 restore한다. 그리고 다시 Recovery를 수행한다. 이러한 작업을
원하는 시점까지 recovery를 하기위해 반복적으로 수행한다.
Oracle 9iR2(9.2.0.x)부터 RMAN은 MAXSIZE option을 제공하는데 이것은 archive log
file이 restore될 disk의 space를 control할 수 있게 해 준다.
만약 disk space가 매우 제한적이라면, 즉 예를 들어 모든 archive log의 size 합보다
disk free space가 적다면 MAXSIZE option을 사용하는 것은 매우 유용하다.
이 OPTION이 기술되면 RMAN은 Media Manager에게 disk space 크기에 부합하는 만큼만
archive log들을 restore하도록 한다. 부가적인 restore operation들은 restore된
마지막 archive log가 적용될 때마다 발생한다.
MAXSIZE option은 이러한 작업들을 하나의 rman job으로 처리하게 해 주고
실수를 하지 않게 해 준다.
아래는 MAXSIZE를 설명하기 위한 예제이며 총 6 단계로 구성되어 있다.
STEP 1: Add data to the database to enforce log switches
STEP 2: Backup the database and archive logs and delete the logs
STEP 3: Add additional data to enforce new log switches
STEP 4: Remove the data file and simulate a database crash
STEP 5: Restore the data file from the backup
STEP 6: Recover the database using MAXSIZE
위 예제는 Unix와 Windows 모두에 적용될 수 있다.
STEP 6 는 다음과 같은 조건으로 두 번 수행될 것이다.
1) MAXSIZE가 archive log size보다 작은 경우:
이 경우 RMAN-6558 Error message를 만나게 된다.
그러므로 MAXSIZE를 archive log보다는 크게 설정해야한다.
2) MAXSIZE가 archive log size보다 큰 경우:
예를 들어 여러 개의 archive log를 포함할 수 있을 정도로 크게 설정하면
restore/recovery는 user에게 transparent하게 수행되어진다.
즉 archive log들은 restore된 후 applied되고 deleted되어 진다. 다시 새로운
archive log들이 restore되어지고 applied된 후 deleted 되어 진다. 이러한 작업은
recovery가 끝날 때까지 반복되어진다. 이러한 작업들이 진행되는 동안 RMAN은
아무런 Message도 발생시키지 않는다.
# Step 1: INSERT enough new data to generate log switches
create table rman_tst (col1 varchar2 (10));
begin
for i in 1..30000 loop
insert into rman_tst values(i,'test');
commit;
end loop;
end;
# Step 2: BACKUP the database and the archive logs automatically
# and then delete the input
run {
backup database format='/web01/usupport/krosenme/admin/backups/db_%d%s%t'
plus archivelog format='/web01/usupport/krosenme/admin/backups/arch_%d%s%t'
delete input;
# Step 3: INSERT enough new data to generate new log switches
begin
for i in 1..30000 loop
insert into rman_tst values(i,'test');
commit;
end loop;
end;
# Step 4: REMOVE users01.dbf file and crash the database
mv users01.dbf users01.org
shutdown abort
# Restore is now needed as the data file is deleted. The backup was
# taken before the new data was added to it, thus archive logs are
# needed to bring the database up to date
# Step 5: RESTORE the data file from the full backup
run {
restore datafile '/web01/usupport/krosenme/oradata/kro_920/users01.dbf';
# Step 6: RECOVER
run {
recover database delete archivelog maxsize 10 K;
# This will fail with RMAN-6558 as the archived log has a size of 16 KB,
# which is bigger than MAXSIZE limit of 10 KB. So the error is expected
# and MAXSIZE works as designed.
# Now rerunning STEP 6: but with MAXSIZE 50 K
run {
recover database delete archivelog maxsize 50 K;
RELATED DOCUMENTS
Recovery Manager Reference, Release 2 (9.2)

cold backup means offline backup, you shut database normally and copy datafiles to another location.
i think operating system does not matter that much but it is RedHat Linux Enterprise Server.
backing up archivelogs whith rman script which is:
run {
allocate channel c1 type disk format '$BKUPLOC/arch_%d_%u_%s_%p.bkp';
change archivelog all validate;
sql 'ALTER SYSTEM ARCHIVE LOG CURRENT';
backup archivelog time between 'SYSDATE - (30*60/(60*60*24))' and 'sysdate';
release channel c1;
so here is the details.
1. because everything is lost, we restored all files(datafiles, controlfiles, redologs etc) from offline backup meaning copied all files from another location to corresponding location.
2. want to apply archive logs which were created after cold backup till disk failure and we have these archive logs with backups which were taken by rman.
So
first of all, we want to register these archive log rman backups(because these backup information does not exist in restored controlfile)
and then restore them and then apply them.
we need rman commands to register these backups and restore them.
Regards,
Kamil

Rman - rolling foward with archive logs during recovery

Similar Messages

Maybe you are looking for