Hi Charlotte,
Was there a backup running at the time?
Cheers,
Leng
On 21 Jun 2022, at 9:33 pm, Charlotte Hammond <dmarc-noreply@xxxxxxxxxxxxx>
wrote:
Thanks Mladen,
No, it's not Activate Data Guard - it's just vanilla standby. While there
are some direct physical reads on the primary at the same time as the apply
lag, there are other times of day which these are much higher and there is no
lag on the standby then.
The processing load on the primary hasn't really changed much in years - so
I'd be surprised if there were any significant change in delayed block
cleanout nor anything else really. Nightly broad brush CPU/disk/memory on
primary is indistinguishable from before the lag started appearing last week.
I'm not sure it's worth pursuing as transport lag is zero which is fine -
just means there's a slight extra delay if we need to failover in the middle
of the night. It's more an exercise in why is this suddenly happening after
years of stability, and nervousness that it's a symptom of something going
bad!
Thanks!
Charlotte
On Monday, June 20, 2022, 08:42:02 PM GMT+1, Mladen Gogala
<gogala.mladen@xxxxxxxxx> wrote:
On 6/20/22 12:54, Charlotte Hammond (charlottejanehammond) wrote:
Hi All,
We've got a Standby database which has the apply lag suddenly started to peak
at 10 minutes overnight during peak processing times, whereas previously it
was near zero. As usual everyone claims "nothing has changed" !
The only OEM tracked metric that seems to have changed is "Physical Read
Direct" which is now bursting at the same times as we are getting the apply
lags, whereas before it was negligible. Redo rates at these times as the
same as before and other CPU, Disk and Memory metrics seem pretty much the
same. The destination is SYNC AFIRM and the transport lag is pretty much
zero.
Any suggestions on how to diagnose this? I'm not really looking to fix it
right now, just find out what has caused it to start happening (19.14).
Thanks for any tips!
Charlotte
Hi Charlotte,
Is this an active DG? If it is, then a full table scan may cause direct
reads. If it isn't, it maybe caused by delayed block cleanout. If you have
delayed block cleanout taking place on the primary side, it will have to be
done on the standby as well. Can you please check whether you have the direct
physical reads taking place on the primary, at the same time? If the standby
is not open, than the standard techniques relying on AWR and ASH are not
available. You may have to open a ticket with Oracle Support.
Regards
--
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com
-- //www.freelists.org/webpage/oracle-l
