26 July 2017
OEM: Metric "Redo Apply Rate (KB/second)" shows 0
We received an alert for one of our cluster standby databases, with OEM metric "Redo Apply Rate (KB/second) " showing 0, indicating there was no apply going on. When I checked DataGuard, it was showing consistent stream of redo apply, so async apply was working fine.
Cause
I searched through Oracle support site and Google, but there is no known bug in Oracle. I think this was caused by one instance applying the redo and the other doesn't. OEM must be reporting 0 because the metric is being calculating on the non-applying instance.
Workaround
Change the sql in Agent's PL file to look over both clustered instance, and take the maximum redo apply.
File:
/opt/oracle/middleware/agent12c/plugins/oracle.sysman.db.agent.plugin_12.1.0.6.0/scripts/db/dg/dgutil.pl
This is my workaround, not offical Oracle's, but it fixed our problem and has been running fine since.
From
{
$sql = "SELECT s.value*512/1000 KB_bytes from v\$sysstat s where s.name='redo blocks read for recovery'";
}
To
{
$sql = "SELECT max(s.value*512/1000) KB_bytes from gv\$sysstat s where s.name='redo blocks read for recovery'";
}
19 July 2017
Oracle bug: wrong spfile in init*.ora
Symptoms
Mon Jul 17 21:50:44 2017ERROR: Unable to get logical block size for spfile '+ORADATA3/PPEN/spfilePPEN.ora'.
Mon Jul 17 21:50:45 2017ERROR: Unable to get logical block size for spfile '+ORADATA1/PPEN/spfilePPEN.ora'.
Cause
The problem is caused by init*.ora file pointing to a non-existing spfile, while spfile instance parameter is pointing to the correct one.
Solution
Create an alias in ASM that matches the name in init*.ora file.
ASMCMD> pwd+oradata1/PPEN
ASMCMD> ls PARAMETERFILE/spfile.268.948615175
ASMCMD> mkalias PARAMETERFILE/spfile.268.948615175 spfilePPEN.ora
Labels: "ERROR: Unable to get logical block size for spfile" solution
