Are you protecting your development databases?

Most of the DBA teams I have been on usually treat a Development environment different than a Production one. That is a practice, I still don’t understand. For me, Development environment is a very important part of the production support infrastructure and you must keep that environment running and available for your users (Developers). So how much will you be expending when a group of developers are unable to access a development environment? What will be the cost associated of the delay to the project time lines?

No long ago when I was setting a new database for a development environment I made some decisions that are not usually taken on a regular basis in development environments. I configured the DB to be in ARCHIVE MODE (Like production), I enabled FLASH and I also enable DB TRAIL. There are several reasons why, but those decisions I made have already been use to aid and/or help our developers and/or implementations projects.

Usually the developers are super users in their respective development environments, and they will have rights that normal users will not have, they will be able to create objects, drop them, and also considering the human aspect, they will make mistakes.

What happens if one them drop a table or a package, delete rows from a table by mistake or on purpose?

As DBA you should do an evaluation in how you need to setup and protect a development environment, and consider them as part of your recovery strategy. Remember your developers are also Users and they are very special ones with a lot of power, and as DBA is up to us to protect our databases independent of what have been done to them and what have happened.

Jose Galan

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics