MS SQL Datenbank verschieben / migrieren

[Hardwaretoaster]

N'abend,

ich habe demnächst größere Datenbank umzuziehen (MS SQL Server, Quelle 2005, Ziel 2008).
Simples Vorgehen bei einer kleinen DB oder einer wo Downtime nicht so wild ist wäre

Export
Verschieben
Import


Nun dauert mir das kopieren der Datenmenge zu lange um es am Tag der Migration zu machen.
Ich will also Deltas kopieren oder die DB replizieren um am Upgradetag nur das letzte Delta initiieren zu müssen und dann nur den Applikationsspezifischen Job über die Daten laufen lassen zu müssen.

Für einfache Files gibt#s in solchen Fällen rsync. Nur suche ich aber schon eine ganze Weile und finde nichts Eindeutiges, was auch für MS-SQL-Server funktioniert.

Wahrscheinlich fehlt mir nur das passende Stichwort: Kann mir jemand auf die Sprünge helfen?

[sei laut]

Du suchst eine Transaktionsreplikation, damit sollte es möglich sein, 2 identische MSSQL DB-Server zu haben. Jedenfalls kannst du mal in Richtung stöbern. Vorausgesetzt, beide Server können gleichzeitig laufen.
Kann dir aber sonst nicht weiterhelfen, hab das bisher nur mit MySQL umgesetzt.

[Matrix316]

Stichwort Logshipping oder Transaktionsprotokollsicherung. Man könnte es dauerhaft einrichten oder nur einmal. Je nach dem wie viele Daten das sind.

http://msdn.microsoft.com/de-de/library/ms179478.aspx
http://msdn.microsoft.com/en-us/library/ms190640.aspx

[Hardwaretoaster]

Danke, das Stichwort Log-Shipping scheint schon mal weiterzuhelfen. Dann werde ich mich da mal reinlesen, habe so einige Restriktionen:

Die Datenbank ist sehr BLOB und Stored Procedure lastig (geht um eine SharePoint-Content-DB)
ich wechsle von den Unterbau von 2005 nach 2008
eventuell sind Quelle oder Ziel geclustert


Mal schauen ob es da irgendwo Nebenwirkungen zu beachten gibt.

[Matrix316]

Wie groß ist denn die Datenbank? (also die Dateien)

[Hardwaretoaster]

Netto ~200GB (logisch in mehr als einer DB, da aber in einer Web App muss das in einem Schlag rüber), brutto müsste ich später nochmal nachschauen.

[Matrix316]

Ok, da wäre Logshipping nicht schlecht. Aber am besten die DB vorher schon rüberziehen und nicht erst beim Einrichten des Logshippings. Geht zwar beides, aber bei 200 GB würde das ziemlich lange dauern. ;) Die Rechner müssen aber schon im gleichen Netz sein, btw.

[sei laut]

Ich verstehs aber nicht wirklich. Man hat nen Server mit einer 200GB Datenbank, der nicht zulange weg sein darf.
Wärs dann nicht von Grund auf sinnvoller, gleich was halbwegs redundantes hinzustellen, wenn das System so wichtig ist? Ich meine, bei einer so fetten DB stelle ich mir auch das Backup schwierig vor - oder kann man MSSQL Datenbanken inkrementell sichern?

[Hardwaretoaster]

Danke, hilft mir auf jeden Fall schon mal zwecks Idee. (gleiches Netz und sogar gleiches DC sind gegeben)

@seiLaut: Würde ich hier ein System auf Ausfallsicherheit trimmen müssen, wäre ich voll bei dir. Sowohl die Maschine als auch das Storage-System drunter sind redundante. Weil Full-backups von sowas lange dauern werden inkrementelle eingesetzt.

Was ich machen muss ist logisch die Migration der Applikation von einer auf die andere SharePoint-Farm.

Vorgehen ist da typisch (mit ein paar Schritten drum herum aber prinzipiell): Detach, rüberkopieren, attach, SP-spezifische-Upgrade-Routine, DNS-Change, fertig

Ich möchte die Enduser bei möglichst wenigen dieser Schritte damit behelligen, daher mein erster Entwurf des Plans: DB von A nach B im Hintergrund - User können weiterhin normal arbeiten; bevor ich die Upgradeprozedur auf der neuen anstoße muss ich die Quelle auf Read-Only nehmen; die user kommen aber zumindest noch lesend auf Ihre Sachen, sobald die Upgrade-Prozedur durch ist kommt die DNS-Änderung und ich bin durch.

Das ist nicht ganz trivial (und mittelfristig ist da sicher BLOB-Externalization ein Thema aber eins nach dem anderen), aber deshalb fange ich jetzt an zu planen und zu testen obwohl der Ernstfall noch ein ganzes Weilchen entfernt ist ;)