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_RETRY
_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
|
