Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Community!
I recently finished my 3rd Installation of SMSP 6.1 with SMSQL 5.2 and Snapdrive 6.4.
At all 3 Installations i sporadic get the following Error for the Content Database in the SharePoint 2010 Environments:
Errors: Clone Backup DB Error :WSS_Content_01
Clone Backup DB Error :WSS_Content_02
Clone Backup DB Error :WSS_Content_03
The Problem is that SMSP 6.1 cannot create the Single-Item Index of these Content Databases.
After testing around with SMSQL and SMSP and no success i decided to Downgrade the SMSQL 5.2 to SMSQL 5.1P2 and now the Backups working again.
I think there is a Bug with SMSP 6.1 in combination with SMSQL 5.2 because all other SQL Backup were working perfectly.
Maybe someone of Netapp can confirm my suggestion 😃
br
Christian Lapacka | HATAHET productivity solutions GmbH
:
8 REPLIES 8
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Christian
I have been working through the same issue for the last few months, finally I have been able to perform an item version backup, the resolution was to downgrade SMSQL from 5.2 to 5.1P2, make sure you uninstall 5.2 first and remove the snapinfo folders, then rerun the SMSQL configuration wizard.
Let me know how you get on.
Andrew
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Although I have had a few backups fail with that same error using SMSQL 5.1P2 today
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May you have old clones mounted in SQL!
First check this with the Clone Wizard of SMSQL if there are no clones for "Delete Cloned Databases" you can delete it in the SQL Management Studio and then run the Backup again
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I actually check this prior to running the backup, since my last post I ran a backup and that was fine. However SMSP seems to leave cloned DB's attached to the verification server, surely this is not normal behaviour?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since SMSQL 5.1P2 i don´t have this problem! Which Snapdrive Version do you have?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm running the same configuration as you now. SMSP 6.1, Snapdrive 6.4 and SMSQL 5.1P2. My only problems now are orphaned clone DB's and the error below:
Configuration Value
Plan Name Full Backup
Plan ID PLAN20120208160858
Backup Level Item Version Level
Backup Type Full Backup
Job ID FB20120217190000
Agent Host S-HO-SP
Media Service S-HO-SP
Email Notification Snap Manager for Sharepoint
Agent Version 6.1.0.0
Manager Version 6.1.0.0
Username bloor_homes\smsp
Start Time 2012-02-17 19:00:00
End Time 2012-02-17 19:07:02
Statistical Result 1657 MB data, 1(0) site collections, 25(0) sites, 282(0) lists, 813(0) items. Error:runcommand error
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I had the same problem using SMSQL 5.2, SD 6.4 and SMSP 6.1
Reverted to SMSQL 5.1P2 and backups are now completing successfully
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello customers/partners,
I can tell you now that this is a recently discovered bug, 585632.
Engineering are currently working on this. I can provide you here with the public report, which is not yet showing up on our site (it should soon).
%%% TITLE:
Restore and clone may fail with error Logical file db_data is not part of database db, Use RESTORE FILELISTONLY to list the logical file names.
%%% DESCRIPTION:
When doing a database restore or cloning, the operation may fail with the
following error messages in SMSQL report:
Failed to prepare VDI mount snapshot.
Error encountered when executing sql command:
Msg 3234, SevLevel 16, State 2, SQLState 42000
[Microsoft][ODBC SQL Server Driver][SQL Server]Logical file 'db_Data' is not
part of database 'db'. Use RESTORE FILELISTONLY to list the logical file names.
Msg 3013, SevLevel 16, State 1, SQLState 42000
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE DATABASE is terminating
abnormally.
Error Code: 0xc00408a0
Unable to get VDI command to perform snapshot creation or LUN restore.
The SQL command executed.
Failed to restore SQL Server database [db] of [inst].
The problem will happen under the following conditions:
1. Multiple databases are sharing same LUN or two LUNs;
2. Among databases sharing LUN(s), there are more than one databases whose
name's first 4 characters are the same, and those databases are belonging
to the same SQL Server instance, or different instances but the first 4
characters of those instances' names are the same.
With such configuration, when those databases are backed up at the same
time, one or more of backup metadata file may be overwritten during
the backup, so the restore or clone will fail.
%%% WORKAROUND:
To prevent this problem from happening again with newly created backup,
use the following workaround:
1. Add the following registry key DWORD (32bit) value named
"SupportLongDbName" under:
HKEY_LOCAL_MACHINE\SOFTWARE\Network Appliance\SnapManager for SQL Server\Server
Set its value to 0.
2. Restart SnapMgrService.
In case a restore is needed for the existing backup, you can manually
mount snapshot which contains the database, copy the database files
from the snapshot LUN manually, then attach the database using the
copied files.
%%% NOTES:
The workaround provided for preventing the issue from happening with
newly created backup does not apply to database with a long name, such
as more than 86 characters. For database with very long name, relocate
such database to separate LUN, so it does not share the same LUN with
other databases.
Daniel Breslauer
NetApp Technical Support Engineer