topic SnapManager for SQL question in ONTAP Discussions

SnapManager for SQL question

yossi — Thu, 05 Jun 2025 07:28:28 GMT

Hi Team,

One of my customers planning to implement large SQL DB, between:2TB -10TB, he also planning to use NetApp SMSQL as the backup software for his DB.

One of his major concern is the verification process for large DB:

· Take long amount of time to finish for each Snapshot verification

· Will impact the NetApp & SQL server performance

In order to by pass this concerns, we thinking of:

· Not use the SnapManager Verification process on each Snapshot

· Use the flex clone technology

· Bring up the SQL DBs on line with scripts and SnapDrive\SnapManager Cli

· customer will check that the DB is online and check that all is ok from his application side ( DB under clone).

Can we promise that: bringing on line the DB from the Snapshots without running the SQL DBCC check is valid? on other words, by pass the Verification.

Thx

--Yossi

Re: SnapManager for SQL question

reinoud7 — Thu, 07 May 2009 21:05:58 GMT

That's a difficult question (or better, difficult to answer correctly).

Just bringing online the database is not a valid test. It says something, but you only know for sure after running DBCC.

An other way to look at this is: when you try this (the whole procedure: snapshot and the DBCC) 200 times, you will probably see that you never have a corrupt DB. With that hit rate, I would skip the DBCC and take more snapshots.

Is it not possible to snapmirror/snapvault the whole volume to an other less important filer (with sata drives) and use a flexclone copy on that system to run the DBCC? So that there's no impact on the production systems?

Reinoud

Re: SnapManager for SQL question

yossi — Thu, 07 May 2009 21:20:30 GMT

Hi Reynders,

Unfortunately, we have only one controller. no DR or Backup to disk quested by the customer.

Thx

--Yossi

Re: SnapManager for SQL question

amiller_1 — Sat, 09 May 2009 21:58:10 GMT

For that kind of setup, it will be difficult to guarantee data consistency given the other requirements. I'd agree that the best approach is just to take lots of snapshots (since most snapshots will be fine but given you can't guarantee that without a DBCC having lots of restore options will alleviate that somewhat).

Even without a second controller or a second aggregate, long-term you could use FlexClone (paid feature) with FlexShare (free feature) to clone the volume inside the same aggregate and then set the cloned volume to a lower priority (so that the DBCC running against the cloned volume won't slow down the production database volume).