Re: Physical Reads Direct on Standby

Hi Charlotte,

Was there a backup running at the time?

Cheers,
Leng

> On 21 Jun 2022, at 9:33 pm, Charlotte Hammond <dmarc-noreply_at_freelists.org> 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_at_gmail.com> 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
> -- http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l