Written by:
29.10.2007 

Den neue SQL Server 2005 wird installiert und entsprechend der Umgebung konfiguriert.

Die User-Datenbanken, die auf das neue System (nur möglich für die dafür unterstützte Version, bei SQL Server 2005 ist das SQL Server 7.0) transferiert werden müssen, auf dem Quellsystem mit dbcc checkdb prüfen.

Die User-Datenbanken kann man mittels backup und restore oder per detach, copy und attach auf das neue System übertragen.

Danach sollten die Datenbanken auf dem SQL Server 2005 mit dbcc checkdb geprüft werden. Wichtig nach diesem Check in das ErrorLog des SQL Servers schauen, ob ein Minidump des DBCC CHECKDB dort eingetragen ist. Ggf. Fehlerursache bereinigen. (Hintergrund: Der dbcc checkdb unter SQL 2005 kann Fehler identifizieren, die unter SQL 2000 nicht als Fehler erkannt wurden.) 

Dann steht DBCC UPDATEUSAGE auf der ToDo Liste. Nach Aktualiserung auf SQL Server 2005 wird dies empfohlen, um eventuell vorhandene ungültige Zählwerte zu korrigieren: http://technet.microsoft.com/de-de/library/ms188414.aspx

Dann kann man noch die neue Methode ALTER DATABASE meineDB SET PAGE_VERIFY CHECKSUM einstellen. "Wenn CHECKSUM angegeben wird, berechnet Database Engine (Datenbankmodul) beim Schreiben der Seite auf den Datenträger eine Prüfsumme des Inhalts der gesamten Seite und speichert den Wert im Seitenkopf. Wenn die Seite vom Datenträger gelesen wird, wird die Prüfsumme erneut berechnet und mit dem im Seitenkopf gespeicherten Prüfsummenwert verglichen." http://technet.microsoft.com/de-de/library/ms190249.aspx

Schließlich sollte man den Kompatibilitätslevel der Datenbank auf 9.0 umstellen. Dann funktionieren auch alle Reports im SSMS - SQL Server 2005 Management Studio.

Noch ein Hinweis zu den Views. Es wird bei SQL Server 2000 in Views hin und wieder das ORDER BY in Views aufgnommen. Aus meiner Sicht gehört es da nicht hin. Das möchte ich hier aber nicht weiter diskutieren. Nur eins möchte ich anmerken, der SQL Server 2005 ignoriert das angegebene ORDER BY in Views. (Dies ist kein Bug!)

Damit man nicht alle Logins auf dem neuen Server per Hand einrichten muss, sollte SSIS - SQL Server Integration Service auf dem neuen System verfügbar sein. Man kann sich ein SSIS Package erstellen, das nur die Aufgabe/Task hat Transfer Logins. So kann man sich leicht die Login vom Quell- in das Zielsystem holen. Aber Achtung: Bitte bei der Task darauf achten, dass die Option "SID erhalten" gewählt ist. Bei der Task kann man auch gleich aufräumen und nur die Login auswählen, die man im neuen System benötigt.

Mit SQL Server 2005 wurden die Schema eingeführt. Nach dem Attach/Restore einer Datenbank aus einer früheren Version werden, werden je User ein Schema eingerichtet. Mir hat das angewandte Verfahren dafür nicht gefallen und habe mich hingesetzt und die Zahl der erzeugten Schema reduziert.

Noch ein Wort zu den Wartungsplänen. Wer mit SQL Server 2000 die Wartungspläne so organisiert hat,  z. B.

• einen Wartungsplan für die Sicherung Datenbanken mit Wiederherstellungsmodus einfach
• einen Wartungsplan für die Sicherung Datenbanken mit Wiederherstellungsmodus vollständig usw.
• einen Wartungsplan für die Sicherung der Transaktionslogs der Datenbanken mit Wiederherstellungsmodus vollständig

dann hat man u. U. den Nachteil, dass neu hinzugefügte Datenbanken nicht automatisch gesichert werden, weil sie im Wartungsplan nicht angegeben sind.

Mit SQL Server 2005 sollte man die Struktur der Wartungspläne an die neuen Möglichkeiten anpassen, denn es ist nun möglich, einen Wartungplan für Transaktionslog Sicherungen für alle Datenbanken zu definieren, auch wenn die Datenbank den Wiederherstellungsmodus einfach hat. Dies wird dadurch ermöglicht, dass bei der Sicherung des Transaktionlogs die Datenbanken übersprungen werden, bei denen keine Transaktionslog Sicherung möglich ist.

Für SQL Server 2005 kann man einfach folgende Wartungpläne definieren, z. B.

• Datenbanksicherung ALLER Datenbanken
• Transaktionssicherung ALLER Datenbanken

Neu hinzugefügte Datenbanken am SQL Server 2005 werden so automatisch gesichert.

Trackback Print

Tags:

Categories:

Location: Blogs OPI's SQL Blog