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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx>
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.
