Sandra,
There has been discussions on this list in the past about performance
degradation after moving to T5 (when coming from an M class sparc) for
applications depending on single thread throughput.
I don't know if this is relevant in your case (certainly as I don't know
from which platform you are coming from), but the conclusion was that
the T5 had a lower performance on things like memory access.
This was notable in an sql trace, where the exec call was consistently
higher on a T5 compared to a M5000.
It could be that a (somewhat) lower per thread performance is just
tipping your application over and triggers a cascading of events.
Also as you mentioned log file syncs, which I think are sensitive to CPU
issues.
Ash / snapper would be indeed a good starting point to compare the 2
environments.
Also comparing the execution plans and maybe following up on specific
queries (identified with ash or snapper) with sql stracing.
Kind regards,
--
Freek D'Hooge
Exitas NV
Senior Oracle DBA
email: freek.dhooge@xxxxxxxxx
tel +32(03) 443 12 38
http://www.exitas.be
On ma, 2015-04-13 at 14:22 -0600, Sandra Becker wrote:
Contrary to what I was told this morning, we did have the option to
switchback to the old hardware. We had a standby running there.
Management decided we should switch because the application had ground
to a halt and customer transactions were rapidly queueing, which of
course led to a lot of customer complaints. So we're back on the old
hardware.
log file syncs were waiting as long as 15 minutes, the average was
about 7 minutes. Some buffer busy waits were over 20 minutes. Now
that we're back on the old hardware, the queue has been reduced and
we're processing in real-time again. I'm leaning towards the idea
that the problem lies in our new T5/EMC configuration. Maybe an
incorrect or missing parameter setting. We have engaged Oracle and
EMC to help troubleshoot all the performance issues on the new
hardware. This is only one of 4 databases we're having issues with on
the new hardware. We definitely cannot switch them all back to the
old hardware, which doesn't exist anymore in some cases.
During the switchback, we moved the redo logs, controlfiles, and
flash recovery area to faster disk. We decided to standardize. A
novel concept here.
I will definitely use the snapper.sql script on the other databases
still on the new hardware.
Thanks.
