Hi
Can you try to identify the number of commits when that happens plus the
IOPS?
I had a similar problems years ago, it turns our in the code a loop ran
2500 commits per sec
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Mon, Oct 7, 2019 at 5:20 PM Herring, David <dmarc-noreply@xxxxxxxxxxxxx>
wrote:
Folks, I've got a bit of a mystery with a particular db where we're
getting a periodic 25-30 pause between user sessions and LGWR processes and
can't clearly identify what's the cause.
- The database is 11.2.0.4, RHEL 7.5, running ASM on EMC.
- Sometimes once a day, sometimes more (never more than 5) times a day
we see user processes start waiting on "log file sync". LGWR is waiting on
"log file parallel write".
- At the same time one of the emcpower* devices shows 100% busy and
service time 200+ (from iostat via osw). mpstat shows 1 CPU at 100% on
iowait. It's not always the same disk (emcpowere1, a1, h1, …), not always
the same CPU. EMC and sysadmins have confirmed there are no disk errors
and from their standpoint the disks are waiting on Oracle.
- During this time LGWR stats in ASH are all 0 - TIME_WAITED, DELTA*
columns. Only after the problem goes away (about 25 secs) these columns
are populated again, obviously the DELTA* columns 1 row later. LGWR's
session state is WAITING so I assume the column value observations are due
to LGWR waiting, as it won't write stats until it can do something.
I am stuck trying to find out, really prove who is the culprit or what
exactly the wait is on. Is LGWR waiting on user sessions and user sessions
are waiting on LGWR and all that causes the disk to be 100%? Can I enable
some sort of tracing on LGWR and would that point to exactly what he's
waiting on to prove where the problem is?
Regards,
Dave
