Re: Oracle DB performance tuning training
Date: Sat, 22 Aug 2015 10:34:59 -0700
Message-Id: <C21CC83D-B0CE-4D28-832D-9CC4A9C78AEB_at_oracle.com>
Poor Deborah - I guess this vibrant thread has posed more questions than answers you needed.
The answer ANY DBA is likely to give you for any question posed is first - "it depends" ! After all, we all know what DBA really stands for, right - Don't Bother Asking. Besides sounding a little flippant, there's some sense in it.
Seriously, gone are the days of designing SQL code on set RULES (for the optimiser to evaluate), evolving into COST basis. As the RDBMS engine has further evolved, we are told to write the code and the "system" will evaluate the optimal execution plan. We no longer need to have distinct databases (DWH, OLTP, Hybrid etc), and of course data volumes have ballooned whilst hardware resources have correspondingly improved vastly.
We go back to the old axiom, "prevention is better than a cure", ie good design, and Developer & DBA teams being in sync with both user / business / system requirements and available resources. I know many will accuse this statement of being idealistic, but that is why Design, Development, Testing, Implementation theories exist.
Checking out.
On Aug 22, 2015, at 5:41, Stéphane Faroult <sfaroult_at_roughsea.com> wrote:
>
>
>>> From my field experience with clients - they usually take the following from such a class: >>> >>> 1) End user complains about performance >>> 2) Look at top wait events in graphical representation in EM or top section in AWR in this time window >>> 3) Analzye and reduce it with the mentioned and trained tools >>> 4) Result = Happy end user >>> >>> ... and we all know that this does not work out well in an effective way (otherwise we would be jobless). A lot of work time in organizations is >>> wasted on tuning wait event <X> without any notice to the complaining end users, just because of some tools show some high colorful graphs :-) >>>
>
> If I may add my $0.02, what Stefan describes looks horribly familiar to me, and what I have also seen is meetings where the DBA was all talking about wait events, and the developers at the same table had no clues
> 1) about what he was talking about
> 2) about how "wait events" could relate to their own code
> I have vivid remembrances of the faces of developers when an ebullient DBA was talking to them about a "buffer busy" problem. Even when explained what it means, they couldn't see how it related to their code.
>
> Which means that even "tuning wait event <X>" is often only possible through what I call the "magical parameter dance", changing that more or less obscure parameter that will bring a 5% improvement that no end user will notice.
>
> One of the problems of performance classes is that (I know it's bad for business) their goal should not be to give attendees a list of buttons to push, but to enable them to educate their own developers and evangelize them. All the more as people who are sent to (often expensive) classes are relatively experienced and senior people in an organization, and aren't the ones that code. If they don't get the global picture and aren't able to explain it to others, it's a waste of time and money (networking aside). When after the course they make developers understand why what Hibernate does behind the scene is bad and how THEY (developers) could change it, then there is hope.
>
> Stéphane Faroult
> --
> http://www.freelists.org/webpage/oracle-l
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Sat Aug 22 2015 - 19:34:59 CEST