Re: DBA's as idiots

  • From: "Andrew Kerber" <andrew.kerber@xxxxxxxxx>
  • To: niall.litchfield@xxxxxxxxx
  • Date: Mon, 2 Jun 2008 15:49:42 -0500

I have been on both sides of that conversation.  And I have been where this
DBA may well have been, that is coming up on an implementation date, getting
ready to go live with real data, and no one especially the vendor has
bothered to document the reason for all those privileges (like DBA on
occasion) granted to the application user.  And when everyone is too busy to
document why privileges have been granted, I have often been tempted to do
what this DBA appears to have done, that is revoke all privileges until
someone can explain why they have been granted.  Wanting to keep my job, I
have never actually done this, but I have often been tempted....  Though in
these days of Sarbanes-Oxley, I could definitely see it happening more
often.  I would rather explain why privileges were revoked today, than
explain to an accountant 6 months down the road why the privileges were
granted in the first place.

On Mon, Jun 2, 2008 at 2:59 PM, Niall Litchfield <niall.litchfield@xxxxxxxxx>
wrote:

> I agree entirely. The whole tone spoke volumes about people unable to
> relate professionally to one another.
>
> I also have some sympathy for the dba who revoked the permissions, since
> the defence is not "the permissions granted are those necessary to make the
> app work as outlined in this document here" but rather outrage that the dba
> responsible for protecting the data had revoked unexplained privs not
> granted by him. Of course providing a detailed commented install script was
> probably done by said dev, just not mentioned. It couldn't possibly be that
> the install script went
>
> GRANT DBA TO APP_USER;
> CONNECT APP_USER..
> CREATE TABLE BLAH(SSN VARCHAR(4000),CREATE_DATE VARCHAR2(255)...);
>
>
> obviously..
>
> Niall
>
>
> On Thu, May 29, 2008 at 7:52 PM, Allen, Brandon <Brandon.Allen@xxxxxxxxxxx>
> wrote:
>
>>  Good stories, but I'd suggest a better approach for the developer in the
>> second story in which the DBA is obviously not worthy of the title.  The
>> developer should've created a test case complete with trace files to show
>> that the query performed better with the index on last name, and then done a
>> live demo for the manager making it indisputable.  If the manager doesn't
>> respond to such empirical evidence but still blindly sides with the DBA, the
>> developer should find a better employer ASAP.  Sneaking behind the manager
>> and DBA's backs isn't the right way to go about it.
>>
>> Regards,
>> Brandon
>>
>>
>>  ------------------------------
>> *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
>> oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Jared Still
>>
>>
>> http://computerworld.com/action/sharktank.do?command=viewDailyFull&date=20080507
>>
>> Privileged/Confidential Information may be contained in this message or
>> attachments hereto. Please advise immediately if you or your employer do not
>> consent to Internet email for messages of this kind. Opinions, conclusions
>> and other information in this message that do not relate to the official
>> business of this company shall be understood as neither given nor endorsed
>> by it.
>>
>
>
>
> --
> Niall Litchfield
> Oracle DBA
> http://www.orawin.info




-- 
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

Other related posts: