PDA

View Full Version : Return Code 6001


RichardChambers
02-22-2012, 02:34 AM
I am trying to get the Primary database to be able to work with RMAN whilst also running DBVisit.

I have modifed my RMAN script to the following

DELETE NOPROMPT OBSOLETE RECOVERY WINDOW OF 2 DAYS;

and it runs fine but DBV gave an error. So I recreated the standby database, which seemed to work fine and restarted but when I ran ./dbvisit LHUNGARY I got the above return code.

I attach the screen shots and 2 trace files as well as a screen shot of my RMAN script. I have just noticed the item highlighted 'delete input'. Should this be removed? (The file is too large to upload to the forum. I will send it by email) I have uploaded the 2 trace files to the forum.

Many thanks.

Regards
Richard Chambers

Arjen Visser
02-22-2012, 07:46 AM
Hello Richard,
The error is:
"Dbvisit Standby searched for log files, but could not find log file to transfer for sequence 25"
This probably means that RMAN has deleted the archive log file before Dbvisit had a change to transfer the archive log file to the standby server.

When setting RMAN parameters, ensure you allow for enough window for Dbvisit to transfer the archive log file before RMAN removes it.

Alternatively you can use RMAN to backup the archive log files, and use Dbvisit to remove the archive log files. This way you are ensured that the archive log file is transfered to the standby server before Dbvisit will deleted them.

Please see http://www.dbvisit.com/forums/showthread.php?t=237 for more details

Regards,

RichardChambers
02-22-2012, 10:04 PM
Hi Arjen,

Thanks for the reply, I understand what settings have to be changed on RMAN but in the meantime how do I clear this return code 460? I have done a backup standalone, created a new standby database but when I run ./dbvisit LHUNGARY on the Primary server I still get the same error message.

I have run it with the -R option. How do I get the log files dbvisit is expecting synchronised with the actual log files we have?

Thanks

Regards
Richard Chambers

Arjen Visser
02-22-2012, 10:12 PM
Hi Richard,

Unfortunately the standby database needs all archive log files in sequence. You cannot skip one.

If an archive log file is missing you have 3 options:
1) Restore the archive log file from backup and then run Dbvisit to transfer the archive log file to the standby server.

If you cannot restore the archive log file from backup then:
2) Rebuild the standby database from scratch using Dbvisit (dbvisit_setup, option 7)
3) Resynch the standby database using incremental backup using RMAN. Please see http://www.dbvisit.com/forums/showthread.php?t=1413

Please let us know which option you have used and any feedback that may useful for the forum.

Kind regards, Arjen

RichardChambers
02-22-2012, 10:32 PM
Hi Arjen,

Thanks for the quick response.

The archive log files are there in the /u08/oradata/LHUNGARY/archivelog folder. I have verified the RMAN backup with no errors so as far as I can tell the database itself is OK.

I will create the standby database again and see what happens.

Regards
Richard Chambers

RichardChambers
02-23-2012, 12:21 AM
Hi Arjen,

No change. I have recreated the standby database several times and it keeps failing when running ./dbvisit LHUNGARY after completeing the standby database. The sequence number it says it cannot find is always the latest log file there. (we are up to 37 now) and all the log files are located where they are supposed to be.

Can you tell from the trace files that I sent you which directory it is looking for to find the log files (it should be /u08/oradata/LHUNGARY/archivelog)

If I do a ./dbvisit -R LHUNGARY it says that the log file 36 cannot be found. Even if I do it several times.

I changed the ARCHLOG_PREFIX from arch to log (which is what the log files all start with). I have also tried this with a blank parameter or arch but it seems to make no difference.

I attach the env file on the Primary server to see if you can spot anything in it that might cause this issue.

Thanks
Regards
Richard Chambers

Mike Donovan
02-23-2012, 03:09 PM
Hello Richard,

In reviewing one of the earlier trace files we can see that Dbvisit Standby is looking in the following locations for the archive logs to transfer on the primary side:
20120221 13:56:03 main::tra_get_last_archive-> ===>FORMATS
20120221 13:56:03 main::tra_get_last_archive-> searching for search_pattern=/u01/app/oracle/oraarch/LHUNGARY/log_LHUNGARY_1_26_775756018.dbf
20120221 13:56:03 main::tra_get_last_archive-> searching for search_pattern=/u01/app/oracle/oraarch/LHUNGARY/archlog_LHUNGARY_1_26_775756018.dbf
20120221 13:56:03 main::tra_get_last_archive-> searching for search_pattern=/u01/app/oracle/oraarch/LHUNGARY/log_LHUNGARY_1_26_775756018.dbf
20120221 13:56:03 main::tra_get_last_archive-> searching for search_pattern=/u01/app/oracle/oraarch/LHUNGARY/archlog_LHUNGARY_1_26_775756018.dbf
20120221 13:56:03 main::tra_get_last_archive-> searching for search_pattern=/u01/app/oracle/oraarch/LHUNGARY/*1_26_*
20120221 13:56:03 main::tra_get_last_archive-> searching for search_pattern=/u01/app/oracle/oraarch/LHUNGARY/arch*1_26_*
20120221 13:56:03 main::tra_get_last_archive-> searching for search_pattern=/u01/app/oracle/oraarch/LHUNGARY/thread_1_seq_26.*
20120221 13:56:03 main::tra_get_last_archive-> searching for search_pattern=/u01/app/oracle/oraarch/LHUNGARY/archthread_1_seq_26.*

Does this resemble the actual form of the archive logs on your system?
If so do they exist in this form in any of these locations?

One other thing to try would be to set IGNORE_ARCH_HIST = Y.
Details relating to this are as follows:

#--------------------------------------------------------------------------
# Variable: IGNORE_ARCH_HIST
#
# Default value: No
# Possible values: Yes, No
#
# Description: This forces Dbvisit to use its own internal mechanism to
# find the next log file to transfer to the standby database.
# Normally this variable is set to No, but during
# initial Dbvisit testing, setting this to Yes is useful,
# as the archive log file to transfer to the standby database
# is not always easily available in Oracle, especially if
# there has been a network outage and the standby database
# has not been updated for a while.
#
# Sample:
# IGNORE_ARCH_HIST = No
#--------------------------------------------------------------------------
IGNORE_ARCH_HIST = N

Kind regards,
Mike Donovan

RichardChambers
02-23-2012, 09:27 PM
Hi Mike,

Thanks for the reply.

The log files are located on the /u08/oradata/LHUNGARY/archivelog folder and are in the format log_LHUNGARY_1_26_775756018.dbf

I did create the folder /u01/app/oracle/oraarch/LHUNGARY because DBVisit requested it. How the data is supposed to get into that folder on the Primary Server I don't know.

I have changed the setting ALT_ARCH_LOCATION to the u08 one and that resolved the issue. Log files are now transferring.

Thanks.
Regards
Richard Chambers