RE: Splitting production and development/test at the DBA level?

Tell me about it. All the DBAs have said they want to be on the side that does NOT get outsourced.  

What you mentioned is what we had in place when I was "Tech Operations Mgr" at the state. Nothing went into production until we had a set of instructions so complete a "semi-tech production control" person could apply. Full instructions, screen shots, expected results, all in place.  

Now we heard the WHOLE team will get migrated to some other division of EIS. Different cost center. If you want "core" to go down, just move some chunk to another cost center.  

I think they are "shooting from the hip". 70+ databases, maybe 80 now and 10 DBAs. Most aren't TOO bad. There has been an "on call" list, but does that mean the test/dev side will now be every other week if there are only two? Funny thing is, even with that many databases, they usually are NO calls for the whole week. Then I've had weeks when it was my turn that there were 3-5 calls, and naturally those were late at night.  

The company is going though an IBM thing where we have "pools" so that someone can be pulled from one pool to help another. This talked about division is saying that one side won't even have access to the other side. So even if prod got a call on a test/devl situation, they wouldn't be able to get in. WalMart syndrome, "That's not my department." It's almost like, "We're going in this direction, except for support?" Been around WAY too long to worry about it.  

I've been in the middle of a backup audit and getting RMAN to work when you can't get the NetBackup folks to load anything is a whole lot of fun. I've also been putting in standard monitor scripts and would eventually like to get up OEM since everything is heading 10G. It's getting better. Any more about 90% of my database work is now PREDICTIVE instead of reactive. I'm fixing things BEFORE they hit that threshold.  

I've got some clients with smaller databases, some having quite a few, and they've basically had no problems since 1998. they like that. But they are responsive on the support side. I'll tell them, "Look, we've got about 2 months to expand this disk, but we can't forget to do it." The next day, it's expanded.  

Michael Kline

Principal Consultant

Business to Business Solutions

13308 Thornridge Ct

Midlothian, VA 23112

O: 804.744.1545

Fax: 804.763.0114  

From: Dennis Williams [mailto:oracledba.williams_at_gmail.com] Sent: Thursday, December 14, 2006 9:17 AM To: mkline1_at_comcast.net
Cc: Oracle-L
Subject: Re: Splitting production and development/test at the DBA level?  

Michael,  

Gee, I want to be on your production team. My experience is that test/dev databases consume a lot more time that properly configured production databases.

    How will you handle off-hour support rotation? If the test/dev people are on the rotation, then I would advocate not such a rigid split of the team.

    Another idea while you are evaluating this change, implement formal policies for promoting production changes. The changes must first be applied to a dev instance which is a recent clone of production. This is the ITIL model. This would argue for the production people to also have control of the dev instances since it doesn't make sense for one person to do the dev update and then have a separate person perform the production update.  

Dennis Williams  

--
http://www.freelists.org/webpage/oracle-l