SQL Clone Change Footprint

[MIKECUTTS]

Hi All,

Apologies if this is in the wrong forum, but I couldn't see one that was more applicable for this question.

I'm relatively new to NetApp as a product (though I have used it occasionally in the past), and am looking to implement database cloning.

I have a test environment with the volumes and LUNs set up in the way I want (ie. One Vol + One LUN for one of our mission critical database's data files, and one vol + one LUN for its log file). I want to be able to clone this database, possibly multiple times running on multiple different instances (all of which share the same NetApp hardware). Again I think I've got to this point successfully.

The question I have is that, if the database is 500GB and I take 2 clones of the database running on different instances, and there are subsequently 1GB amount of data change on each of the 3 instances, where is that space taken from? Is it from the snapshot reserve of the source of the clone, is it from the destination volumes? I don't seem to be able to find where that space is being allocated, though I have been working with far smaller data changes in the test environment I have implemented.

I just don't want to get into a situation where I'm putting the production server at risk by having clones which have significant data change each day.

Any thoughts would be gratefully received.

Thanks,

Mike.

[MIKECUTTS]

Anyone any thoughts on this please?

Cheers,

Mike.

[radek_kubka]

Hi Mike,

Good questions. Are you talking about volume-level FlexClone? If that's the case, this article gives the answer to your question:

https://communities.netapp.com/docs/DOC-10323

"The disk space associated with the Snapshot copy and the FlexClone volume is accounted for separately from the data in the parent FlexVol volume."

That holds true for any writes to the FlexClone copy itself. However, if you make any changes (or data additions) to the parent volume, then extra space for snapshots (you will have at least one as the base for FlexClone) will be taken from the parent volume - starting with snap reserve, potentially overflowing to the live file system if snap reserve gets full.

Regards,

Radek

[MIKECUTTS]

Hi Radek,

Thanks so much for your help.

Regarding volume-level FlexClone, I'm not sure what you mean. However, what I can say is that all our volumes are FlexVol volumes, and the method I'm using to clone it is within SnapManager for SQL Server, using the Clone Wizard. Is that what you wanted to know?

With what you said, if I'm understanding correctly, any changes on the source database would result in the snapshot reserve space being taken up on the volume where the source database resides.

If I were to make a significant number of changes to the clone copy, would this also take up space on the snap reserve of the volume housing the source database? The reason I ask is because I'm cloning databases from one instance on one server to an instance on a separate server, though they are sharing the same NetApp device.

Thanks again for your help,

Mike.

[radek_kubka]

If you have FlexClone licence on the system, then SMSQL will automatically use it, clone a volume and all the caveats discussed so far will be applicable.

However, without FlexClone license LUN cloning will be used and all changes, both for original database and/or clones will affect free space in the original volume.

[MIKECUTTS]

Hi Radek,

Thanks again. So just to clarify, if we were licensed for FlexClone, the changes made to a cloned database (assuming one database is stored on one volume) would be accounted for in a separate space to the volume storing the source of the clone?

Conversely, if we weren't licensed for FlexClone, the changes made to either the source or cloned database would all be accounted for in the volume where the source database resides.

Thanks once more,

Mike.

[radek_kubka · Accepted solution]

Hi Mike,

According to my best knowledge this is correct.

Regards,

Radek

[MIKECUTTS]

Hi Radek,

Thank you so much for the info. Much appreciated.

Mike.