Re: Re[2]: EM access to developers

From: Courtney Llamas <courtney.llamas_at_oracle.com>
Date: Sat, 31 Jan 2015 08:55:20 -0600
Message-Id: <D41A0AD8-C83E-4BFF-9209-FDC89B3119A2_at_oracle.com>



Can I hit a like button somewhere? Or just maybe +1042

If your coming to rmoug, come see my session beyond the dba for more on the security aspect of this to understand why it is OK to give them access!

And I can't remember who said they got paged cause there were alerts they didn't care about and th developers saw them, if that's the case your metrics are set up incorrectly. You should only set metrics on actionable items...the rest can be seen from all metrics or a report when needed.... Developer access or not 😄

Courtney

Sent from my iPad

> On Jan 31, 2015, at 3:38 AM, William Robertson <william_at_williamrobertson.net> wrote:
>
> Absolutely agree. We (DB dev team) do not want to manage the database and we certainly should not have CREATE JOB privilege on production, but what we most certainly do need is a graphical performance dashboard giving an overview of instance status and allowing drill-down into execution plan history, SQL monitoring, day-on-day load comparisons and so on. Poking about in TOAD for misleading execution plans is so far from adequate it's not even funny.
>
> Shops vary of course, and perhaps in some there is a DBA responsible for everything database-related, staring across the hall at a database-agnostic C# dev horde who want as little to do with the persistence dump as humanly possible. However there are also sites where DB developers do PL/SQL, BI, Perl and job scheduling and we need to know why the batch is overrunning or the UI is not responding. This is partly for the level 3 production support rota and UAT, but also for continuous performance improvement feeding back into development. It would also assist the application support team in deciding how to route tickets. (Nobody gets paged at 2am any more - we have teams in 4 time zones.) The DBA teams are responsible for the stuff Iggy mentioned - configuration, availability, upgrades, installations, backups etc - for multiple systems, and aren't involved in application or batch details unless there is some deeper problem that needs investigation, where of course we value their expertise.
>
> One of the things people say about Oracle is it's complicated and hard while SQL Server for example has friendly desktop tools. As a career Oracle specialist I can't say how they compare, but I strongly suspect a clear, informative and above all brightly coloured web dashboard would go a long way towards reassuring switchers and decision makers that they've got something amazing for their money.
>
> William Robertson
>
>
> On 31 Jan 2015, at 04:24, Peter Sharman <pete.sharman_at_oracle.com> wrote:
>
> > This is not your father's Enterprise Manager.
>
> This is the key point. Nearly all of the discussion I’ve seen in this thread that mentions EM12c as a database management tool is just plain wrong – sorry to be as blunt as that, but then again I am an Aussie! ;)
>
> EM12c is much more than a database management tool. It’s an Oracle data center management tool. If you don’t believe me, go to the OTN page for EM (http://otn.oracle.com/oem) and look at the left hand side bar. Database management is just of many areas the product covers. Whether you use it to its full potential or not is up to you, but if you only use it for database management you are doing both yourself and your organization a great disservice.
>
> Let the flame wars continue! J
>
> Pete
> <image001.jpg>
> Pete Sharman
> Database Architect, DBaaS
> Enterprise Manager Product Suite
> 33 Benson Crescent CALWELL ACT 2905 AUSTRALIA
> Phone: +61262924095 | | Fax: +61262925183 | | Mobile: +61414443449
> "Controlling developers is like herding cats."
> Kevin Loney, Oracle DBA Handbook
>
> "Oh no, it's not, it's much harder than that!"
> Bruce Pihlamae, long term Oracle DBA
>
> From: kellyn.potvin_at_ymail.com [mailto:kellyn.potvin_at_ymail.com]
> Sent: Saturday, January 31, 2015 2:30 PM
> To: Mladen Gogala
> Cc: Oracle-L (E-mail)
> Subject: Re[2]: EM access to developers
>
> 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_at_freelists.org>:
> Responses in-line:
>
> On 01/30/2015 09:37 PM, kellyn.potvin_at_ymail.com 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
>
> --
> http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l
Received on Sat Jan 31 2015 - 15:55:20 CET

Original text of this message