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

We had the DBA split at my last employer. The biggest problems we had were lack of communication between the two groups, unrealistic expectations from management, and policies/procedures for each group not clearly defined and documented. The split itself was not the problem.

As was mentioned earlier though, I would definitely review the workload for each group to see if the proposed numbers for each team are appropriate. We had a fairly even split--3 production, 4 dev/test.

Sandy

On 12/13/06, Powell, Mark D <mark.powell_at_eds.com> wrote:
>
> Splitting of the DBA function is not that uncommon at larger concerns in
> the US. Some places have infrastructure DBA and Application DBA's. The
> infrastructure DBA's install the Oracle software, configure the db,
> configure the listener, and monitor the db space usage and overall
> performance. The application DBA creates the Oracle objects in the system
> (controlled) test environment and then applies the change scripts in
> production. Sometimes the Application DBA hands the (tested against system
> test) scripts off to the Infrastructure DBA or a different Application DBA
> to apply the changes to production. The application DBA's are not members
> of the DBA group and do not have the ability to start or stop Oracle.
>
> How well this works is mostly a matter of having and following documented
> change control procedures.
>
> -- Mark D Powell --
> Phone (313) 592-5148
>
>
> ------------------------------
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Michael Kline
> *Sent:* Tuesday, December 12, 2006 6:18 PM
> *To:* Oracle-L
> *Subject:* *****SPAM***** Splitting production and development/test at the
> DBA level?
>
>
>
> 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
>
>
>
>

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