Friday, March 31, 2006

Non Production databases

How do you deal with non-production databases at your current place of work? Currently we have a mix of Commercial-Off-The-Shelves (COTS) and in-house applications and we are going the route of COTS instead of custom build. For example, our HR/payroll is PeopleSoft and those guys have 5 or 6 different environments beside Production and we are being asked to provide more environments for future projects. The approach taken by Application Services is to have multiple copies of development/test for each individual projects so that there is no fear of disruption from other projects. Just think of the number of databases that have to be cloned and supported per application per project!

So, how do you deal with it? I'm planning to just restrict and limit the number of databases by telling Application Services that they will just have to be nice and share but for some COTS like PeopleSoft and Oracle E-Biz Suite, we might just have to set up instances like INT_TEST (mirror of Production) so that we can debug problems encountered in Production, DEV for developing or adding new functionalities, TEST to allow for full testing of modifications, PATCH to test out patches before applying them to the necessary environments, and DEMO, a vanilla environment but populated with standard corporation information like the sample VISIO data that comes with Oracle E-Biz Suite that can be used to verify bugs, issues, etc.


Bill S. said...

We currently have separate boxes for PROD and DEV and are in the process of setting up a new box which is called our "litter-box". Plainly put, we can put whatever crap we want in it, and play with things such as version upgrades, patches, theoretical problem-solving issues, etc., without having to impact current developement initiatives or production. I feel it is SO important to have a development box AND a test box. Gives the developers a stable production-like environment, and gives the DBAs a place to try things without fear.

Oh, and that is one db per box. We don't believe in sticking more than one db on a box (seems like tempting fate ;-D).


Herod T said...

We too are heading down the path.. well are most of the way down the path to "COTS", we are only developing small internal applications that we can't find a COTS for.

I like that acronym :)

We are a "mainframe" type shop, everybody grew up around mainframes and keep that style in mind.

We have a large cluster of HPUX boxes connect to a SAN and a bunch of linux and "the" windows server.

We have test boxes/databases and then we have "OUR" boxes. Servers that are only for the IT department for testing and breaking.

Lots of breaking going on. Most of it planned.

We unfortunately share a lot of test databases on the same server as the production database.

We don't like that, but it is what we are forced to deal with.