Aktualisieren Sie die SQL Server 2000-Datenbank auf 2008 R2 und aktivieren Sie neue Funktionen

Ich habe kürzlich die SQL Server 2000-Datenbank auf 2008 R2 aktualisiert.

Was ich getan habe war:

1. Herunterfahren des SQL Server 2000 (Express) -Dienstes auf alter Maschine,
2. Verschieben Sie die Datendateien ( mydatabase.mdf und mydatabase.ldf ) auf einen neuen Computer.
3. Führen Sie SQL Server Management Studio 2008 aus.
4. Verbindung zur lokalen Datenbankmaschine herstellen,
5. Anhängen von Datendateien an die Datenbank.
6. Ändern Sie den Kompatibilitätsgrad der Datenbank in SQL 2008 (100).

Frage: Was kann ich noch tun, um die Migration abzuschließen?

Ich möchte:

1. Verwenden Sie neue Funktionen wie Prüfsummen und ein vollständiges Wiederherstellungsmodell.
2. Stellen Sie sicher, dass diese Datenbank genau so ist, wie sie in SQL 2008 R2 erstellt wurde.
3. Stellen Sie sicher, dass diese Datenbank vollständig kompatibel, korrekt und für das neue SQL 2008 R2-Datenbankmodul perfekt geeignet ist.

Mit anderen Worten: Ich möchte nur wissen, wie man eine alte SQL 2000-Datenbank korrekt und vollständig in eine neue 2008 R2-Datenbank konvertiert. Seien Sie ruhig, dass alles richtig gemacht wurde, und freuen Sie sich über alle neuen Funktionen.

Ich stelle diese Frage, weil ich viele Websites im Internet gefunden habe, die so viele verschiedene Dinge sagen, die mich verwirren: Einige sagen, dass es erforderlich ist, Indizes neu zu erstellen, andere sagen, andere Dinge zu tun ... und Jetzt weiß ich nichts und möchte daher die Meinung einer erfahrenen Person und klare, schrittweise Anweisungen hören. Ich arbeite für eine sehr kleine Firma, bin alleine und möchte nichts vermasseln.

Sir, ich bin wirklich beeindruckt von Ihrer Antwort, ich habe nicht so viel erwartet.

Also ein paar Kommentare:

1. Die Datenbank ist jetzt in Produktion. Wie gesagt, es wurde mit der Deattach-Attach-Methode aktualisiert, wie im ersten Beitrag beschrieben und auf MSDN beschrieben: http://msdn.microsoft.com/en-us/library/ms189625.aspx hatte es schnell getan werden, also musste ich es so machen. Vergessen wir, wie unangemessen es war und konzentrieren wir uns auf die aktuelle Situation.

2. Die Benutzer / Persmission ist hier kein Problem - es gibt nur wenige und Berechtigungen sind einfach.

3. Die Anwendung, die die Datenbank verwendet, ist mit SQL 2000 bis 2012 kompatibel, daher ist dies auch kein Problem.

4. Die Datenbankdatei (MDF) ist nicht groß - nur etwa 1 GB.

Noch ein paar Fragen:

1. Sie empfehlen die Verwendung der Sicherungs- / Wiederherstellungsmethode, aber wie oben beschrieben. Kann ich jetzt auf Probleme stoßen? Alles hat problemlos geklappt.

2. Informationen zur Prüfsumme und zum vollständigen Wiederherstellungsmodell: Es war in SQL 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.

3. Ich bereite mich darauf vor, diese Datenbank auf SQL 2012 zu migrieren - also war es zuerst von SQL 2000 auf 2008 R2, jetzt von 2008 R2 auf 2012 (dies war nicht direkt möglich, da die SQL 2000 - Datenbanken in SQL 2012 nicht unterstützt wurden) SQL 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?

4. 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?

5. Da wir jahrelang SQL 2000 Express verwendet haben (keine Verwaltungsschnittstelle), haben wir Sicherungen einfach durch Stoppen der Engine und RAR des DATA-Verzeichnisses durchgeführt. Ist dies für den Moment in SQL 2008 nicht noch besser als die Verwendung der Sicherungsfunktion in Management Studio?

6. Vollständiger Wiederherstellungsmodus mit häufigen Transaktionsprotokollsicherungen - Wo wird das Transaktionsprotokoll gespeichert - ist es die LDF-Datei? Wie soll ich es richtig sichern?

Ich weiß, dass meine Fragen albern klingen mögen, ich bin kein professioneller Datenbankadministrator, aber ich bin die einzige Person hier, die solche "Hardcore" -Aufgaben wie das Upgrade der Datenbank-Engine ausführen kann. Ich bin mir auch sicher, dass Ihr Wissen anderen Menschen wie mir sehr helfen wird.

Vielen Dank für Ihre Zeit und Ihr Wissen, das weiß ich sehr zu schätzen.

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:

1. Skript unsere Anmeldungen auf 2000 Server mit sp_help_revlogin .
2. Skript aus Jobs und Verbindungsservern von SQL 2000 Server.
3. Stoppen Sie Webserver, die eine Verbindung zu 2000 Server herstellen. Stellen Sie sicher, dass keine Anwendungen eine Verbindung zum 2000-Server herstellen.
4. 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.)
5. 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.
6. Synchronisieren Sie verwaiste Benutzer (falls vorhanden) und erstellen Sie SQL Agent-Jobs und Verbindungsserver auf dem neuen Server neu.
7. Ändern Sie die Kompatibilitätsstufe für die wiederhergestellten Datenbanken auf 100.
8. Dbcc checkdb mit aktivierten Optionen all_errormsgs und data_purity: DBCC CHECKDB ('<db_name_goes_here>' ) WITH ALL_ERRORMSGS,NO_INFOMSGS, DATA_PURITY
9. Führen Sie DBCC UPDATEUSAGE für die wiederhergestellten Datenbanken aus DBCC UPDATEUSAGE('database_name') WITH COUNT_ROWS
10. Aktualisieren Sie die Statistiken für alle Tabellen mit einem vollständigen Scan: Update Statistics table_name with FULLSCAN
11. 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 .
12. Kompilieren Sie alle SPs mit sp_recompile 'procedureName'
13. Aktualisieren Sie Ihre Ansichten SP_REFRESHVIEW view_name
14. Stellen Sie sicher, dass Sie die Datenbankoption ändern: page verify to CHECKSUM.
15. Ä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.

16. 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:

• Wartung von SQL Server- Indizes und -Statistiken - zum Defragmentieren Ihrer Indizes
• SQL Server Backup - für die Sicherung Ihrer Daten
• SQL Server-Integritätsprüfung - Zum Überprüfen der Datenbankkonsistenz Ihrer Datenbanken

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