Could I have jammed more vendors into the title of this blog?  (I am told by the smart folks at ESG that I will get more readers if I use well-known proper nouns in the title of my blogs, so I am obliging).

Two lists this week.  The first is the reason for all the names:

• When you have a mix of well established vendors and start-ups solving a similar problem, you can assume that a viable market exists around that problem.
• The problem that I am referring to is the creation of several test and development copies of production database applications.
• Two reasons I am focusing on this.  First, I just left an end-user that is literally running a 5,000 + organization on five 500GB database applications.   The underlying databases are copied (full mirrors), on average, eight times for test and development / quality assurance purposes.  Second, 42%  of organizations surveyed by ESG said that major application and database upgrades are their most important 2010 IT initiatives.  Translated–more testing, developing, quality checking this year, which means more copies this year.

This leads to the  second bullet list on how the aforementioned vendors do this and why customers should care:

• The problem with “full” copies for test and development is the storage consumption.  The simple math for the company I met with this week:  (5 databases) x (500 GB) = 2.5TB.  Let’s say you run RAID 1, now you are at 5TB.  Now, copy this data 8 times and you are suddenly at 40TB for test and development.  You have to back this all up, maybe replicate it for disaster recovery, and, well, you see my point.
• Given that most developers are going to keep making copies (telling them to minimize the number of copies  is like telling the Tech Baby not to put everything in his mouth–it is an exercise in futility), the best way to address this is by creating “space efficient” copies–a.k.a subsets, write-able snapshots, and virtual databases.  These smaller databases can still be used for test and development and they consume far less storage.
• Let’s assume that one of the vendors mentioned or not mentioned (I didn’t include storage vendors like NetApp who do this within their systems) can help my customer reference reduce “full copies” by 80%.  The math is now 5TB for the primary environment and 8TB for test and development.  Less to back up, replicate, etc.
• The differences amongst the vendors are: how easy it is to create the space efficient copies and promote these into production if necessary (promoting DEV to PROD is a regular occurrence and should be simple), application / database integration (maintain integrity so the tests are executed in production-like environments), security (masking confidential / sensitive information), and management of all the copies (delete copies if they aren’t needed any more, audit who created the copies and who has access them).

We all talk about data growth as being a huge problem.  Organic data growth is rarely the issue in database applications (except for data warehouses–those seem to grow like weeds); all of the copies we make of these databases pose the biggest challenge.  It is about time we did something about it.

Read Brian’s other blog entries at IT BULLETins.

• Share