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, [EMAIL PROTECTED] 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 [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).

-- 
===============================================================
Ray Stell   [EMAIL PROTECTED]     (540) 231-4109     KE4TJC    28^D
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Ray Stell
  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).

Reply via email to