Der wichtigste Schritt besteht darin, den Upgrade Advisor auszuführen für die SQL Server 2000-Datenbank und alle von ihm gemeldeten Probleme zu beheben.
Verwenden Sie als bewährte Methode das Upgrade Advisor-Tool für Ihre ältere SQL Server 2000-Datenbank und importieren Sie eine Ablaufverfolgungsdatei zur Analyse in das Upgrade Advisor-Tool. Mit der Tracedatei erkennt der Upgrade Advisor Probleme, die bei einem einfachen Scan der Datenbank möglicherweise nicht auftreten, z. B. in Anwendungen eingebettetes TSQL. Sie können TSQL-Traces mit SQL Profiler auf Ihrem SQL Server 2000-Server während der üblichen Geschäftszeiten erfassen und diese Traces mit dem Upgrade Advisor analysieren.
Der Rest der Schritte wäre also:
Am Tag der Migration:
- Skript unsere Anmeldungen auf 2000 Server mit sp_help_revlogin .
- Skript aus Jobs und Verbindungsservern von SQL 2000 Server.
- Stoppen Sie Webserver, die eine Verbindung zu 2000 Server herstellen. Stellen Sie sicher, dass keine Anwendungen eine Verbindung zum 2000-Server herstellen.
- Sichern Sie Ihre Datenbanken und stellen Sie sie wieder her auf dem SQL 2008 R2-Zielserver wieder her. (Hinweis: Trennen Sie die Verbindung nicht, da dies zu Fehlern führen kann. Sie erhalten dann eine getrennte Datenbank und keine Sicherungen.)
- Nachdem Ihre Sicherungen auf dem 2008 R2-Server wiederhergestellt wurden, führen Sie die Ausgabe von sp_help_revlogin auf dem 2008 R2-Server aus, um die Anmeldungen erneut zu erstellen.
- Synchronisieren Sie verwaiste Benutzer (falls vorhanden) und erstellen Sie SQL Agent-Jobs und Verbindungsserver auf dem neuen Server neu.
- Ändern Sie die Kompatibilitätsstufe für die wiederhergestellten Datenbanken auf 100.
- Dbcc checkdb mit aktivierten Optionen all_errormsgs und data_purity:
DBCC CHECKDB ('<db_name_goes_here>' ) WITH ALL_ERRORMSGS,NO_INFOMSGS, DATA_PURITY
- Führen Sie DBCC UPDATEUSAGE für die wiederhergestellten Datenbanken aus
DBCC UPDATEUSAGE('database_name') WITH COUNT_ROWS
- Aktualisieren Sie die Statistiken für alle Tabellen mit einem vollständigen Scan:
Update Statistics table_name with FULLSCAN
- Optional: Überprüfen Sie die Fragmentierungsstufen, und führen Sie je nach Fragmentierungsstufe eine Neuorganisation / Neuerstellung aller Indizes durch. Sie können Olas Skripte verwenden .
- Kompilieren Sie alle SPs mit
sp_recompile 'procedureName'
- Aktualisieren Sie Ihre Ansichten
SP_REFRESHVIEW view_name
- Stellen Sie sicher, dass Sie die Datenbankoption ändern: page verify to CHECKSUM.
- Ändern Sie das Wiederherstellungsmodell (falls abweichend von SQL 2000) in FULL. Wenn Sie zum vollständigen Wiederherstellungsmodell wechseln, stellen Sie sicher, dass Sie häufig Transaktionsprotokollsicherungen durchführen. Auf diese Weise können Sie den Zeitpunkt wiederherstellen und Ihr T-Log nicht aufblähen.
Ab SQL Server 2005 wurde Database Mail eingeführt. Sie müssen also von SQLMail zu Database Mail migrieren.
USE [master]
GO
sp_configure 'show advanced options',1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'Database Mail XPs',1
GO
RECONFIGURE
GO
Wenn Sie eine Replikation haben, müssen Sie diese zurücksetzen. Wenn ein DR wie Logshipping oder Mirroring (neu in 2005 und höher, aber in 2012 abgeschrieben) auftritt, müssen Sie ihn ebenfalls zurücksetzen.
Alte DTS-Pakete müssen mithilfe von C:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTSMigrationWizard.exe(Befehlszeile) oder mithilfe des Paketmigrations-Assistenten auf SSIS migriert werden .
Sie können auch mein Skript unter /dba//a/36701/8783 verwenden . Obwohl die Methode " Detach / Attach" verwendet wird, wird die Verwendung der Methode " BACKUP / RESTORE" dringend empfohlen . Ändern Sie das Skript entsprechend.
Als Randnotiz:
- Aktivieren Sie Instant File Initialization auf dem neuen Server.
- Haben Sie mehrere Tempdb-Datendateien mit gleicher Größe.
- Aktivieren Sie das Ablaufverfolgungsflag 1118
- Konfigurieren Sie den maximalen und minimalen Speicher korrekt. Besonders Max Speicher von Standard entfernt.
- Passen Sie die MAXDOP-Einstellungen korrekt an. Weitere Informationen finden Sie unter /dba//a/36578/8783 .
- Am besten installieren Sie sp_Blitz von Brent Ozar. Führen Sie es aus und beheben Sie die von ihm gemeldeten kritischen Probleme mit hoher Priorität.
- Sie können SQL Power Doc sogar von kendalvandyke aus verwenden - SQL Power Doc funktioniert mit allen Versionen von SQL Server von SQL Server 2000 bis 2012 sowie allen Versionen von Windows Server und Windows-Betriebssystemen für Endverbraucher von Windows 2000 und Windows XP bis Windows Server 2012 und Windows 8. Auch nützlich für die Planung von Upgrades - sehen Sie, welche verborgenen Funktionen in einer Instanz verwendet werden.
- Aktivieren Sie "Für Ad-hoc-Workloads optimieren" und "Standard-Sicherungskomprimierungsoptionen".
Gehen wir auf Ihre Fragen ein ...
Was kann ich noch tun, um die Migration abzuschließen?
Siehe meine Antwort. Es wird Ihnen dabei helfen, einen Migrationsplan zu erstellen. Testen Sie Ihren Migrationsplan immer in einer UAT (nicht produktiv) zusammen mit geeigneten Anwendungstests durch Geschäftsbenutzer.
Verwenden Sie neue Funktionen wie Prüfsummen und ein vollständiges Wiederherstellungsmodell.
CHECKSUMist neu in SQL Server 2005 und höher. Ich habe es als Teil der oben beschriebenen Migrationsschritte behandelt.
full recovery modelist nicht neu. Dies hängt von Ihrem Geschäftstyp ab und bestimmt, wie viele Daten Sie im Katastrophenfall verlieren können.
Der vollständige Wiederherstellungsmodus mit häufigen Transaktionsprotokollsicherungen ermöglicht die Wiederherstellung zu einem bestimmten Zeitpunkt, indem der Datenverlust verringert wird.
Stellen Sie sicher, dass diese Datenbank genau so ist, wie sie in SQL Server 2008 R2 erstellt wurde.
Stellen Sie sicher, dass diese Datenbank vollständig kompatibel, korrekt und für das neue SQL 2008 R2-Datenbankmodul perfekt geeignet ist.
Verstehe das nicht ganz! Die obigen Migrationsschritte helfen Ihnen jedoch. Sie müssen nur die Datenbank wiederherstellen und die Kompatibilitätsstufe 10 100sowie die obigen Schritte ändern .
Ich möchte nur wissen, wie man eine alte SQL Server 2000-Datenbank korrekt und vollständig in eine neue 2008 R2-Datenbank konvertiert, beruhigt sein, dass alles richtig gemacht wurde und mit allen neuen Funktionen zufrieden sein kann.
Sie müssen vorsichtig sein, da dies auch Änderungen an Ihrem Anwendungscode erfordert. Wenn Ihr Anwendungscode geändert wird, um die neuen Funktionen in SQL Server 2008 R2 zu verwenden, treten keine Probleme auf. Vorausgesetzt, Sie haben einen vollständigen Regressionstest Ihrer Anwendung in einer UAT- oder DEV-Umgebung durchgeführt. Dies gibt Ihnen das größte Vertrauen, wenn Sie die eigentliche Migration in PROD durchführen.
Hinweis: Oben sind Schritte aufgeführt, an die ich mich erinnern konnte, und ich bin mir ziemlich sicher, dass nichts ausgelassen wird. Wenn ich sehe, dass ich einiges verpasst habe, werde ich es oder andere Experten auf dieser Seite hinzufügen - zögern Sie nicht, etwas hinzuzufügen!
Alles, was oben beschrieben wurde, muss zuerst in einer NON PRODUCTION-Umgebung abgespielt werden, um Überraschungen während der eigentlichen Migration zu vermeiden.
----------
Noch ein paar Fragen:
Sie empfehlen die Verwendung der Sicherungs- / Wiederherstellungsmethode, aber wie oben beschrieben. Kann ich jetzt auf Probleme stoßen? Alles hat problemlos geklappt.
Wenn alles geklappt hat und Sie die Datenbank anhängen konnten, haben Sie KEINE Probleme. Trennen / Anhängen vs Sichern / Wiederherstellen ist nur eine Methode, wie Sie Ihre Datenbank (en) an einen anderen Ort verschieben. Nur zu Ihrer Information . Sichern / Wiederherstellen ist sicherer und zuverlässiger, als wenn etwas schief geht (im schlimmsten Fall), dann müssen Sie zumindest eine Sicherung erstellen, um Ihre Datenbank (en) wiederherzustellen und wiederherzustellen.
Informationen zur Prüfsumme und zum vollständigen Wiederherstellungsmodell: Es war auf SQL Server 2000 nicht verfügbar / aktiviert, daher möchte ich sie jetzt verwenden. Sie sagten, dass ich nur diese Optionen in den Datenbankeigenschaften aktivieren muss? Ich habe irgendwo gelesen, dass es nicht genug ist und ich auch Indizes oder so etwas neu erstellen sollte. Ich weiß es wirklich nicht, ich frage nur.
Wie bereits erwähnt, ist die Prüfsumme ab Version 2005 neu. Es ist ein Mechanismus, mit dem SQL Server Seitenbeschädigungen erkennt, insbesondere aufgrund von E / A. Beziehen Sie sich auf meine Antwort hier für mehr Details.
Um CHECKSUM zu aktivieren und das Wiederherstellungsmodell auf FULL zu ändern, können Sie den folgenden T-SQL-Code verwenden:
USE master;
GO
ALTER DATABASE [your_database_name] -- change this !!
SET RECOVERY FULL, PAGE_VERIFY CHECKSUM;
GO
Hinweis: Sobald Sie die Datenbankoptionen festgelegt haben, wird sie bei der Migration von 2008R2 nach 2012 beibehalten.
Ich bereite die Migration dieser Datenbank auf SQL Server 2012 vor - also war es zuerst von 2000 auf 2008 R2, jetzt von 2008 R2 auf 2012 (dies war nicht direkt möglich, da 2000 Datenbanken in SQL nicht unterstützt wurden Server 2012). Ich verstehe also, dass ich Ihrem Leitfaden folgen sollte: Sichern Sie ihn in 2008 R2 und stellen Sie ihn in 2012 wieder her. Tun Sie dann den Rest Ihrer Tipps, richtig?
Ja bitte. Wie ich bereits sagte, ist die Backup-Wiederherstellung die bevorzugte Methode, es sei denn, Sie haben einen guten Grund, dies nicht zu tun.
Erklären Sie mir bitte die Sicherungs- / Wiederherstellungsmethode: Ist es wie ein Speicherauszug der Datenbank für SQL-Abfragen und das anschließende Wiederherstellen durch Ausführen einer Reihe von Abfragen? Wird diese Methode meine Datenbank übrigens "defragmentieren"? Wenn nicht, wie kann man es manuell defragmentieren / optimieren?
Backup / Restore ist ... ähnlich wie Dump und Load in Sybase, Oracle oder wahrscheinlich auch MySQL. Es ist nur SQL Server nennt es .. Backup / Restore.
Lesen Sie unbedingt: Grundlegendes zu SQL Server-Sicherungen von Paul Randall.
Einfache Syntax (für vollständige Syntax siehe BOL ):
backup database database_name
to disk = 'D:\backup\database_name_full.bak'
with init, stats =10
Die Wiederherstellung kann dann auf dem Zielserver wie folgt durchgeführt werden:
- Angenommen, das Festplattenlayout des Ziels stimmt nicht mit dem des Quellservers überein
restore database database_name
from disk = 'D:\backup\database_name_full.bak'
move 'logical_data_fileName' to 'physical_path\database_name.mdf'
move 'logical_log_fileName' to 'physical_path\database_name_log.ldf'
with recovery, stats = 10
- Angenommen, das Festplattenlayout des Ziels stimmt mit dem des Quellservers überein
restore database database_name
from disk = 'D:\backup\database_name_full.bak'
with recovery, stats = 10
Wird diese Methode meine Datenbank übrigens "defragmentieren"? Wenn nicht, wie kann man es manuell defragmentieren / optimieren?
Backup / Restore defragmentiert Ihre Datenbank nicht. Sie müssen Alter Index Reorganize oder Rebuild je nach Fragmentierungsgrad verwenden.
Da Sie SQL Server noch nicht kennen, kann ich Ihnen die Verwendung von Ola Hallengren sehr empfehlen:
Da wir SQL Server 2000 Express jahrelang verwendeten (keine Verwaltungsschnittstelle), haben wir Sicherungen einfach durch Stoppen des Moduls und RAR des DATA-Verzeichnisses durchgeführt. Ist dies für den Moment, da wir uns in SQL Server 2008 befinden, nicht noch besser als die Verwendung der Sicherungsfunktion in Management Studio?
Das Abstellen des Motors ist das Schlimmste, was Sie tun können, um ein Backup zu erstellen !!
Lesen Sie den Link von Paul über die Backups, die ich erwähnt habe, und das Skript von Use Ola. Microsoft hat einen KB-Artikel mit dem Skript zum Ausführen automatisierter Sicherungen - Planen und Automatisieren von Sicherungen von SQL Server-Datenbanken in SQL Server Express
Vollständiger Wiederherstellungsmodus mit häufigen Transaktionsprotokollsicherungen - Wo wird das Transaktionsprotokoll gespeichert - ist es die LDF-Datei? Wie soll ich es richtig sichern?
Jede SQL Server-Datenbank verfügt über ein Protokoll, in dem alle Transaktionen und Datenbankänderungen aufgezeichnet werden, die von jeder Transaktion vorgenommen wurden. Das Transaktionsprotokoll ist eine wichtige Komponente jeder Datenbank.
Die übliche Namenskonventionserweiterung für das Transaktionsprotokoll lautet ".LDF". Sie kann jedoch eine beliebige sein.
Ich werde nicht mehr darüber schreiben, da dies die Antwort sehr leicht machen wird. Siehe
Transaktion Log Management und meine Antwort hier hat auch eine gute Anbindung.
EDIT: 24.08.2016 .. Dies wird zukünftigen Lesern helfen:
Wenn Sie Ihre gesamte Instanz von einer Version auf eine andere Version migrieren, würde ich die Verwendung einer PowerShell-basierten Lösung dringend empfehlenStart-SqlMigration
