Re: Are Oracle DBAs trivialized?

domenicg_at_hotmail.com (Domenic) writes:

> I'd like everyone's thoughts on this ...
>
> More and more I am finding that the role of the Oracle DBA is not
> taken as seriously as it once was.
>
> Having worked for many software companies in the last few years I see
> the same pattern over and over -- most shops refuse to stay current
> with Oracle and patchsets -- they're still running 8i, don't want to
> use Oracle-specific features (clusters, IOTs, etc.) for fear it will
> lock them into Oracle, and let the developers model and write their
> own DDL.
>
> Most of the time I feel they only want a DBA to put out fires.
>
> Here are some recent examples ...
>
> - I had to pull teeth to get my current company to switch to RMAN.
>
> - I got laughed at for naming NOT NULL constraints in my CREATE TABLE
> scripts

hehe - you see their thinking hasnt gone that far - they still don't know which columns should and should not allow null (if any) because no real analysis or design has occured.
>
> - I had a one of my designs tossed out because it had triggers,
> clusters, and deferrable FK constraints in it.
>

I suspect they wee tossed out because they didn't understand even what a FK was.

> - I have been telling management for almost a year to get off 8i --
> falls on deaf ears of course

Still trying to get rid of an 8i db ourselves.

>
> - I get apps tossed at me with hundreds of poorly written queries
> (correlated subqueries everywhere, NOT EXISTS, etc.) that I have to
> rewrite for speed.
>

We have actually started giving a can of 'spam' to the developer which either does the largest cartesian join or the simplest select statement with the record for consistent 'gets'.

> - I get crap from the UNIX SAs at just the thought using 10g ASM when
> we finally upgrade, by that time Oracle 13 will be out.

Lucky here - DBAs and Sys Admins get on well and both want to see us get to 10g sooner rather than later.
>
> - I have developers who commit every SQL statement and throw highly
> denormalized tables at me, but management still feels they should NOT
> have to come to me to get a table designed.

We get that and the opposite - huge numbers of unrelated inserts without any commits which keep blowing out rollback segments no matter how large they are! Really seems to be know mental comprehension of what a commit is and when and when not to use it.

>
> - HA requirements but they refuse to use RAC or Data Guard.

Same and it took nearly 12 months to convince the business and developers of the merits of hot backups instead of nightly cold backups!

>
> This is not just my current company, but they all seem to be the same
> lately. It seems that the Java shops operate this way more than
> anyone else -- very hostile attitude towards Oracle and DBAs in
> general.

Not sure if its 'hostile' or just plain old ignorance and a failure to recognize the relevance of knowledge which is outside your own specialist area (like java programming).

>
> Is it just me, or does this go on everywhere?
>

I'm no longer doing development or DBA work (I was only ever an Oracle DBA 'in training' anyway). I made the fatal mistake of moving into management and now have to manage the DBAs, Unix and Windows and network sys admins.

We are very lucky in that we have a very experienced, capable and professional senior DBA and a very capable and promising 'junior' DBA (he isn't really junior, just not senior - if you get the difference). We also have some very capable sys admins. Luckily, the sys admins and DBAs have a very good and strong working relationship. However, the DBAs do cop a lot of flak from some of the developers and from some of the other managers. One of the managers from the business side of things actually made the statement a few weeks ago that DBAs were really just glorified helpdesk staff - you see, he is an expert because he has a MSCE!

There is a constant battle with the developers because they feel the DBAs (and sys admins) are simply there to make their life difficult - they get upset when we reject work they have done because it is inefficient, has security holes or is just a bad design.

Unfortunately, the style of management around these days is all about short-term benefits and getting projects 'over the line'. Very little is put into good solid long term solutions. I believe its because most managers I've come across had no other real skill other than 'managing' and really only wanted to climb the career ladder. For them, any solution which lasts more than 5 years is a waste as they will be long gone onto that next promotion - they want quick short term success at a low cost so that it looks like they have done their job better and can get that promotion and fatter pay packet sooner. therefore, they pay cheap inexperienced developers to get the job done quick and dirty and don't want irritating DBAs getting in the way.

I see all of the things you listed on nearly a daily basis. When I first started in this industry, the DBA was a person you went to for advice and guidence - but back then, nearly all the developers new at least the first 3 normal forms, they new who Cobb was and beleived they were building systems which would last and require minimal maintenance.

The last laugh is with me though! I've been given the job of selecting the new development platform for the developers. Currently, they only use Oracle forms and reports. the problem is that we have changed direction and no longer do really full blown development, but rather integration of systems and setting up reporting frameworks etc. The type of work now requires rapid turn-around and the Oracle tools just don't cut it for this type of work. I've been given the job because the developers couldn't agree on a direction.

All the developers are really worried as they know my favorite language of all is Common Lisp. I've led them to believe this is what I'm going to be putting into place - of course, there is no way I could ever sell this to the business (unfortunately), but its fun watching the panic and fear in their eyes!

In reality, I'll probably go with Java and a scripting language like Perl (or python!).

Tim

-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!