Wie mir neulich bei einem Kunden aufgefallen ist, kann es vorkommen, dass bei einem Restore/Verify aus dem SnapManager Sharepoint Version 6.1.0.0 die SQL Datenbanken am SQL Server „hängen“ bleiben.
Damit bleiben auch die LUNs und Volumes des Snapshots in der Netapp hängen.
Trotz 100% sauberer Installation war es mir unerklärlich, weshalb bei einem Restore aus dem SnapManager Sharepoint die SQL Datenbanken und die LUNs weiter am Server angehängt waren.
Nach einigen Tests direkt mit dem SnapManager SQL fand ich heraus, dass das Problem irgendwo beim SnapManager für Sharepoint liegen muss. Denn der SnapManager SQL war in der Lage Datenbanken aus einem SnapShot anzuhängen und auch wieder abzuhängen.
Ein Ticket bei NetApp brachte die „Erlösung“
In den Microsoft „Best Practise Guides for Sharepoint“ ist es empfohlen den einzelnen Web-Frontend & Application Servern vom Sharepoint einen ODBC Alias für die SQL Server/Cluster zu vergeben.
Dies führt dazu, dass der SnapManager SQL zwar in der Lage ist einen konsistenten SnapShot der Datenbank zu machen, bei einem Restore durch den SnapManager für Sharepoint aber der auf dem Sharepoint angegebene Aliasname des SQL Servers für einen Restore Versuch verwendet wird.
Daher wird zwar ein Restore ausgeführt, aber ein Abhängen der Datenbank durch den SnapManager Sharepoint ist nicht mehr möglich, da dieser dem SQL Server angibt er solle : [SERVERNAME] [ALIASNAME] [SHAREPOINTDATENBANK] abhängen.
Der SQL Server versteht nun, dass er auf Server [SERVERNAME], in der Instanz [ALIASNAME], die Datenbank [SHAREPOINTDATENBANK] abhängen soll.
Der SQL Server kennt aber keine Instanz [ALIASNAME] und bricht ab. Somit bleibt die Snapshot-LUN gemountet und auch das Volume besteht weiter in der NetApp.
Einen Offiziellen Patch für diese Problem gibt es noch nicht, so dass wir alle auf die neue Version vom SnapManager warten könnt oder Ihr bezieht Euch auf die Case Nummer: 2003466776
Netapp hat da in Windeseile einen Bugfix geschriben, welcher sicherlich auf in den SnapManager Sharepoint 7 einfließen wird.
Typische Fehlermeldung im LOG:
delete-clone -Server „SQLSERVERNAME“ -ServerInstance „ALIASNAME“ -Database ‚SMSP_R_SP2010_SHAREPOINTDB_sqlsnap__SERVERNAME_09-20-2012_06.00.53‚ -apicontext:$True -verbose:$True
ErrorMessage:
Pipeline State Changed to Failed:
Failed to invoke the backup operation.PSObjectOutput:
[14:04:19.7920943]: Initializing [delete-clone][System.String]
[14:04:19.8544944]: Connecting to server: [des04984] [processing][System.String]
[14:05:20.7882014]:
Failed to connect to the specified SQL Server.Details: Error Code: 0xC0040804 Further details may be found in the SnapManager report or event logs.[System.String]
[14:05:20.7882014]: Retrying to connect to SQL Server for validation [ALIASNAME][System.String]
[14:06:22.5019098]:
Failed to connect to the specified SQL Server.Details: Error Code: 0xC0040804 Further details may be found in the SnapManager report or event logs.[System.String]
[14:06:22.5019098]: Failed to connect to Server: [SERVERNAME][System.String]
[14:06:22.5799100]: System.Management.Automation.PipelineStoppedException: The pipeline has been stopped.
at System.Management.Automation.MshCommandRuntime.ThrowTerminatingError(ErrorRecord errorRecord)
at System.Management.Automation.Cmdlet.ThrowTerminatingError(ErrorRecord errorRecord)
at SMSQLPSSnapIn.SMSQLPSDeleteClone.ProcessRecord()[System.Management.Automation.PipelineStoppedException]
[14:06:22.5799100]: An Error occured while deleting the Database clone.Please check the SnapManager Reports/Windows EventLogs for more information.
Details:The pipeline has been stopped.[System.String]
[14:06:22.5799100]: Failed.
Wenn Ihr Fragen dazu habt, schreibt mich ruhig an. Ich weiß, dass das Thema etwas komplex ist und ich kann nicht garantieren jedem helfen zu können.