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 ...
