RE: Stanby Database- Archive Transfer Problem

The quick answer to this one is : Try using more online redologs, adding them is a fairly simple RTFM.

>From looking at the setup you describe, I think you have two issues with your
standby database. Which one you fix will depend on how you want the system to behave.

It looks like you are using the 'default' standby database config, where you let Oracle take care of copying the archived redo logs to the standby database. I'd also guess that you have set the remote archive destination to OPTIONAL, so the database will abandon the attempt to copy the file if it fails.

What seems to be happening is that your system is switching through the redo logs faster than it can transmit them to the standby database. You are only using 4 redologs, so when it finishes writing to the fourth one and tries to start writing to the first one again, it has not finished copying it to the standby database. With the archive destination for the standby database set to OPTIONAL, it will abandon the attempt to copy the file rather than stopping the production database until the transfer is complete.

That would explain the missed files and give you two possible solutions:

You could make the archive_log_dest_2 MANDATORY - this would avoid missed files, but your production database will stop dead until the transfer is complete. This is probably a bad idea on its own.

You can make it more likely that the archived redo log will be copied across before the system needs to reuse that online redo log. Ideally, you do this by getting a better network, but thats probably not an option. The other answer is to have more than four online redologs, so it takes longer to wrap round to the first one again. More online redologs will compensate for short holdups in the network, but it isn't guaranteed - if you keep switching logs faster than you can transfer them, then sooner or later you will run into the same problem.

Increasing the number of Archive processes helped the first time because each file to be transferred got picked up as soon as it was ready, but I don't think theres any point having more archive processes than you have redo logs - theres nothing for the extra processes to do.

It could be some deeper problem with the network, but its probably just slow - you can check by measuring the time it takes to send a 1Mb file between the two computers when the system gets busy.

Hope this helps, theres much more info on Metalink

Simon Anderson

Please respond to ORACLE-L_at_fatcity.com

To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> cc: (bcc: Simon Anderson/SSplc)

If you find a solution for this, I would be interested in it. We have the same problem, same platform. Somatimes SAP starts some kind of processing and the network load increases enormously. And the archive log transfer fails after a while.

Tamas Szecsy

-----Original Message-----
Sent: Thursday, April 04, 2002 10:28 AM
To: Multiple recipients of list ORACLE-L

Oracle 8.1.7 and WINNT4
Our Standby database was running smoothly but due to some reasons we had to reconfigure it.
We have used the same init parameter file which we used earlier(to have the exact parameters). The standby database was configured alright but this time logs are not properly getting transfered to the standby database, I mean every 3rd or 4th archived log file doesn;t get transfered and is missed.

Our 4 redo logs are 1mb and block size is 8192, Log_checkpoint_interval = 10000 (the default) and log_checkpoit_timeout = 600

Archive processes are 10(this we had increased to 5 the last time to counter the missin files on our standby database,and it worked fine,but this time we have increased from 5 to 10 and its not) and the view v$Archive_dest shows that both primary and standby database locations are valid.

Average time for log switch, under normal conditions, is roughly 12-15 mins, but for some reasons it starts getting missed after a regular transfer of 3-4 archive files.

Our network is 10Mbps and is sllow off and on.

What could be the reason for the delay.

Hussain Ahmed Qadri
Database Administrator
Shaukat Khanum Memorial Cancer Hospital & Research Centre hussain_at_skm.org.pk
www.shaukatkhanum.org.pk

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: Simon.Anderson_at_scisys.co.uk

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: ListGuru_at_fatcity.com (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).