Gotcha. So, what does log_archive_dest_1 and log_archive_format look like on 1. Target 2. Auxiliary Bradd Piontek On Mon, Oct 4, 2010 at 1:58 PM, Taylor, Chris David < ChrisDavid.Taylor@xxxxxxxxxxxxxxx> wrote: > Well, in my case I’m doing an UNTIL TIME. > > > > I have my backups copied from 8pm last night. I copied over my archivelogs > to the local filesystem from 8pm until just after the UNTIL TIME. > > So: > > Copied 8pm backup to aux server > > Copied 7:30pm->8:30am archivelogs to aux server log_archive_dest_1 directly > from the log_archive_dest_1 on the primary server > > > > Here’s the RMAN script I used. When it tried to recover, it complained > about not being able to find the logs since they were in a different > location on the aux database server. To get around this, I backed up the > archivelogs on the primary and shipped them to the backup location the aux > server. The recover then restored the archivelogs to log_archive_dest_1 > folder on the aux server. > > > > > > (This is a LAB server – test box only so keep that in mind) > > run > > { > > allocate channel d1 type disk; > > allocate channel d2 type disk; > > allocate channel d3 type disk; > > allocate channel d4 type disk; > > allocate auxiliary channel a1 type disk; > > allocate auxiliary channel a2 type disk; > > allocate auxiliary channel a3 type disk; > > allocate auxiliary channel a4 type disk; > > set until time="to_date('10/04/2010 08:00:00','MM/DD/YYYY HH24:MI:SS')"; > > > > duplicate target database to F9PRD2 > > logfile > > GROUP 1 > > ( > > 'F:\oracle\oradata\F9PRD2\onlinelog\redo01b.log' > > ) size 25M, > > GROUP 2 > > ( > > 'F:\oracle\oradata\F9PRD2\onlinelog\redo02b.log' > > ) size 25M, > > GROUP 3 > > ( > > 'F:\oracle\oradata\F9PRD2\onlinelog\redo03b.log' > > ) size 25M; > > } > > > > *Chris Taylor* > > *Sr. Oracle DBA* > > Ingram Barge Company > > Nashville, TN 37205 > > Office: 615-517-3355 > > Cell: 615-663-1673 > > Email: chris.taylor@xxxxxxxxxxxxxxx > > > > *CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential > and may also be privileged. If you are not the named recipient, please > notify the sender immediately and delete the contents of this message > without disclosing the contents to anyone, using them for any purpose, or > storing or copying the information on any medium.* > > > > *From:* Bradd Piontek [mailto:piontekdd@xxxxxxxxx] > *Sent:* Monday, October 04, 2010 1:46 PM > *To:* Taylor, Chris David > *Cc:* oracle-l@xxxxxxxxxxxxx > *Subject:* Re: RMAN duplicate question regarding archivelog file locations > on different server > > > > Chris, > What does your duplicate command look like? (are you restoring to an > SCN?) By default , iirc, DUPLICATE will attempt to restore to the most > current SCN on the 'target' database. As a previous email stated, > log_archive_dest_<n> and log_archive_format will tell your auxiliary > database where to look for archivelogs (and where to restore them to). it > sounds more to me like you are duplicating to a point in time too current > (unless you manually copy or back up the archivelogs). > > I tend to get an SCN from the latest backup controlfile and use that as my > DUPLICATE TO SCN number. > > Bradd Piontek > > On Mon, Oct 4, 2010 at 10:55 AM, Taylor, Chris David < > ChrisDavid.Taylor@xxxxxxxxxxxxxxx> wrote: > > I’m running a duplicate command to clone a database over to a dev server > and the disk drive letters are different on the secondary server for the > archivelogs. My backup disk location is the same on both servers. > > > > Is there a way when doing a duplicate to tell RMAN to look in an alternate > location than where the primary sends its archivelogs? > > > > I’m receiving the RMAN-06025: no backup of log thread 1 seq 93814 lowscn > 8775725044 found to restore error since the archivelog paths are different. > > > > To get around this, I’ve backed up the archivelogs on the primary and > copied those backups and I believe the restore will work from that point but > it seems like there should be an easy way to have alternate file locations > when doing a duplicate. > > > > Thanks, > > > > *Chris Taylor* > > *Sr. Oracle DBA* > > Ingram Barge Company > > Nashville, TN 37205 > > Office: 615-517-3355 > > Cell: 615-663-1673 > > Email: chris.taylor@xxxxxxxxxxxxxxx > > > > *CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential > and may also be privileged. If you are not the named recipient, please > notify the sender immediately and delete the contents of this message > without disclosing the contents to anyone, using them for any purpose, or > storing or copying the information on any medium.* > > > > >