Re: Duplicate from active database failing with ORA-19625 , ORA-27037 for archivelogs

Sandra,

If RMAN works out that no redo has been applied, it doesn't try to restore the datafiles again, so you _might_ get away with that. From this distance I'd suspect that the sym link is not working for you. I'd probably try copying the archivelogs from the old host to /backup. (This is just distant advice with limited information to go on, so don't shoot the messenger if it doesn't work. )

Hmm, come to think of it, it might not be the sym link. Came across an obscure bug with mounting files remotely which maps to your problem closely from the limited amount I can recall about it. Copying archivelogs might get you past that as well, if that's what's going on.

RMAN has DEBUG and TRACE=filename command-line options. They may tell you exactly where the problem lies.

Good luck!

Regards,

John Thomas
Database Designer and Administrator
https://oracleexpert.net

On Thu, 31 Jan 2019 at 22:38, Sandra Becker <sbecker6925_at_gmail.com> wrote:

> I am connecting to the target database on the remote host and the
> auxiliary on the local host. I was mainly showing the basics of what I had
> in the script.
>
> the active database's archivelogs are on a mount called /backup. Since
> the new host already had a /backup, we NFS mounted the active host's
> /backup as /backup2. I then set up a sym link on the new host's /backup
> and verified I could see the active database's archivelogs.
>
> No errors seen regarding the controlfile. I see "backup as copy current
> controlfile auxiliary format..." I do see the controlfile in the directory
> when I check.
>
> The log_file_name_convert is in the init.ora and it seems to be working as
> expected.
>
> I have another DBA telling me that running the duplicate through a shell
> script is "old school" and not necessary. The initial duplicate to get the
> datafiles copied took over 24 hours. I did the script to ensure that if
> something happened to my session, the duplicate would continue running in
> the background. Was this really not necessary? Would starting RMAN and
> issuing the duplicate command have been sufficient?
>
> Sandy
>
> On Thu, Jan 31, 2019 at 2:13 PM John Thomas <jt2354_at_gmail.com> wrote:
>
>> Sandra,
>>
>> You mention your source is on a remote system, but connect target does
>> not show you connecting to the remote. Maybe there's just some detail
>> missing.
>>
>> Difficult to see what's going on without the logs.
>>
>> But are you mounting the active databases archivelogs over NFS or
>> similar? If so, is the path slightly different on the new server?
>>
>> What does the log say about the controlfile? That's where the records of
>> the logs are so if the controlfile restore has got the wrong version of the
>> controlfile... Specifying log_file_name_convert or db_recovery_file_dest on
>> the duplicate command might help.
>>
>> Sorry, a bit like flying with half a blindfold on without seeing the
>> logs...
>>
>> Regards,
>>
>> John Thomas
>> Database Designer and Administrator
>> https://oracleexpert.net
>>
>>
>> On Thu, 31 Jan 2019 at 20:55, Sandra Becker <sbecker6925_at_gmail.com>
>> wrote:
>>
>>> Oracle 11.2 on RHEL
>>>
>>> I have been trying to duplicate a production database to a new server to
>>> do some baseline testing. This is not a situation where I can do a
>>> duplicate for standby and the auxiliary database must have a new name. I'm
>>> able to get the datafiles restored without a problem. The duplicate is
>>> failing to find/copy all the archivelogs it needs. Sometimes it can't find
>>> a log with a sequence between two others it did find. For example, it
>>> found 730 and 737, but did not find 731 through 736. All logs still exist
>>> on the old server.
>>>
>>> My duplicate script is pretty simple:
>>>
>>> connect target
>>> connect auxiliary
>>> run
>>> {
>>> allocate channel t1 type disk;
>>> allocate channel t2 type disk;
>>> allocate channel t3 type disk;
>>> allocate channel t4 type disk;
>>> allocate auxiliary channel a1 type disk;
>>> allocate auxiliary channel a2 type disk;
>>> allocate auxiliary channel a3 type disk;
>>> duplicate target database to baseline from active database
>>> nofilenamecheck;
>>> release channel t1;
>>> .
>>> .
>>> .
>>> release channel a3;
>>> }
>>> exit
>>>
>>> Unfortunately, I cannot post the entries from the log due to security
>>> policies, but I'll try for a synopsis.
>>>
>>> - After restoring datafiles (or using previous duplicated file), it
>>> does an alter system archive log current and then the set new name commands
>>> - I see "backup as copy reuse" and then a list or archivlogs with
>>> the current primary archive log location then the auxiliary format with
>>> that location
>>> - Next catalog clone datafile copy
>>> - switch clone datafile to datafilecopy
>>> - executing memory script
>>> - Starting backup
>>> - skipping archived log for logs already copied from previous run,
>>> then input archived log
>>> - finished backup
>>> - catalog archived log
>>> - instance started
>>> - alter system to set db_name and reset db_unique_name
>>> - shutdown
>>> - release channels
>>> - Error stack indicating it can't find an archivelog
>>>
>>>
>>> Q1: Why isn't the duplicate copying all the logs if they are on disk?
>>> Q2: Can I manually copy the logs before I start the duplicate?
>>> Q3: How can I find all the logs that I will need?
>>>
>>> Frustration level is pretty high since my deadline is Monday and I've
>>> been working on this for over a week. Any help/suggestions would be
>>> greatly appreciated.
>>>
>>> Thank you,
>>>
>>> --
>>> Sandy B.
>>>
>>>
>
> --
> Sandy B.
>
>

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