techblog 

It is quite commonplace for developers to want to prototype their applications against a full copy of live. One popular method for doing this is using snapshot technology. A good example of this is from Alex Gorbachev. One advantage of snapshots is the potential for using far less storage space than what a full copy would require. However, I am less in favour of this as I fear the additional I/O that may be generated on your production storage array and I like to keep prod and development instances well physically seperated. We have a seperate EMC storage array for our developers with around 10TB available to play with. This means we can easily full copies of live, as our production database is around 130GB in size.

The one serious disadvantage we find with refreshing developers test databases is the time to perform a full restore of production from backups. While this is a good test of our ability to recover from our backup tapes, the developers can get frustrated at the amount of time required for a refresh. Currently it takes around 3 hours to perform a full restore and I did not consider this to be an acceptable turn around time.

Looking around for something to accelerate our database refresh time I came across EMC Snapview we are using this to take full clones of luns so that we can recover a copy of production from backup once and then clone multiple times, in effect giving the developers a copy of a copy of live. I then had the idea why not use a physical standby for the master lun and clone the developers copies from this.

The big advantage with doing a clone from a physical standby is that snapview works out what blocks have changed so as there is a relatively small number of blocks being changed in comparison to the total number of blocks the database uses a refresh from the physical standby is far, far quicker than a full clone from backup tape.