R

[82]Hi Guys We have 4 databases that have standby d...... Tso P Feb 11,
14:38
[87]Thanks Jan I have copied your script. Regard...... Tso P Feb 12,

Subject: DR sync
Os info: RHEL5
Oracle info: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0
- Production
Message: Hi Guys
We have 4 databases that have standby databases and we have a 10MB line
between our production server and the DR site.
Now, our standby databases keeps on lagging and it looks like its a
network throughput.
I checked one of the busiest database so that I can support my story:
1.) On Primary Database:
select EVENT, TOTAL_WAITS, TOTAL_TIMEOUTS, TIME_WAITED, AVERAGE_WAIT
from v$system_event
where event like '%LNS%'
or event like '%LGWR%' order by 4 desc;
EVENT TOTAL_WAITS TOT
AL_TIMEOUTS TIME_WAITED AVERAGE_WAIT
---------------------------------------------------------------- ----------- ---
----------- ----------- ------------
LNS ASYNC end of log 4478902
4478786 437962026 97.78
LNS wait on SENDREQ 829474
0 14921694 17.99
LNS wait on ATTACH 211
0 113031 535.69
LNS ASYNC control file txn 1516
1136 112892 74.47
LGWR-LNS wait on channel 87752
87751 94944 1.08
LNS ASYNC archive log 166
152 14855 89.49
LGWR wait for redo copy 117489
51 531 0
LNS ASYNC dest activation 3
3 293 97.76
LNS wait on DETACH 327
0 1 0
LNS wait on LGWR 323
0 1 0

2.) On Standby Database:
select EVENT, TOTAL_WAITS, TOTAL_TIMEOUTS, TIME_WAITED, AVERAGE_WAIT
from v$system_event
where event like '%RFS%' order by 4 desc;
EVENT TOTAL_WAITS TOT
AL_TIMEOUTS TIME_WAITED AVERAGE_WAIT
---------------------------------------------------------------- ----------- ---
----------- ----------- ------------
RFS write 242559
0 24989 .1
RFS dispatch 244213
0 11595 .05
RFS close 772
0 4844 6.27
RFS create 826
0 2172 2.63
RFS attach 56
0 20 .36

To me these results seems to suggest that the network bandwidth is the
culprit in this issue.
Or is the a way that I check how long it takes for the archivelogs to
be transported to the DR server?
Thanks in advance...
Please Help!!!


Subject: Re: DR sync
Message: Hi Tso
I would start with your REDO generation rate. As a start, look at
v$archived_log view. Something like the following statement:
SELECT (blocks*block_size) bytes,
(next_time - first_time)*24*60*60 seconds,
ROUND((blocks*block_size)/((next_time - first_time)*24*60*60)/1024/1024,
3) "mbytes/sec"
FROM v$archived_log
ORDER BY 3 DESC;

If your first row(s) show some number significantly higher than 10 (10
MB/s) in the last column, then you need a faster network-connection.
If the numbers are close to 10, then your standby will regularly fall
behind (keep in mind, these numbers are averages for a whole redo log).
If the numbers are lower, you might still get peaks were the connection
is not fast enough, but your standby should eventually catch up.
Regards,
Jan


Subject: Re: DR sync
Message: Thanks Jan


Subject: Re: DR sync
Message: Below are the results :
BYTES SECONDS mbytes/sec
---------- ---------- ----------
2560 7 0
2560 7 0
3072 8 0
3072 8 0
2560 8 0
2560 8 0
46205440 -37 -1.191
46205440 -37 -1.191
45245952 -12 -3.596
45245952 -12 -3.596
42971136 -10 -4.098

BYTES SECONDS mbytes/sec
---------- ---------- ----------
42971136 -10 -4.098
42971136 -9 -4.553
42971136 -9 -4.553
42971136 -3 -13.66
42971136 -3 -13.66

I presume that we have a network issues.
Thanks


Subject: Re: DR sync
Message: Hi Tso
Did you really copy-and-paste my SELECT statement? I don't think that
any database that returns negative numbers for
SELECT next_time - first_time FROM v$archived_log

can be considered production-safe.
Your query-result looks plain wrong to me.
Regards,
Jan


Subject: Re: DR sync
Message: Thanks Jan
I have copied your script.
Regards

Enregistrer un commentaire

0 Commentaires