Re: EM access to developers
- From: "Mladen Gogala" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "mgogala@xxxxxxxxx" for DMARC)
- To: oracle-l@xxxxxxxxxxxxx
- Date: Fri, 30 Jan 2015 22:07:43 -0500
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:
