· a physical standby database. The faster one doesn’t
seems like the likely difference to me. Did I miss the protection mode? How far
away (ping latency) is the standby?
Do you have the ability to set up on the new box with the only change being no
physical standby?
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Harel Safra
Sent: Thursday, April 23, 2020 12:31 PM
To: Paul.Houghton@xxxxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Redo per transaction inconsistency when running SLOB
Hi,
Any chance the slower one with the standby is set to force logging while the
faster one isn't? Are there nologging operations in the database?
Harel
On Thu, Apr 23, 2020 at 2:29 PM Paul Houghton <Paul.Houghton@xxxxxxxxxxxxx>
wrote:
Hi
We have some new hardware which seems slower from an IO perspective than the
old hardware, so I downloaded SLOB to investigate, and ran it on two databases
which are copies of each other. Both on RHEL7 OS with Oracle 12.2.0.1 and the
April critical patch. Both are in archive log mode. Looking into the AWR, it
seems the slower one on the new hardware is generating more redo per
transaction than the old one. I set up SLOB identically in both databases
(./setup.sh IOPS 8) and ran it identically (./runit.sh 8). The tablespace is a
smallfile and I specified it’s location, but otherwise I used the defaults. I
set up the admin user as “sys/sys as sysdba” and for this run changed the run
time to 900 seconds.
There are some differences in configuration. The slow one is supposed to be
more like production than the faster one, so it has:
· bigger buffers the log buffer is 10M as opposed to 5M in the faster
one
· uses huge pages, where the fast one doesn’t
· LOST_WRITE_PROTECT is NONE in both environments.
· a physical standby database. The faster one doesn’t
There are applications running against these databases, but I can’t see that
there was any application SQL that would make this much difference.
I am looking in the load profile section of the AWR report that is generated.
Redo size per transaction is 54K for the faster one, and 203k for the slower
one, so about 4x as much. What could be causing this?
I’d be grateful for some pointers as to where I can look to see what is causing
the extra redo.
Thanks
PaulH
