Re: Stanby Database- Archive Transfer Problem

What do the interface stats look like?

netstat -i

If you have excessive interface errors (sounds like you do) then set up a private lan between the primary and standby, after you wake the guy who is responsible for lan operations.

On Thu, Apr 04, 2002 at 03:28:20AM -0800, Simon.Anderson_at_scisys.co.uk wrote:
>
>
> 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).

-- 
===============================================================
Ray Stell   stellr_at_vt.edu     (540) 231-4109     KE4TJC    28^D
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Ray Stell
  INET: stellr_at_cns.vt.edu

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).