Umzug aller Datenbanken auf neuen SQL Server

Henning Eiben Als Antwort am 14 Sept. 2010 09:50

Ich habe bisher nur einmal eine SharePoint-Datenbank von einem Server auf einen anderen migriert. Habe dazu den Technet Artikel Move all databases verwendet.

Am Ende wird dort irgendwo ein SQL-Alias eingerichtet - ohne das habe ich auch ein paar Probleme mit den Timer-Jobs im SharePoint gehabt. Mit einem solchen Alias sollte allerdings die Migration zu bewältigen sein.

Sebastian Als Antwort am 14 Sept. 2010 10:07

Weitestgehend stimmt der Technet Artikel mit meinem Script überein. Den Alias kann ich jedoch nicht setzten, da auf dem alten SQL Server Datenbanken andere Systeme verbleiben.

Henning Eiben Als Antwort am 14 Sept. 2010 10:32

Das Alias setzt du ja nur auf dem SharePoint-Server - gilt also auch nur für diesen Server. Musst du denn von dem SharePoint-Server diese anderen Datenbanken ansprechen? Wenn nein, dann sollte das kein Problem darstellen.

Sebastian Als Antwort am 14 Sept. 2010 10:36

Achso dann habe ich das falsch verstanden. Nein das Ziel ist es ja gerade, den Sharepoint und alles was damit zu sammenhängt separat zu halten. Hast du einen Hinweis wie ich diesen Alias setzen kann?

Henning Eiben Als Antwort am 14 Sept. 2010 10:41

Dann solltest du das mit dem SQL-Alias machen können :)

Sebastian Als Antwort am 14 Sept. 2010 10:57

Ist das richtig so? Alias = alter SQL Server; Servername = neuer SQL Server

http://www.sharepointassist.com/2010/02/02/configure-a-sql-server-alias-for-sharepoint-sql-server-2008/

Sebastian Als Antwort am 14 Sept. 2010 15:10

Der Alias funktioniert problemlos und schon gibts neue Probleme

Und zwar tauchen jede Stunde nun folgende EventIDs auf:

7888

