Data Backup and Recovery

SMSP backup errors during backup indexing

dgreg

Hi there,

I’m having an issue with the SMSP backup job I’ve configured for a customer. The SharePoint components are backing up okay, but it appears that indexing of the backed up data is failing. There is an SQL server error when the cloned database is presented to the SQL server as follows:

"[Microsoft][ODBC SQL Server Driver][SQL Server]Logical file 'WSS_Content_c553abc3-1f78-471e-a32e-d2082bdf8b49' is not part of database 'SMSP_B_WSS_Content_c553abc3-1f78-471e-a32e-d2082bdf8b49_sqlsnap__mssqlr2_05-24-2012_14.38.05'. Use RESTORE FILELISTONLY to list the logical file names.

Msg 3013, SevLevel 16, State 1, SQLState 42000"

I’ve attached the SMSQL clone backup log file which I think is most relevant, and the SMSP backup log file.

The customers SharePoint environment is as follows:

  • Microsoft Office SharePoint server 2010 Enterprise Edition SP1
  • 2 x WFE servers – control / member agent
  • 1 x SP Index server – member agent
  • 1 x SP Application server  - member agent
  • SQL server 2008 running on a Windows 2008 Failover cluster – member agents

NetApp software

  • SMSP 6.1 x64
  • Data ONTAP 8.0.2P3
  • SnapDrive 6.4 x64
  • SMSQL 5.2 x64
  • Host Utilities 6.0

Any advice on how to remediate this issue would be most appreciated.

Cheers.

Greg Davis

Consultant

Professional Services, ASEAN

1 ACCEPTED SOLUTION

bojan

Hi Greg,

This is a known issue. Please check this Burt:
http://burtweb-prd.eng.netapp.com/burt/burt-bin/start?btn=view&burt-id=585632

There is a workaround available:

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 SMSQL Service.

Cheers
Bojan

View solution in original post

6 REPLIES 6

dgreg

Hi,

The SMSP backup job indexing is now working. I do not know what changed, however this is now resolved.

Thanks.

Greg Davis

NetApp PSC,ASEAN

bojan

Hi Greg,

This is a known issue. Please check this Burt:
http://burtweb-prd.eng.netapp.com/burt/burt-bin/start?btn=view&burt-id=585632

There is a workaround available:

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 SMSQL Service.

Cheers
Bojan

View solution in original post

mdvillanueva

Hi Bojan,

I think I am experiencing the same issue. Do you know what dgreg means that backup database metadata will be overwritten?

Thanks,

Maico

dgreg

Hi Bojan,

Thanks for your reply. Yes that is the issue I'm facing and it is with SMSP. It is worrying because I read in the BURT that backup database metadata will be overwritten where databases have the same first four characters in their database name, as is the case with the customer's Sharepoint databases evidently.  I will get the customer to execute the workaround as soon as possible.

Thanks.

Greg Davis

NetApp PSC, ASEAN

mdvillanueva

Hi Dgreg,

Were your customer able to apply the workaround? what happened?

Thanks,

Maico

dgreg

Hi Maico,

Thanks for your message. I did manage to fix this issue for the customer but I don't remember the exact process we followed. I think it is likely I executed the workaround discussed in the following BUG: http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=585632

Basically, if you have two databases on a LUN which have the first few characters the same, SMSQL can incorrectly query the wrong database during a clone or restore operation.

I hope that helps.

Greg Davis

NetApp PSC, ASEAN

Announcements
NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner
Public