Hi I can't be certain from your description of the probelm, but have you tried increasing the number of redolog groups?
I'm guessing that the problem is with Oracle reusing the online redo logs before they have been archived to the standby - The first half of the answer is to make the standby destination for archive logs mandatory to prevent this, but it does it by stopping the database until the log gets archived, and that's not a good answer by itself on a production system. If I'm right, the issue is the speed of the link to the standby database - it just can't transmit the archived logs as fast as the database produces them at peak load, so the redo logs get reused before they have been archived and the standby is left hanging. As a reminder, Oracle switches between its redo log groups, writing to each in turn and going back to the first one again once the last one has been written to - it is these online redo logs that are copied by the archiver processes to become archive logs. The other half of the answer is to increase the number of redolog groups, so it takes longer for Oracle to cycle back to the first one and therefore gives you longer to finish archiving the first one to the standby database. This works as long as the system slows down the switching and catches up with the archiving before it's run out of unused redo log groups. The slower your link, and the longer your high-activity periods, the more redolog groups you need. Increasing the number of archiver processes may have helped by starting to copy the archivelogs sooner, and I seem to remember Oracle suggesting 4 was a good number of archivers, but it doesn't deal with the underlying problem, which is producing archivelogs faster than you can archive them. The other answer to all this is to get a faster link between the two systems, but that's another issue entirely. Hope this helps - I'm currently working on a standby database project, so I've been looking at the same problems. Simon Anderson Please respond to [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> cc: (bcc: Simon Anderson/SSplc) Hi, ------Winnt 4.0, Oracle 8.1.7.------- We have slight problem with our Standby Database Configuration. All the archives from our Primary Database are not being copied to the Standby Database. When the archives are generated at a normal time, i.e after after a gap of 15-20 minutes ( which is normal, as our logfile size is 500K and it works fine with our normal database behaviour) , the archives get copied completely to the standby site. But due to a few jobs that run over night, the log switch happens very fast,a few times per minute. This kind of fast switching also happens incase of bulk insert or delete. Its in such cases that some of the archive logs are not copied to the standby site. To counter that, we increased the number of archiver processes from 1 to 4 on the Primary site, and when it didn't entirely solve our problem, we increased it to the maximum, i.e is 10. Even now all the archives are not being copied because of the quick switching of logs. Keeping the archiver processes to 10 is also a burden on the resources. Moreover, the second destination for writing archives(standby DB) is optional, and the value for log_archive_min_succeed_dest is set to 0. I am not sure increasing this or changing the site from optional to mandatory would solve the problem. Or would that have any effect? The other thing is that since the problem lies with the files not being copied from one site to the other, so it should not directly have anything to do with the Archiver processes, as server is generating archives properly. But on increasing the number of archiver processes, less number of files were not copied to the standby site, so it did help. Is there something we are missing here. Any help would be appreciated. Regards, Hussain Ahmed Qadri Database Administrator Shaukat Khanum Memorial Cancer Hospital & Research Centre [EMAIL PROTECTED] www.shaukatkhanum.org.pk -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
