RE: RMAM duplicate database - until when?

From: Andy Rivenes <arivenes_at_llnl.gov>
Date: Fri, 22 Dec 2006 09:05:12 -0800
Message-Id: <7.0.0.16.2.20061222085103.022bc0e8@llnl.gov>

Hi Duncan, at least partly because of the problems your having I put two things in the backup log that help in these situations. The first is that I output the date and time at the beginning and end of the backup. The second is that I grab the "current" SCN with:

   $ORACLE_HOME/bin/sqlplus -s /NOLOG << STOP > /tmp/dbinfo.$$ CONNECT $CFG_BKUPDB AS SYSDBA
SET HEAD off FEEDBACK off VERIFY off ECHO off;

COLUMN scn FORMAT 9999999999999999;

SELECT l.first_change# "SCN" FROM v\$log l WHERE l.status='CURRENT'; EXIT sql.sqlcode;
STOP I'm not sure that this is better than the solutions offered, but it works for my purposes (it was originally added to synchronize backups for 10g AS prior to the availability of Application Guard, but that's another story).

And for most of the duplications that I do I use time rather than SCN. It's usually close enough and much less error prone (the error being not having all the backup archivelog files readily available on the restore machine). So the following is an Oracle9i disk based duplicate template script that restores based on time or SCN if that helps:

#
# Auxillary database must be started "nomount"
#
# Expects "log_file_name_convert" and "db_file_name_convert" to
# be set in the init.ora if not using "newname" commands
#

export NLS_LANG="AMERICAN_AMERICA.WE8ISO8859P1" export NLS_DATE_FORMAT="DD-MON-YY HH24:MI"
#

$ORACLE_HOME/bin/rman nocatalog target sys/pwd_at_alias log=dupdisk.log <<-EOF connect auxiliary /
#

run {
#
# Note: Use of the following init.ora parameters avoids the need for
explicit file renaming:
#
# db_file_name_convert='/u01/oradata/dev','/u01/oradata/dupdev'
# log_file_name_convert='/u01/oradata/dev','/u01/oradata/dupdev'
#
#set newname for datafile '/u01/oradata/dev/system01.dbf' to
'/u01/oradata/dupdev/system01.dbf';
#set newname for datafile '/u01/oradata/dev/undotbs01.dbf' to
'/u01/oradata/dupdev/undotbs01.dbf';
#set newname for datafile '/u01/oradata/dev/cwmlite01.dbf' to
'/u01/oradata/dupdev/cwmlite01.dbf';
#set newname for datafile '/u01/oradata/dev/drsys01.dbf' to
'/u01/oradata/dupdev/drsys01.dbf';
#set newname for datafile '/u01/oradata/dev/example01.dbf' to
'/u01/oradata/dupdev/example01.dbf';
#set newname for datafile '/u01/oradata/dev/indx01.dbf' to
'/u01/oradata/dupdev/indx01.dbf';
#set newname for datafile '/u01/oradata/dev/tools01.dbf' to
'/u01/oradata/dupdev/tools01.dbf';
#set newname for datafile '/u01/oradata/dev/users01.dbf' to
'/u01/oradata/dupdev/users01.dbf';
#set newname for datafile '/u01/oradata/dev/xdb01.dbf' to
'/u01/oradata/dupdev/xdb01.dbf';
#
# Note: Set this in the init.ora as well!
#

sql 'ALTER SESSION SET NLS_DATE_FORMAT="DD-MON-YY HH24:MI"'; set until time = '08-SEP-03 01:00';
#set until sequence = 2148 thread = 1;
#
# Uset NOFILENAMECHECK if duplicating to the same log and file names
#

duplicate target database to dupdev;
# nofilenamecheck
#logfile
# group 1 ('/u01/oradata/dupdev/redo01.log') size 100m,
# group 2 ('/u01/oradata/dupdev/redo02.log') size 100m,
# group 3 ('/u01/oradata/dupdev/redo03.log') size 100m;
}
exit;
EOF At 01:22 AM 12/22/2006, Lawie, Duncan wrote:

>I don't believe I can safely subtract one from the SCN and expect it 
>to be in an existing log - and I get the same error as with the higher number
>
>Oracle Error:
>ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
>ORA-01152: file 3 was not restored from a sufficiently old backup
>ORA-01110: data file 3: '/data/oracle/TESTDBE30/u01/sysaux01.dbf'
>
>Now that error doesn't make sense, as the file 3 has a higher SCN 
>than 1 or 2 ...
>
>SQL> select FILE#, CHECKPOINT_CHANGE# from v$datafile_header order by 1;
>
>      FILE# CHECKPOINT_CHANGE#
>---------- ------------------
>          1           45670185
>          2           45670185
>          3           45670188
>...
>
>Note that recovery works if I use the checkpoint_change# for file 
>3.  But this database was pretty static when it was backed up.
>
>

Andy Rivenes
Email: arivenes_at_llnl.gov

--
http://www.freelists.org/webpage/oracle-l

Received on Fri Dec 22 2006 - 11:05:12 CST