| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Splitting production and development/test at the DBA level?
This may be off the topic but I am a lone DBA in an Oracle Apps shop. I am going to be assigned a new person to help part-time with the Oracle Apps DBA stuff and will probably have to train them from scratch. If you separate the production duties from development, how do you handle cloning from prod to dev since you have to know both the production apps and system passwords to clone? Just curious because I would love to hand off cloning to my help but really don't relish giving them the production passwords at first.
Regards,
Nancy Iles
Omni Hotels
Date: Wed, 13 Dec 2006 06:35:28 +0000From: niall.litchfield_at_gmail.comTo: mkline1_at_comcast.netSubject: Re: Splitting production and development/test at the DBA level?CC: oracle-l_at_freelists.orgThey were/are going to do that at the last place I worked. I'm in two minds about it. In it's favour dedicating DBA resource to development does improve the quality of both code and design. I like that a lot. I also like the idea that those responsible for development are also responsible for the release package being of sufficient quality and standard that someone who hasn't previously run it can do so successfully. I also am totally behind the idea that you don't let development into production (fighting that battle here, relatively easy with in-house staff, impossible maybe with 3rd parties). I don't like the idea of having a team of just 2 (my last place had 4 permanent DBAs and part of the 'reason' for the split was that both production and development needed 3 dbas but didn't recognise it yet). A split of 2/6 suggests to me that the perception is that a 3rd of the workload is in test and development put together and 2/3 in production. It would be interesting to see if that reflects reality, I'd almost expect it to be the other way around but a review of support tickets/work records would show that assumptions truth or otherwise. As far as not knowing what is coming, if the current culture is that development don't talk to production about a release schedule you've got bigger issues than who does what. On the whole I don't think it a bad idea provided that the team is big enough in both areas and that dbas still get to work on what suits them (might mean mixing and matching the teams from time to time) so that you maintain the interest and career development of the guys. On 12/12/06, Michael Kline <mkline1_at_comcast.net> wrote:
I've got a client that is considering splitting devl/test and production at the DBA level.
There are only about 8 Oracle folks, and that would put 6 on Production and 2 on test and there are about 70-80 databases.
This all has something to do with a Gartner paper that was some 7-8 years old.
Has anyone tried this before and what were the results?
Migrating new code forward just sounds like it will be horrible because now TWO DBA's will be involve and probably be almost totally unaware of what's coming and the like.
The strange thing is, this client is into "pools" big time where you get a DBA from the pool to work on what ever. That is pretty much how they were doing it now. Yet, being "in line" with this pools thing, they now want to make two pools and then make it so prod would have no access to devl/test and devl/test will have no access to prod. It reminds me of like WalMart type stores. "Sorry, that's not my department." It's got the DBA department quite concerned.
The paper was supposed to say this was the thing to do, and perhaps would make SOX happy.
Michael Kline
13308 Thornridge Ct
Midlothian, VA 23112
O: 804.744.1545
Fax: 804.763.0114
 |
 |