RE: Re[2]: EM access to developers
- From: Iggy Fernandez <iggy_fernandez@xxxxxxxxxxx>
- To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Sat, 31 Jan 2015 09:19:16 -0800
re: "I wish you (DBAs) would stop telling me to change my queries, and just
tune the damned database!!".
We can't really blame them because we been telling them for two generations
that "the optimizer uses the optimal plan". That's a big fat lie of corse. The
optimizer does the best it can with obfuscated SQL, defective logical design,
inadeqate physical design, limited parsing time, limited information
(statistics), and limited capabilities (the optimizer is a continuous work in
progress with a very long way to go). It is a myth that the optimizer uses the
optimal plan; nobody has studied the success rate of this claim. The myth dates
back to the 1980s when the RDBMS salesmen where competing against network
technology but it has endured for two generations.
Since database administrators themselves believe this myth (as I did for a very
long time), they believe that tuning SQL, indexing, partitioning, etc are their
responsibility. But I now see that the application developers who develop the
application are responsible for all aspects of application performance. They
should have access to every sort of performance data, whether it be real-time
views into database and application performance; ASH, AWR, and Statspack
reports; and 10053 and 10046 traces, and they should understand how the
database works (undo, redo, temp, read consistency, etc).
If an application developer develops an application without consideration to
performance,without an understanding of performance issues, without access to
performance data, what are the chances that the developer will develop a
well-performing application?
But I'm preaching to the choir.
Iggy
Date: Sat, 31 Jan 2015 10:58:27 -0500
Subject: Re: Re[2]: EM access to developers
From: mark.brinsmead@xxxxxxxxx
To: kellyn.potvin@xxxxxxxxx
CC: dmarc-noreply@xxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
I can't fault this reasoning. Sharing information is how things are improved
just about anywhere, and certainly in IT.
I still maintain, though, that placing a large amount of data into the hands of
people who do not understand how to interpret it is a recipe for disaster. The
sort of disaster I have seen numerous times.
Training and education (along with an actual will to learn) are essential to
making this sort of thing successful. Where the resources and the will exist,
I am sure this will be wildly successful. Often I have dreamed of a world
where developers would analyse wait events and tune their own queries, but in
my present reality, I much more frequently hear things like "I wish you (DBAs)
would stop telling me to change my queries, and just tune the damned
database!!".
We all have a common goal -- effective and efficient IT services -- but
sometimes key people in the organiztion (DBAs, network administrators, or
system administrators, for example) are required to play the role of
"guardians" in order to prevent well intentioned people from doing themselves
harm. That can be a really tough balancing act, and one that we are rarely
thanked for performing.
One thing we probably all need is more "DBA" skills (or rather skills that we
have traditionally considered to be DBA skills, like query tuning and
performance management) on the development side of the IT department.
Premature tuning can be a costly mistake, but its usually nowhere near as
costly as letting a system go all the way to production before performance and
scalability are carefully considered.
On Fri, Jan 30, 2015 at 10:29 PM, <kellyn.potvin@xxxxxxxxx> wrote:
Mladen,
You proceeded to read one out of about every five words I wrote. Sharing
knowledge is how we are all more successful. I know a number of developers I
was told, "they'll never learn any new tricks..." and yet after learning how to
make the most of performance data, were able to produce better code in less
time.
For those that asked, EM Express is an excellent performance tool to allow
Developers to view the resource demands and wait events in database
environments, but that is a product fully installed on the user database and no
management agent. It doesn't have many of the management features that DBAs
liked in it's predecessor, DBConsole, but it was never meant to be. With EM12c
the product has far grown past just a DBA management tool- features like
database replay, (RUEI), middleware features, cloud management pack features
like Database as a Service that let's the DBA automate many of the tedious
tasks of provisioning and schema refreshes so they can be free to do more
interesting work that provides the business, with a self-service portal for
developers, PM's, etc. submitting requests. This is so all of IT can be more
successful, not just DBAs. Kyle already knows this, Delphix offers a similar
product as DBaaS, freeing up DBAs so they are no longer viewed as roadblocks
and lessen resource constraints.
This is not your father's Enterprise Manager.
Kellyn
Sent from myMail for iOS
Friday, January 30, 2015, 8:07 PM -0700 from Mladen Gogala
<dmarc-noreply@xxxxxxxxxxxxx>:
Responses in-line:
On 01/30/2015 09:37 PM, kellyn.potvin@xxxxxxxxx wrote:
>
>
> I saw too many IT departments remove DBA roles from their staff
> because DBAs were viewed as roadblocks to project success.
So have I. The IT departments that have done so have never succeeded, in
the long run.
> Attend a conference like ODTUG's KSCOPE and you'll hear this story so
> often from the developers that it will make you realize that the "us
> vs. them" scenario is making DBAs a liability instead of an asset.
DBA is the guardian of the production database, the person ultimately
responsible for its performance and availability. If the developer wants
to put a huge full table scan in an OLTP application and use PQ to
resolve it quickly, it's the DBA job to prevent that from happening,
because such query would consume resources needed for other programs. I
used to work as a production DBA in a companies with several thousands
of online users, using web applications. If DBA doesn't exercise a tight
control over the database, performance will ultimately become sluggish
for everybody. And that is a resume generating event. It's my job to
prevent that from happening.
> Steven Feuerstein often asks in his sessions, "of the DBAs in here,
> how many grant access to performance views in Enterprise Manager?" I'm
> often the only one who raises their hand and the common excuse is, "If
> we grant them access, then they'll be able to see things" Really.
Of course they will be able to see things, but would they be able to
interpret them correctly? Performance tuning requires certain training
and certain mindset. Developers are rarely trained for performance
tuning. From my experience, they don't show too much interest in the
performance analysis. You would be surprised to learn how many
developers still think in terms of buffer cache hit ratios.
>
> Well, here's the way I see it. No DBA has any excuse for complaining
> about the quality of code released in production if they aren't
> willing to provide developers and testing the same access to view
> performance data in tools such as Enterprise Manager as they have.
Why is that? What would you achieve by giving an access to trace files
to the person who doesn't know how to analyze them? What would you
achieve by giving access to all those performance monitors to the people
who are not sure how to interpret them? Instead of a diagnosis we would
get a debate about the meaning of the monitoring data.
> With more and more companies moving towards Agile, more companies
> using scrum masters/scrum collaboration, it is essential for everyone
> to understand the challenges they are up against and truly work as a team.
Agile is frequently used incorrectly and becomes the source of the
problem. The financial appeal of Agile is cutting the costs of QA. The
end result is frequently spewing large quantities of code, without DBA
being able to influence it. About 3 years ago, I resigned my DBA
position at a company which was doing Agile, precisely because of that.
There was an application code in the SYS schema. I am not a big fan of
Agile.
--
Mladen Gogala
Oracle DBA
http://mgogala.freehostia.com
--
//www.freelists.org/webpage/oracle-l
Other related posts:
