RE: Splitting production and development/test at the DBA level?
- From: Nancy Iles <nancy_iles@xxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 13 Dec 2006 20:15:04 -0600
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@xxxxxxxxxxx:
mkline1@xxxxxxxxxxxxxxxxxx: Re: Splitting production and development/test at
the DBA level?CC: oracle-l@xxxxxxxxxxxxxxxxx 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@xxxxxxxxxxx> 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
-- Niall LitchfieldOracle DBAhttp://www.orawin.info
_________________________________________________________________
Check the weather nationwide with MSN Search: Try it now!
http://search.msn.com/results.aspx?q=weather&FORM=WLMTAG
Other related posts:
