Shipping ASM archivelogs

Sometimes it is required to ship the archivelogs from one server to another. It becomes difficult when archivelogs are sitting on ASM file system. ASM files can not be directly accessed. RMAN can come to the rescue in this.

I had an issue of missing archives on STANDBY server (Log GAP) and somehow those archives got backedup to tape and mrp could not access it. Now I had to restore it and then get it shipped to STANDBY server. Since the GAP was too big, I decided to restore it and manually ship it rather than MRP to handle it. This is the process I followed. I am sure there may be many ways. But this one worked for me.

• I identified log GAP using query

SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG"
FROM V$LOG_HISTORY
GROUP BY THREAD#
/

• Then copy/restore the ASM logs to the cooked file system.

RMAN> run {
allocate channel c2 device type 'sbt_tape';
set archivelog destination to '/u01/app/oracle/admin/infra/arch';
restore archivelog from sequence 8852 until sequence 8856 thread 2;
release channel c2;
}
2> 3> 4> 5> 6>
allocated channel: c2
channel c2: sid=2228 instance=infra1 devtype=SBT_TAPE
channel c2: Data Protection for Oracle: version 5.3.3.0
executing command: SET ARCHIVELOG DESTINATION
Starting restore at 22-JAN-09
archive log thread 2 sequence 8856 is already on disk as file /u01/app/oracle/admin/infra/arch/infra_2_8856_641059495.arc
channel c2: starting archive log restore to user-specified destination
archive log destination=/u01/app/oracle/admin/infra/arch
channel c2: restoring archive log
archive log thread=2 sequence=8852
channel c2: restoring archive log
archive log thread=2 sequence=8853
channel c2: restoring archive log
archive log thread=2 sequence=8854
channel c2: restoring archive log
archive log thread=2 sequence=8855
channel c2: reading from backup piece qek5f68i_1_1
channel c2: restored backup piece 1
piece handle=qek5f68i_1_1 tag=TAG20090122T161057
channel c2: restore complete, elapsed time: 00:00:55
Finished restore at 22-JAN-09
released channel: c2
RMAN> exit

• Once the logs are restored, scp or sftp it to the standby destination. This will again be a cooked file system

scp infra_2_*.arc :/tmp
infra_2_8853_641059495.arc 100% 131MB 11.0MB/s 00:12
infra_2_8854_641059495.arc 100% 267MB 12.2MB/s 00:22
infra_2_8855_641059495.arc 100% 60MB 8.5MB/s 00:07
infra_2_8856_641059495.arc 100% 542KB 541.5KB/s 00:00

• Now if standby database log recovery destination is ASM file system or different than the scp destination, manually recover the database. Or at the recovery prompt manually feed the file name with a full path.

SQL> alter database recover managed standby database cancel;

SQL> recover from '/tmp' standby database;

• Start the managed recovery

SQL> alter database recover managed standby database disconnect from session;

• Verify the log shipping and log apply and That's it