Re: select for update wait issues
Date: Tue, 14 Apr 2015 09:17:05 +0000
Message-ID: <CAFQ5AC+S5y7DfiPzP+rbwPx7smidfNWVfR9m8UGFJjTibR9aPA_at_mail.gmail.com>
I didn't want to speculate too much, but I had the same thought as Freek. Particularly since one of the events you saw was PR enqueue, which is process startup.....
More thorough analysis will tell the story.
-Mark
On Tue, Apr 14, 2015, 4:52 AM Freek D'Hooge <freek.dhooge_at_gmail.com> wrote:
> 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:
>
> 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-lReceived on Tue Apr 14 2015 - 11:17:05 CEST