Es wurde eine Laufzeitausnahme erkannt. Details folgen.
Meldung: Es wurde eine doppelte Website-ID (4b779c30-9af7-4b6a-b8e3-dc5400ceb87b(http://Intranet)) gefunden. Dies wird möglicherweise verursacht, wenn eine Inhaltsdatenbank aus einer Serverfarm in einer anderen Serverfarm wiederhergestellt wird, ohne zuvor die ursprüngliche Datenbank zu entfernen, und wenn anschließend der Befehl 'stsadm -o preparetomove' ausgeführt wird. Falls dies die Ursache ist, kann dieses Problem behoben werden, indem der Befehl 'stsadm -o preparetomove' mit der Befehlszeilenoption '-OldContentDB' verwendet wird.

5555

Fehler beim Synchronisieren der Webanwendung bee45e31-a72e-4bda-9dba-6382e85ee93c, Inhaltsdatenbank 89a5f769-7e47-4556-947f-939df4471a6a. Ausnahmemeldung war Es wurde eine doppelte Website-ID (4b779c30-9af7-4b6a-b8e3-dc5400ceb87b(http://Intranet)) gefunden. Dies wird möglicherweise verursacht, wenn eine Inhaltsdatenbank aus einer Serverfarm in einer anderen Serverfarm wiederhergestellt wird, ohne zuvor die ursprüngliche Datenbank zu entfernen, und wenn anschließend der Befehl 'stsadm -o preparetomove' ausgeführt wird. Falls dies die Ursache ist, kann dieses Problem behoben werden, indem der Befehl 'stsadm -o preparetomove' mit der Befehlszeilenoption '-OldContentDB' verwendet wird.

Beim Umzug der Datenbanken wurd nur für die Sharepoint_Config der stsadm Befehl preparetomove verwendet. Grund ist der, das es sich bei dem System noch um ein SP1 handelt. Nach dem alle Datenbanken umgezogen sind, wurde auf der betroffenen Datenbank auch die -preparetomove -undo Option angewendet.

Wie bekomme ich auch diese beiden Probleme noch in den Griff? Wo kann ich ansetzten?

Henning Eiben Als Antwort am 15 Sept. 2010 11:22

[quote user="Sebastian"]

Der Alias funktioniert problemlos und schon gibts neue Probleme

Wie bekomme ich auch diese beiden Probleme noch in den Griff? Wo kann ich ansetzten?

[/quote]

Ich habe bisher die Migration von Datenbanken nur wie in http://technet.microsoft.com/en-us/library/cc512725%28office.12%29.aspx beschrieben durchgeführt (allerdings auf einem SP2 System).

Dabei habe ich allerdings nicht preparetomove verwenden müssen, und solche Probleme hatte ich anschließend auch nicht.

Wenn du in der Zentral-Administration unter Anwendungsverwaltung einmal die Inhaltsdatenbank ansiehst - ist da für deine Web-Anwendung denn mehr als eine Inhaltsdatenbank angegeben?

Sebastian Als Antwort am 15 Sept. 2010 11:34

Hallo Henning,

nein war nicht. Ich konnte das Problem lösen, in dem ich stsadm -o sync deletecontentdb 0 ausgeführt habe. Zuvor habe ich jedoch noch preparetomove -undo durchlaufen lassen.

Die Farm sieht nun vom Eventlog her wieder gut aus - alles schon blau :-)

Mal eine generelle Frage:

Wäre es nicht einfacher gewesen, ich hätte eine parallele Farm aufgesetzt und einfach nur die ContentDBs für die MySites und die Portale umgehängt?

Henning Eiben Als Antwort am 15 Sept. 2010 11:39

Das kommt darauf an, wieviele Einstellungen du in der Zentral-Admin vorgenommen hast. Denn diese Einstellungen sind alle in der Config-DB, die du ja bei einer neuen Farm neu erstellen müsstest.

Aber generell ist das ein durchaus valider Ansatz. Damit kann man sich einige Probleme ersparen. Allerdings musst du dann genau alles an Einstellungen dokumentieren und in der neuen Farm wieder anwenden.

Sebastian Als Antwort am 15 Sept. 2010 11:52

Dokumentiert ist die Farm vorbildlich. Was bedeutet "alles an Einstellungen ... in der neuen Farm wieder anwenden"? Da mit meinst du doch nur Einstellungen wie ausgehende/ Eingehende Emails und so weiter. Sprich alles was in der Central Administration vorgenommen wird.

Berechtigungen für Bibliotheken, Dokumente, Listen und was sonst so im Frontend eingestellt wird ist damit nicht gemeint oder?

Andi Fandrich Als Antwort am 15 Sept. 2010 12:08

Genau so ist es. Alles, was über die Zentraladministration oder stsadm oder PowerShell geändert werden kann, steht in der Config-DB. Außerdem alle selbtentwickelten oder zugekauften Erweiterungen.

Die eigentlichen Inhalte (Webs, Listen, usw.) und ihre Berechtigungen stehen in den Content-DBs.

Sebastian Als Antwort am 15 Sept. 2010 12:13

Ich danke euch für die tolle Unterstützung. Dann bleibt ja nur noch das ganze am Produktivsystem durchzuführen.

Henning Eiben Als Antwort am 15 Sept. 2010 12:11

Ja, genau. Aber auch alle AAM-Einträge, die SSPs (also welche es gibt, und welche Web-Apps dazugehören). Die Konfiguration innerhalb des SSPs dürfte nicht mehr in der Config-DB stehen.

Aber auch Timer-Jobs o.ä. die vielleicht von Drittanwendungen angelegt wurden stehen auch in der Config-DB.

Sebastian Als Antwort am 15 Sept. 2010 12:16

AAM Einträge?

Henning Eiben Als Antwort am 15 Sept. 2010 12:23

Alternative Access Mapping

Sebastian Als Antwort am 15 Sept. 2010 12:27

Dank der wirklich guten Dokumentation sind diese Daten schnell wieder herzustellen.

Henning Eiben Als Antwort am 15 Sept. 2010 11:17

[quote user="Sebastian"]

Ist das richtig so? Alias = alter SQL Server; Servername = neuer SQL Server

http://www.sharepointassist.com/2010/02/02/configure-a-sql-server-alias-for-sharepoint-sql-server-2008/

[/quote]

ja, genau.