Networker

Re: [Networker] Timestamps for recovered Oracle files?

2006-10-20 16:57:16
Subject: Re: [Networker] Timestamps for recovered Oracle files?
From: Lancy Quadros <Lancy.Quadros AT ROTARY DOT ORG>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Fri, 20 Oct 2006 15:22:34 -0500
Try this:
RMAN> run
2> {
3> set until time "to_date('2006/10/18 21:00:00','yyyy/mm/dd
hh24:mi:ss')";
4> }

That should work.

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of George Sinclair
Sent: Friday, 20 October, 2006 1:22 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Timestamps for recovered Oracle files?

Following is the rman script that was working with tape. We've since 
commented out the 'set until' time line since
that wasn't working:

run {
allocate channel t1 type 'SBT_TAPE';
#allocate channel d1 type disk;
#set until time 'Oct 16 2006 21:00:00';
restore controlfile to '/0/oracle10.2/recover/y';
#restore controlfile from 'SBT_TAPE';
sql 'alter database mount';
restore database;
recover database;
sql 'alter database open resetlogs';
}

Here are the environment variables we set before running this script 
shown from 'env':

NLS_DATE_FORMAT=Mon DD YYYY HH24:MI:SS
NLS_LANG=american

I should also note that we've since re-tested another rman script 
working with disk,
and that, too, fails in a similar fashion. Here's that script. Either of

the 'until time'
lines causes a problem. We've also tried both double and single quotes.

run {
set until time 'SEP 20 2006 20:00:00';
restore controlfile from AUTOBACKUP;
#restore controlfile until time "TO_DATE('09/30/2006','MM/DD/YYYY')";
sql 'alter database mount';
restore database;
recover database;
sql 'alter database open resetlogs';
}


Lancy Quadros wrote:

>George,
>
>If possible, could you post the entire rman recover script (with
>server/db names obscured if you wish) with a copy of the environment
>variables in effect during the rman session?
>
>Lancy
>
>-----Original Message-----
>From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
On
>Behalf Of George Sinclair
>Sent: Friday, 20 October, 2006 8:45 AM
>To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
>Subject: Re: [Networker] Timestamps for recovered Oracle files?
>
>Doug,
>
>Thanks. It seems, though, that whenever we use the *set until time 
>"format", rman just complains. It
>doesn't like the 'set' command. It errors off every time it hits that 
>darn line. We tried setting the NLS_DATE_FORMAT in the Oracle
>user's environment, before running the rman script as:
>
>export **NLS_DATE_FORMAT=*'Mon DD YYYY HH24:MI:SS'
>
>and then to ensure that it was set properly:
>
>env | grep *NLS_DATE_FORMAT
>echo $**NLS_DATE_FORMAT*
>
>Nothing works. We even tried setting this variable in the init.ora
file.
>
>(actually, in our case it's initTEST.ora)
>since we have a TEST database. RMAN still dies when it hits the 'set 
>until time' line. We even tried different
>syntaxes like: DD-MM-YYYY HH24:MI:SS' and 'MM/DD/YYYY HH24:MI:SS', you 
>name it. They all die. We even tried
>adding the line: *NLS_DATE_FORMAT=*'Mon DD YYYY HH24:MI:SS' to the rman

>script itself but before the line:
>
>run {
>
>It still terminates as soon as it sees that 'set until time' line. WE 
>finally just gave up and removed the line, and then it works, but
again,
>it
>recovers the most recent file(s), so while we can make it work, we
still
>
>can't recover by specific date. We've been scratching our heads over 
>this one. It's really frustrating
>when you use the same examples in the Legato Oracle documentation and 
>they won't work.
>
>Any suggestions?
>
>George
>
>Doug Brown wrote:
>
>  
>
>>George
>>
>>This works every time.
>>
>>
>>in a shell script
>>
>>export NLS_DATE_FORMAT='Mon DD YYYY HH24:MI:SS'
>>
>>Inside rman
>>
>>*run {*
>>*set until time "Aug 10 2006 23:50:00";*
>>*allocate auxiliary channel t1 type "SBT_TAPE"*
>>*parms 
>>
>>    
>>
>"BLKSIZE=1048576,ENV=(NSR_CLIENT=dbsp01,NSR_SERVER=aesnsr,NSR_MMDB_RETR
Y
>_TIME=30,NSR_DATA_VOLUME_POOL=aesprodrman)"*; 
>  
>
>>...
>>...
>>*duplicate target database to E04;*
>>*}*
>>
>>
>>
>>
>>
>>*George Sinclair <George.Sinclair AT NOAA DOT GOV>*
>>Sent by: EMC NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>
>>
>>10/19/2006 06:17 PM
>>Please respond to
>>EMC NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>; Please 
>>respond to
>>George Sinclair <George.Sinclair AT NOAA DOT GOV>
>>
>>
>>      
>>To
>>      NETWORKER AT LISTSERV.TEMPLE DOT EDU
>>cc
>>      
>>Subject
>>      [Networker] Timestamps for recovered Oracle files?
>>
>>
>>
>>      
>>
>>
>>
>>
>>
>>Hi,
>>
>>We're using RMAN and NMO to test backup/recovery of an Oracle test 
>>database.
>>I notice that when we use an RMAN script to recover data files, or
>>    
>>
>even
>  
>
>>the control file (we recover that to a different location), they
>>all get recovered with the current time (i.e. the time of the recover)
>>and not their original times.
>>Recovery of non_Oracle data, however, always preserves the original
>>    
>>
>time
>  
>
>>stamp.  I'm thinking the time SHOULD change when
>>dealing with database files in order to keep things consistent? Maybe
>>this is reasonable and merely a function of Oracle, or is the NMO
>>purposely doing this because it knows Oracle will want the current
>>    
>>
>time?
>  
>
>>I should note that our RMAN recover script does not have a 'set until
>>time' line. We tried that, but it always bombs
>>with a complaint about the 'set' syntax. Tried everything, including  
>>NLS_DATE_FORMAT, environment variables,
>>and even the init.ora file and could never get RMAN to take it so we
>>finally just took out the 'set until time' line,
>>and it worked. Of course, this means it's just recovering the most
>>recent file I guess. We'll obviously have to get that
>>working since that's the whole point of the NetWorker software, but if
>>and when we can get this working will the recovered
>>files still have the current time?
>>
>>Thanks.
>>
>>George
>>
>>-- 
>>George Sinclair - NOAA/NESDIS/National Oceanographic Data Center
>>SSMC3 4th Floor Rm 4145       | Voice: (301) 713-3284 x210
>>1315 East West Highway        | Fax:   (301) 713-3301
>>Silver Spring, MD 20910-3282  | Web Site:  http://www.nodc.noaa.gov/
>>- Any opinions expressed in this message are NOT those of the US Govt.
>>    
>>
>-
>  
>
>>To sign off this list, send email to listserv AT listserv.temple DOT edu and 
>>type "signoff networker" in the
>>body of the email. Please write to 
>>networker-request AT listserv.temple DOT edu if you have any problems
>>wit this list. You can access the archives at 
>>http://listserv.temple.edu/archives/networker.html or
>>via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>>
>>    
>>
>
>
>  
>


-- 
George Sinclair - NOAA/NESDIS/National Oceanographic Data Center
SSMC3 4th Floor Rm 4145       | Voice: (301) 713-3284 x210
1315 East West Highway        | Fax:   (301) 713-3301
Silver Spring, MD 20910-3282  | Web Site:  http://www.nodc.noaa.gov/
- Any opinions expressed in this message are NOT those of the US Govt. -


To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu 
if you have any problems
wit this list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER