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 [EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
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
[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).
