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

[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 · Accepted solution]

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

[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

[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