Re: select for update wait issues
Date: Thu, 16 Apr 2015 10:45:46 -0600
Message-ID: <CAJzM94DS2zYT43iRgR7W0i2_A-j=OQRPgquZFiypt4JV5Oqxrg_at_mail.gmail.com>
Lots of good information. Thank you. Comparison of execution plans showed they were identical. Code hasn't been changed in 3 years. Only change was the hardware. Then we started noticing other databases we migrated were also performing sub-optimally to the point the applications were unusable.
We engaged Oracle support and Technologent (who recommended the EMC SAN). Lots of reports and discussions transpired. Only yesterday did I find out that the SE team did not configure the SAN in the manner recommended by Technologent. This was on top of the SE team not configuring mounts the way I requested for redo logs, flashback logs, and controlfiles.
So here's what we did for the worst performing DB:
- Set up mounts for the redo, flashback, and controlfiles as I originally requested (and Technologent also recommended)
- Migrated the LUNs to a new pool that had FAST CACHE disabled
Performance is acceptable again. Playing some catch up as far as getting the last 2 weeks of data loaded so it will be interesting to see the final effect once we are real-time with everything again.
Sandy
On Tue, Apr 14, 2015 at 4:32 PM, MARK BRINSMEAD <mark.brinsmead_at_gmail.com> wrote:
> Ah. Wry. Got it.
>
> :-)
>
> Somehow, I didn't think I needed to explain the difference between
> response time and throughput. That's why I stopped at a "clever analogy".
> Also somewhat wry, I guess.
>
> On Tue, Apr 14, 2015 at 6:21 PM, John Hurley <hurleyjohnb_at_yahoo.com>
> wrote:
>
>> Mladen knows about t5 he's just using that wry humor ...
>>
>>
>>
>
-- Sandy GHX -- http://www.freelists.org/webpage/oracle-lReceived on Thu Apr 16 2015 - 18:45:46 CEST