Re: select for update wait issues
Date: Thu, 16 Apr 2015 23:06:28 -0700
Message-ID: <CAEbHM44iQmCAm=pLuZUe6oB4wb6Fi4av8y-nLtLd8w2HF98yQw_at_mail.gmail.com>
I'm curious - what changes were made to the mounts (before/after)?
On Thu, Apr 16, 2015 at 9:45 AM, Sandra Becker <sbecker6925_at_gmail.com> wrote:
> 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 Fri Apr 17 2015 - 08:06:28 CEST