Re: select for update wait issues

  • From: kathryn axelrod <kat.axe@xxxxxxxxx>
  • To: Sandra Becker <sbecker6925@xxxxxxxxx>
  • Date: Thu, 16 Apr 2015 23:06:28 -0700

I'm curious - what changes were made to the mounts (before/after)?

On Thu, Apr 16, 2015 at 9:45 AM, Sandra Becker <sbecker6925@xxxxxxxxx>
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@xxxxxxxxx>
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@xxxxxxxxx>
wrote:

Mladen knows about t5 he's just using that wry humor ...






--
Sandy
GHX

Other related posts: