I'm hoping that you have a "sev 1" TAR open on this, as well. Keep
pestering them if you haven't had a response; keep the TAR status at
"IMMEDIATE RESPONSE REQUIRED" (by responding multiple times) whenever you
hit the ball back to them. Also, be sure that all relevant facts are
recorded online through MetaLink, in case this later degenerates into a
finger-pointing game. You cannot play that game with verbal records...
---
You are connecting both TARGET and AUXILIARY to the same database instance
(i.e. "/"). For a DUPLICATE DATABASE operation, you don't have to connect
to the TARGET at all, if I recall correctly; a DUPLICATE DATABASE operation
doesn't involve the TARGET. Sounds funny, until you consider that the
operation is reading from tape to the new AUXILIARY database instance.
For the AUXILIARY, be sure that you have already created another empty
database instance (using most of the TARGET databases "init.ora" parms, with
obvious exceptions like CONTROL_FILE) which is started up NOMOUNT before
starting this DUPLICATE DATABASE operation.
If what I suspect is correct, then I think you ought to be *glad* that RMAN
just "hung" instead of following its directions! Of course, a relevant
error message would a lot *nicer* than just "hanging" that way...
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
Sent: Monday, April 08, 2002 7:43 AM
> Dear All,
>
> I am totally out of my depth here and this is a production db which needs
to
> be restored urgently.
> I shall explain my scenario first. Our application team had lost some data
> after last Wednesday night's
> backup. They have a tool to have a dump of the data from the database from
> which they can extract the
> data if needed. This dump was taken on Thursday morning. Due to some
***hole
> they lost some more data
> on Thursday during the day. They recovered this data from the database
dump
> which they had taken on
> Thursday morning.
> They now want the data which was lost on Wednesday. Since there was no
> database dump available prior to
> this, I suggested that we can create a duplicate database upto a point of
> time (as on Wednesday night) to a
> different location on the server. They could then take a database dump
with
> their tool and extract the lost records.
> This is my script which I compiled with help from Metalink and an old
> post from John Hallas (the backup of our target database is taken on tape
> with Veritas Netbackup) :
>
> #!/bin/ksh
>
> rman target / catalog rman_sid1/rman_sid1_at_rman817 auxiliary /
>
> run {
>
> set until time "to_date('20-MAR-2002 20:00:00','DD-MON-YYYY HH24:MI:SS)";
>
> allocate channel c_dlt1 type 'SBT_TAPE';
>
> allocate auxiliary channel dupdb_d1 type disk;
>
> setlimit channel c_dlt1 kbytes 67108864 maxopenfiles 128 readrate 256;
> setlimit channel dupdb_d1 kbytes 67108864 maxopenfiles 128 readrate 256;
>
> set newname for datafile
> '/disk01/oradata/sid1/data/system01sid1.dbf'
> to '/disk01/oradata/test/data/system01sid1.dbf';
>
> set newname for datafile
> '/disk01/oradata/sid1/data/rbs01sid1.dbf'
> to '/disk01/oradata/test/data/rbs01sid1.dbf';
>
> set newname for datafile
> '/disk01/oradata/sid1/data/temp01sid1.dbf'
> to '/disk01/oradata/test/data/temp01sid1.dbf';
>
> set newname for datafile
> '/disk01/oradata/sid1/data/tools01sid1.dbf'
> to '/disk01/oradata/test/data/tools01sid1.dbf';
>
> set newname for datafile
> '/disk01/oradata/sid1/data/users01sid1.dbf'
> to '/disk01/oradata/test/data/users01sid1.dbf';
>
> duplicate target database to test
>
> logfile
> group 1 '/disk03/oradata/test/logs/log01a01sid1.dbf' size 180M,
> group 2 '/disk03/oradata/test/logs/log02a01sid1.dbf' size 180M,
> group 3 '/disk03/oradata/test/logs/log03a01sid1.dbf' size 180M;
> }
>
> What happens is that RMAN connects to the target, catalog and auxiliary
> database and goes into the
> RMAN prompt and just hangs there........after some time, when I type
'exit'
> there out of frustration, I
> get the following errors :
>
> ./create_dupdb.sh[5]: run: not found
> /create_dupdb.sh[9]: allocate: not found
> /create_dupdb.sh[11]: allocate: not found
> /create_dupdb.sh[13]: setlimit: not found
> /create_dupdb.sh[14]: setlimit: not found
> /create_dupdb.sh[17]: /disk01/oradata/sid1/data/system01sid1.dbf: cannot
> execute
> /create_dupdb.sh[18]: to: not found
> /create_dupdb.sh[21]: /disk01/oradata/sid1/data/rbs01sid1.dbf: cannot
> execute
> /create_dupdb.sh[22]: to: not found
> /create_dupdb.sh[29]: /disk01/oradata/sid1/data/temp01sid1.dbf: cannot
> execute
> /create_dupdb.sh[30]: to: not found
> /create_dupdb.sh[33]: /disk01/oradata/sid1/data/tools01sid1.dbf: cannot
> execute
> /create_dupdb.sh[34]: to: not found
> /create_dupdb.sh[37]: /disk01/oradata/sid1/data/users01sid1.dbf: cannot
> execute
> /create_dupdb.sh[38]: to: not found
> /create_dupdb.sh[77]: duplicate: not found
> /create_dupdb.sh[79]: logfile: not found
> /create_dupdb.sh[80]: group: cannot execute
> /create_dupdb.sh[81]: group: cannot execute
> /create_dupdb.sh[82]: group: cannot execute
> /create_dupdb.sh[83]: syntax error at line 84 : `}' unexpected
>
> Could anybody please help me in identifying what is the problem and why
does
> it say 'run:not found' and the
> other subsequent lines ?? This is highly urgent for me !!
>
> Thanks and Regards,
> Samir
>
> Samir Sarkar
> Oracle DBA
> SchlumbergerSema
> Email : samir.sarkar_at_nottingham.sema.slb.com
> ssarkar2_at_slb.com
> Phone : +44 (0) 115 - 957 6028
> EPABX : +44 (0) 115 - 957 6418 Ext. 76028
> Fax : +44 (0) 115 - 957 6018
>
>
>
>
___________________________________________________________________________
> This email is confidential and intended solely for the use of the
> individual to whom it is addressed. Any views or opinions presented are
> solely those of the author and do not necessarily represent those of
> SchlumbergerSema.
> If you are not the intended recipient, be advised that you have received
this
> email in error and that any use, dissemination, forwarding, printing, or
> copying of this email is strictly prohibited.
>
> If you have received this email in error please notify the
SchlumbergerSema Helpdesk by telephone on +44 (0) 121 627 5600.
>
___________________________________________________________________________
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: SARKAR, Samir
> INET: Samir.SARKAR_at_nottingham.sema.slb.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Tim Gorman
INET: Tim_at_SageLogix.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Mon Apr 08 2002 - 09:53:23 CDT
