Flex clone puts DEV server load on same data files as production?

[indianrock]

I'm trying to understand the flex clone concept.  It seems to be a very attractive, and quick, way to get copies of a production database onto development sql servers.  Our development servers can generate quite a bit of IO as QA runs "production-like" queries, so I'm concerned that if the DEV databases are actually hitting the same data as production, we could have a problem.

[GARDINEC_EBRD]

That is a possibility, yes.  But... You could say the same about running high I/O dev/test on the same filers as production, whether they are clones or not.  Some things to consider:

1. If you are running dev/test on the same aggregate as production, the disk load will be shared whether you have flexclones or not.

2. All data on the controller uses the same NVRAM/CPU/ETC.  So, FlexClone or not, you are sharing resources anyway.

3. If this is of concern, consider cloning from a snapmirror destination or a DataGuard copy (if using Oracle with DG) on a different filer.

4. Use FlashCache - the shared blocks used in the clone are more likely to be in the cache (as you have multiple clients accessing the same blocks), and will reduce disk load.

Ultimately, it can be a trade-off between the benefits/savings from FlexClone and the cost of dedicated disks/filers/etc.  We are using clones of Oracle DB's on some Prod filers, and it was also a concern at the design stage.  We took a shot at it and it's working OK 1 year on.  Any critical DB's with high IO (such as data warehouse applications) are cloned at DR from the mirrors.

Regards,

Craig

[indianrock]

Thanks Craig, that helps.  We're a sql server shop and currently the DEV sql boxes have their own local disks.  Since they are at our office where the DR/mirror filer will be, it sounds like cloning there would be best to eliminate traffic from our server facility to office.    I also posted about the impact of regular database index maintenance on snaps, but haven't received a reply on that one yet.  At our headquarters I'm told the DBAs schedule maintenance as needed and the storage team "just has to deal with" any impacts that may have on snap/backups.   In that office the DBAs apparently have nothing to do with snaps/backups/restores/DR.

The issue here is that our Systems guy ( part-time storage engineer ) doesn't know or want to know anything about database technology so I'm not sure how well he'll be able to handle Snap Manager for Sql Server ---  over the years, he and I have worked together, complementing eachother's skill sets.