I consider myself a Developer/DBA.
That said, you've probably either read about or experienced the typical riff between the developer and the DBA.
At my current employer, I am finally surrounded by true Production DBAs. Initially, I found it difficult to work with them. When I would ask "Why can't I do that?" I would rarely get a response.
Over time though, things have changed...for the better.
I believe it's called trust.
Trust that I am trying to do the right thing.
Trust that I want to learn.
Trust that I will listen to their suggestions.
Trust that I won't hack their DEV/QA instances using CREATE ANY PROCEDURE and EXECUTE ANY PROCEDURE.
Trust that I want to build a scalable and robust application.
So love your DBA. Give them time to get to know you. Give them time to learn your style, your methodology. Maybe someday they'll love you back and your job will get infinitely easier.
8 comments:
I think it depends quite a lot on the individual-ness of the DBA, plus how many times they've had their fingers burnt in the past.
I'm lucky to work with a great bunch of DBA's in my present company, whereas in my last job, we had a real jobs-worth of a DBA, who never failed to put people's backs up when it came time to request anything be done (although I quite liked them as a person, in a social setting!). Nothing we did made them any less suspicious of us, and believe me, we tried everything we could think of to get on with them!
I've always gone with the principle that you don't annoy the people who do things for you, be they cleaners, bin men, security - or DBA's! But when you've had to spend several hours proving to a DBA that "create directory" just will not work on an 8i database, patience goes out of the window! *{;-)
There a couple of technical solutions that I feel can aid in this trust.
First, use a source code control system. I'm a big fan of subversion, as are many teams within Oracle. If everyone checks-in code and you tag release candidates and test them as a unit, then move that unit of code from Dev to Test to Production, you're a lot less likely to introduce instability. It's also a sign of a "professional developer" vs a "cowboy coder", which should help to put your DBA's mind at ease.
Second, track DDL in development and prevent it in production. You can track it with an "after ddl on database" trigger and log it into a table. With 11g, you can also have all DDL logged into the alert log. You can also do schema diffs with either Enterprise Manager Change Management or via SQL Developer schema diff.
Third, the 11g SQL Performance Analyzer makes it a lot easier for DBAs or Developers to prove to each other that a suggested change will have the intended positive impact while not having any negative impacts. I blogged about it here: SQL Performance Analyzer Rocks!.
Tyler
Working in a couple large corporations, i have learned to hate my DBA (team).
They have absurd naming rules.
One company forced us to use twelve character TABLE names. The first must be "M", the last four had to be "_TBL". The second and third were strongly recommended to be the sub-project name. Only after much complaining did i get to break the length rule. But it still had to be M*_TBL.
Why was this the case? Because noone changed the rules sine hierarchical databases on the mainframe. "M" means "master", and "_TBL" represented the end of an 8.3 file name.
At my current company the rules are more absurd. Every TABLE name must start off with a letter (assigned per major department) three letters denoting the project, the a unique number assigned to the TABLE consisting of three digits, unless it is a history, lookup, or temp TABLE which get a letter and only two digits, then an underscore, then the name.
After that, each COLUMN has the same preface as the TABLE sans the first letter.
I despise my DBAs. They are morons.
Sorry, forgot one. Flashback. As a DBA, set your UNDO_RETENTION to something large, like 2 days instead of the default 15 minutes. You can use flashback query to diagnose and recover DML mistakes, flashback a table to before drop, flashback export a whole schema via data pump. All of these things are a lot easier than restoring a database from a backup.
Tyler
Tyler,
Big fan. Been reading your stuff via asktom for a few years now.
I would however take a bit of umbrage with point number 2. Preventing DDL in a production database is definetly a no-brainer, but the logging of all DDL in dev?
That, to me anyway, is the opposite of trust. I think dev should be the developers play area. I will concede however that I wouldn't want everyone having the ability to make structural changes, mainly the junior developers. At least not until they prove their worth.
Source control is a must. The timer near the top the page was the last time I broke production, I did that by promoting code (accidentally) from dev to prod. The DBAs at the time deployed from our ticketing system (yikes) and I attached a version of the code that didn't go through QA. I am happy to report that the next day they were doing so! ;)
Brian,
At WellCare the naming is done set forth by our architects. I keep lobbying the DBAs to do it, as they are the maintainers, but they are too busy putting out fires that we (not me...well once) create.
I have my own naming style, but I realize it isn't for everyone. It can be absurd. Our architect says one thing and does something different.
I'm too the point where I just don't care, just tell me what to do and I'll do it.
I am the DBA.Blame me...
Sue me .. Sue me.. Sound like your friend Don Burleson versus Johnathan Lewis ....
BTW : I got flashback and backup too.. so when nerd screw things I can fix it quickly.. last week right?
From one Oracle nerd to another... I hope you enjoy the rap video about Super DBA: http://www.youtube.com/watch?v=UZuZkhbNPjs
He uses SQL powers to save the day and make all the children happy:-)
Post a Comment