RE: EM access to developers
- From: "Ruel, Chris" <Chris.Ruel@xxxxxxx>
- To: "dmarc-noreply@xxxxxxxxxxxxx" <dmarc-noreply@xxxxxxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Sat, 31 Jan 2015 16:37:20 +0000
Your arguments against Dev access to OEM sound more like a training issue than
anything else. FWIW, I have worked with DBA's in past lives that fit the same
criteria below whom I would not have wanted to have access to OEM either, let
alone developers.
At my current job, I work with some very astute developers. We cooperate in
ways that makes us both better caretakers of our Oracle environment. They can
read trace files, they can tune SQL, and they have a desire to write better
code and learn more about how to interact with an Oracle database specifically
(as opposed to just some black box data store). For every lackey developer I
have come across in the past who doesn't give two hoots about the code they
write and how it performs, I have run a across someone who calls themselves a
DBA who should be trusted with a SQL*Plus login.
It works the other way too for me. The better I understand the job of the
developer, how their code works, and what they are trying to accomplish, the
better I can set up the database, recommend features, and provide top shelf
service.
With all that said, I can empathize with your concerns...it wasn't long ago
that I was reluctant to share OEM with anyone but a DBA. Now, especially with
12c, and in the company of a quality development team with whom I work, I see
that this is a win-win. Yes, it takes some training, and some work. But, in
the long run, I think it will be mutually beneficial.
Chris..
_____________________________________________________________________
Chris Ruel * Oracle Database Administrator * Lincoln Financial Group
cruel@xxxxxxx * Desk:317.759.2172 * Cell 317.523.8482
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Mladen Gogala
Sent: Friday, January 30, 2015 10:08 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: EM access to developers
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
Notice of Confidentiality: **This E-mail and any of its attachments may contain
Lincoln National Corporation proprietary information, which is privileged,
confidential,
or subject to copyright belonging to the Lincoln National Corporation family of
companies. This E-mail is intended solely for the use of the individual or
entity to
which it is addressed. If you are not the intended recipient of this E-mail,
you are
hereby notified that any dissemination, distribution, copying, or action taken
in
relation to the contents of and attachments to this E-mail is strictly
prohibited
and may be unlawful. If you have received this E-mail in error, please notify
the
sender immediately and permanently delete the original and any copy of this
E-mail
and any printout. Thank You.**
Other related posts:
