Re: select for update wait issues
Date: Tue, 14 Apr 2015 10:52:30 +0200
Message-ID: <1429001550.8215.23.camel_at_dhoogfr-lpt1>
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_at_exitas.be tel +32(03) 443 12 38 http://www.exitas.be On ma, 2015-04-13 at 14:22 -0600, Sandra Becker wrote:Received on Tue Apr 14 2015 - 10:52:30 CEST
> 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.
>
>
>
-- http://www.freelists.org/webpage/oracle-l