We have som probs with our netapp till some days. Our SQL DB Admin has enabled the indexing on some tabels witch was generating over 4 GB TLogs...
He has disabled this now.
But i beleve till then we have troubles during the VERIFY DATABASE AFTER BACKUP Phase of this DB Backup.
SQL Version: SQL 2008 R2 SP1 (Version 10.50.2500)
DB Size: 1.8 GB
Free Space C:\ : ca 10GB
Free Space D:\ : ca. 20 GB
SnapDrive Version: 6.3
SnapManager Version: 5.1
I have traced down that there must be a prob with the TLogs caus... if we do a manuel SQL Backup (Dump to file without Snapdrive) it works.
Direct after that we dose run the SnapDrive Job and it was sucsessfully
But... the Job from last night some houres later showes us the same error.
Logs if its working:
[22:44:20.263] *** VERIFY DATABASE AFTER BACKUP
[22:44:20.263] Collecting verification information...
[22:44:20.264] Getting database backup information from SnapInfo file...
[22:44:20.273] Running verification from local server....
[22:44:20.286] Mounting Snapshot [sqlsnap__vechbs-vs105_03-14-2012_22.43.54__daily] for LUN [D:\SQL\WIS\UserDB\] of Computer [vechbs-vs105]
[22:44:20.287] SnapManager will use directory [C:\Program Files\NetApp\SnapManager for SQL Server\SnapMgrMountPoint] to mount snapshot [sqlsnap__vechbs-vs105_03-14-2012_22.43.54__daily]
[22:44:20.288] Mount point directory [C:\Program Files\NetApp\SnapManager for SQL Server\SnapMgrMountPoint]
[22:44:20.289] Snapshot will be mounted on subdirectory [MPDisk006]
[22:44:35.198] This Snapshot is mounted as the drive [C:\Program Files\NetApp\SnapManager for SQL Server\SnapMgrMountPoint\MPDisk006].
[22:44:35.199] Mount Snapshot succeeded.
[22:44:35.201] Using existing connection to server [VECHBS-VS105\WIS]...
[22:44:35.211] Attaching database [ABS__Clone]...
[22:44:35.211] CREATE DATABASE [ABS__Clone] ON PRIMARY (NAME = 'ABS_Data', FILENAME = 'C:\Program Files\NetApp\SnapManager for SQL Server\SnapMgrMountPoint\MPDisk006\Program Files\Microsoft SQL Server\MSSQL10_50.WIS\MSSQL\DATA\ABS.MDF'), FILEGROUP [ftfg_WIS] (NAME = 'ftrow_WIS', FILENAME = 'C:\Program Files\NetApp\SnapManager for SQL Server\SnapMgrMountPoint\MPDisk006\Program Files\Microsoft SQL Server\MSSQL10_50.WIS\MSSQL\FTData\ftrow_WIS.ndf') LOG ON (NAME = 'ABS_Log', FILENAME = 'C:\Program Files\NetApp\SnapManager for SQL Server\SnapMgrMountPoint\MPDisk006\Program Files\Microsoft SQL Server\MSSQL10_50.WIS\MSSQL\DATA\ABS.LDF') FOR ATTACH
[22:44:35.718] Database attached.
[22:44:35.720] ALTER DATABASE ABS__Clone SET AUTO_SHRINK OFF
[22:44:35.734] DBCC CHECKDB (N'ABS__Clone') WITH NO_INFOMSGS, PHYSICAL_ONLY
[22:44:52.043] DBCC CHECKDB completed successfully.
Logs some houres later...
[04:05:48.930] *** VERIFY DATABASE AFTER BACKUP
[04:05:48.930] Collecting verification information...
[04:05:48.931] Getting database backup information from SnapInfo file...
[04:05:48.940] Running verification from local server....
[04:05:48.953] Mounting Snapshot [sqlsnap__vechbs-vs105_03-15-2012_04.05.23__daily] for LUN [D:\SQL\WIS\UserDB\] of Computer [vechbs-vs105]
[04:05:48.954] SnapManager will use directory [C:\Program Files\NetApp\SnapManager for SQL Server\SnapMgrMountPoint] to mount snapshot [sqlsnap__vechbs-vs105_03-15-2012_04.05.23__daily]
[04:05:48.954] Mount point directory [C:\Program Files\NetApp\SnapManager for SQL Server\SnapMgrMountPoint]
[04:05:48.956] Snapshot will be mounted on subdirectory [MPDisk006]
[04:05:49.299] [SnapDrive Error]: The target LUN in Snapshot copy is inconsistent or does not exist and cannot be connected.
(SnapDrive Error Code: 0xc00402ba)
[04:05:49.302] [SnapDrive Error]: The target LUN in Snapshot copy is inconsistent or does not exist and cannot be connected.
[04:05:49.303] Database verification information was not updated.
[04:05:49.304] There is an error during database verification.
[04:05:49.305] **** FULL DATABASE BACKUP RESULT SUMMARY #1 ****
[04:05:49.305] Backup Time: 03-15-2012_04.05.23
If anyone see a possible error source pleas tel me..
Otherwise i'm happy if anyone can explain me waht is happening in the VERIFY DATABASE AFTER BACKUP Phase...
I guess that we have some size problems on the C: cause the TLogs are to big to mount and do the DBCheck...
In that case i have to say that im not realy familiar with SnapDrive for SQL and SQL ^^
Thanks for your Time and Help
Okay i monitored the c and the d Drive over night. both had the same utilisation all the time. so ther is no problem with the space.
Wath i was reading that if the lun is published wrong over a quqetree this problems could happen... but with the other DB's on the same Luns i havent any probs....
is the post unclear ore are more information needet im glad to hear from you..
Just this morning we had the same error. There are no other errors, OS/NetApp/SQL, that happened at the same time. First time with this error since we started using snaps. Roughly 40days of hourly backups/verifies. We are verifying on a remote SQL Server.
For us this was with SnapDrive 6.4.1 and SMSQL 6.0.0. Windows 2003, SQL Server 2008 R2 on both servers.
"waht is happening in the VERIFY DATABASE AFTER BACKUP Phase... I guess that we have some size problems on the C: cause the TLogs are too big to mount and do the DBCheck"
As I understand it, what happens is that snapshot you just took gets mounted to (in your case) C:\Program Files\NetApp\SnapManager for SQL Server\SnapMgrMountPoint\MPDisk006. This does not consume any space except perhaps for some metadata, on your C: drive. The databases which you selected to be backed up / verified are attached, DBCC CHECDB ran against them, then unmounted. This is done one at a time until all the databases are checked, then the snapshot is unmounted.
If you look in SMSQL under Reports->Backup you will find the log which is very detailed. Reading these logs shed the most light on what SMSQL/SnapDrive is actually doing.
Hope that helps,
Make sure you don't have snapshot autodelete turn on for the FlexVol(s) for which the DBs exists. This is a default setting when making SAN FlexVols with System Manager and is intended to keep the LUN online instead of having the LUN go offline when the space fills up. Try to also look in the storage system logs (/etc/log/messages) around the time the backups are taken to see if the snapshot was autodeleted. If that is the case, then that is your resultant cause, but the actual cause is that you have undersized your FlexVol for the amount of change that occurs within the LUN. The only solution will be to increase the size of the FlexVol.