Update von SQL Sever 7 zu 2000

[Holger Möller]

Hallo!

Wir planen ein Update von SQL Server 7 auf 2000 und wollen im gleichen Zug die Daten auf ein neues RAID-System portieren.

Wir denken dabei über 2 Möglichkeiten nach:

1. Zuerst ein Backup der Benutzer-Datenbanken in Version 7 (aus Sicherheitsgründen), dann Löschen aller Benutzer-Datenbanken in Version 7. Portieren des SQL Server 7 auf das neue RAID-System. Nun das Upgrade auf Version 2000 und abschließend das Wiederherstellen der Datenbanken (im Format von 7) aus der Version 2000 heraus.

2. Zuerst ein Backup der Benutzer-Datenbanken in Version 7 (aus Sicherheitsgründen), dann die 2000er Version auf dem neuen RAID komplett neu installieren und abschließend ein Recorvery im SQL Server 2000 der alten Backups durchzuführen.

Uns ist aber unbekannt, ob es beim Wiederherstellen von Datenbanken im SQL Server 2000, die im Format der Version 7 vorliegen, Probleme geben kann, oder ob es reibungslos funktioniert. Weiterhin sollen die Zugriffsberechtigungen bestehen bleiben.

Vielleicht gibt es aber auch noch eine bessere Alternative zum portieren eines 7er Servers auf ein neues RAID und gleichzeitigem Updade auf 2000.

Das zugrundeliegende Betriebssystem auf dem Server wird übrigend Win2K Server sein.

Für jede Hilfe und Anregung wäre ich sehr dankbar (insbesondere was das Wiederherstellen betrifft).

Vielen Dank!

MfG

Holger

[Patrick Sack]

Hi,
<br>
<br>Neuen win2000 und sql2000 srv auf dem Raid aufsetzten und danach mittels DTS Export die Daten vom SQL7 auf den SQL2000 schieben. Bei dieser Methode kann man noch einstellen das die Benutzerberechtigungen mit übernommen werden. Wenn ihr schon eine Umstellung macht überlegt mal ob ihr von den SQL Berechtigungen zur gesicherten Anmeldung via NT Domäne Konten wechseln wollt.
<br>
<br>Von einem Backup recovery kann ich nur abraten, vorallem dann, wenn dieses Backup auf einem neuen Server zurückgesichert werden soll.
<br>
<br>Achtung wenn in Stored Procedures mit Temporären Tabellen gearbeitet wird, dann muß im Create Table ggf. was geändert werden (Stichwort Sortierreihenfolge bei VarChar).
<br>
<br>mfg
<br>p

[Andreas Kosch]

Hallo,

man kann auch die Datenbankdateien direkt auf den neuen Rechner kopieren und dann im <i>Enterprise Manager</i> den neuen Dialog <b>Datenbank anfügen</b> aufrufen. Wird dort die Datei ausgewählt, hängt der SQL Server 2000 die Datei als Datenbank ein. Das Hantieren auf der Kommandozeilenebene mit ATTACH ist somit beim 2000er nicht mehr notwendig.

Das Backup/Restore-Verfahren ist jedoch in jedem Fall sicherer

[Patrick Sack]

@A.Kosch:
<br>bei attach/detach oder Backup/Restore werden da auch die Benutzer Berechtigungen / Konten mit übertragen?
<br>
<br>Mit Backup/Restore habe ich bisher nur Probleme gehabt. Ein Backup der Datenbank XDB auf dem Sql Server X wiederherzustellen funktioniert aber dieses backup auf dem SQL Server Y wiederherzustellen funktioniert nicht. Haben sie auch diese Erfahrung gemacht (@A.Kosch)?
<br>(Vieleicht sollte ich es einfach nochmal testen). Die besten Ergebnisse habe ich mit den DTS - import/export gemacht. Dauert zwar länger aber hat bisher immer funktioniert.
<br>
<br>@H.Möller:
<br>Bei DTS import/export SQL-Server 7 Objekte kopieren auswählen.
<br>
<br>mfg
<br>P

[Holger Möller]

Hallo!

Vielen Dank erst einmal für die Hilfe!

Noch zur Ergänzung: Wir benutzen bereits die Windows NT Domänen Konten. Sie existieren aber ebenfalls unter "Sicherheit" - "Benutzernamen" (als NT-Gruppen) und haben dort ihre Rechtevergabe.

Ich habe nun Testweise einmal von einem SQL Server 7 zu einem anderen SQL Server 7 Datenbanken mit allen Benutzerrechten (auch auf Server-Ebene) exportiert, die dort noch nicht existierten. Dabei habe ich die zu exportierende Datenbank im DTS-Manager auf dem einen Server neu angelegt. Der Export (auch ein Import) schlug allerdings immer fehl, da er nach anderen Datenbanken verlangt hat, oder ihm Benutzergruppen nicht bekannt waren. Ich hatte dabei Objekte kopieren ausgewählt
Ein erneutes eingeben der Benutzerkennungen im SQL Server soll wenn möglich vermieden werden, da es eine Fehlerquelle ist.

@ Herrn Patrick Sack:
Beziehen Sie sich bei dem Problem mit der Sortierreihenfolge darauf, dass man in 2000 pro Datenbank Sortierreihenfolgen festlegen kann, oder ist da noch etwas anderes?

@ Herrn Andreas Kosch:
Im Gegensatz zu Herrn Sack sagen Sie, dass das Backup/Restore-Verfahren sicher(er) ist. Können Sie mir hier nähere Informationen geben?

Mittlerweile wird noch über die alternative nachgedacht, zuerst das update auf 2000 auszuführen und dann auf das neue RAID zu wechseln.
Dies ist wahrscheinlich die sicherste (und einfachste?) Methode, dauert vermutlich aber länger. Sind bei dieser Methode Probleme bekannt?

Noch einmal vielen Dank für Ihre Hilfe!

MfG

Holge

[Patrick Sack]

Hallo,
<br>
<br>mal folgendes probieren:
<br>
<br>im DTS Export Assistent muß man die Quelle, dann die Zieldatenbank eingeben und dann erscheint eine Auswahl, in der man "Objekte und Daten zwischen SQL-Server7 Datenbanken übertragen" auswählt.
Dann "weiter drücken", "Standardoptionen verwenden" deaktivieren und dann auf "Optionen drücken...". Hier bitte SQL-Server-Benutzernamen (Windows-NT und SQL Server-Benutzernamen) übertragen auswählen. "OK" dücken und weiter und weiter ...
<br>
<br>Das sollte bei den Benutzerproblemen helfen.
<br>
<br>Zu folgendem "Der Export (auch ein Import) schlug allerdings immer fehl, da er nach anderen Datenbanken verlangt hat, ..." (ggf. hier die genaue Fehlermeldung mal angeben)
<br>Wenn Replikation, Verteilung usw. aktiviert sind dann muß man die ggf. für diese DB deaktivieren (das würde ich jedoch nur im Letzten Fall machen wenn die Datenbank überhaupt nicht von A nach B bewegt werden kann). Was eher sein kann ist das irgend wo in der DB Views oder Stored Procedures existieren, die auf Elemente in anderen Datenbanken verweisen. In solch einem Fall sollte man zunächst diese DBs auf die verwiesen wird exportieren und danach die ursprüngliche DB.
<br>Was auch noch sein kann:
<br>Es wird versucht die Benutzer berechtigungen zu übertragen. Mit diesen Berechtigungen werden ggf. auch Rechte für DBs übertragen, die auf dem neuen SQL Server nicht existieren. (Ob das so ist (sein kann) weiß ich nicht. Die genaue Fehlermeldung wäre wohl interessant.
<br>
<br>Versuchen sie aber auch mal den Weg von Herrn Kosch ggf. habe ich, wie schon erwähnt, in der Eile beim Backup was falsch gemacht.
<br>
<br>mfg
<br>p

[Holger Möller]

Hallo!

@ Herrn Patrick Sack:

Die erste Methode, die Sie beschrieben haben war genau die, die zu Fehlern geführt hat.
Beim ersten Ausführen bekam ich folgende Fehlermeldung:
"[Microsoft][ODBC SQL Server Driver][SQL Server]Die Datenbank <Datenbankname> ist nicht vorhanden. Verwenden Sie sp_helpdb, um die verfügbaren Datenbanken anzuzeigen"
(wobei ich hier glaube, das die konkret angegebene Datenbank keine Rolle spielt, da sie mit dieser garantiert nicht interagiert. Weiterhin kann ich hier sehen, dass nicht alle Benutzergruppen/-namen auf den neuen Server portiert wurden.)

Wenn ich nun anschließend beim Export die Standardoptionen verwende bekomme ich folgende Fehlermeldung:
"[Microsoft][ODBC SQL Server Driver][SQL Server]Windows NT-Benutzer oder -Gruppe <Name> nicht gefunden. Überprüfen Sie den Namen erneut"
(dies tritt auf, weil beim ersten Ausführen nicht alle Benutzernamen und -gruppen mit portiert wurden)

Die Datenbank, die ich Testweise exportiert habe, hat keinerlei Verknüpfungen mit anderen Datenbanken (ich habe mir eine Prozedur geschrieben, die mir die Verbindungen zwischen allen Datenbanken auf dem Server ausgibt, daher weiß ich das).
Auch ist keine Replikation oder Verteilung, etc. aktiviert.

Mir ist keine Möglichkeit bekannt, um mehrere oder alle Datenbanken eines Servers auf einen anderen zu portieren. Wenn nun Ihre Annahme stimmt, dass er Fehlermeldungen liefert, wenn bei den Berechtigungen auch Rechte für DBs übertragen werden, die auf dem neuen nicht existieren, so besteht das Problem, dass ich keine Datenbank portieren kann, da es keine gibt, die Benutzer enthält, die ausschließlich in einer Datenbank enthalten sind. Das bedeutet, ich müsste theoretisch <b>alle</b> Datenbanken <b>gleichzeitig</b> exportieren können.

Den von Herrn Kosch vorgeschlagenen Weg habe ich bis jetzt noch nicht testen können, werde ich aber noch tun.

Nochmals Danke für alle Tips, Hilfen und Anregungen!

MfG

Holge

[Holger Möller]

Hallo!

Mittlerweile konnte ich den Vorschlag von Herrn Kosch testen. Da ich allerdings nur auf der Version 7 testen konnte, habe ich die gespeicherte Prozedur <b>sp_attach_db</b> verwendet. Ich habe zunächst die Dateien einer Datenbank auf ein anderes Laufwerk kopiert, auf den ein anderer (lokaler) SQL Server zugreift. Dann habe ich von diesem Server aus mittels Query Analyser und erwähnter Prozedur die Datenbank angefügt.

Folgendes Resultat bezüglich der Benutzerrechte trat dabei auf:
Keine der Benutzerkennungen des ursprünglichen Servers wurde bei dem neuen Server eingetragen (logisch, dass keine eingetragen wurden, die nicht auch in der angefügten Datenbank enthalten waren, aber auch die, die darin enthalten waren fehlten.

Interessanterweise tauchte bei der angefügten Datenbank unter Benutzernamen ein einziger Benutzername (NT-Gruppe) auf, der nur auf dem ursprünglichen Server existierte. In der <b>sysusers</b> stehen alle Kennungen, die auf dem ursprünglichen Server Zugriff hatten. Ich hätte jetzt verstanden, wenn alle aufgetaucht wären, oder keine. Aber nur eine Kennung ist mir rätselhaft. Vielleicht liegt es an Windows NT. Dagegen spricht aber, dass ich selbst nicht Mitglied dieser einen Benutzerkennung bin und die zugrundeliegende NT-Gruppe auch nichts mit dem Rechner zu tun hat, auf der der lokale SQL Server liegt.

Wenn ich nun auf dem lokalen SQL Server eine Kennung eintrage, die auf dem ursprünglichen Server existiert und die auch Zugriff auf die angefügte Datenbank habe, so werden die alten Berechtigungen automatisch übernommen. Ausnahme ist die Standarddatenbank, auch wenn es die neu angefügte ist, die also existiert.

Versuche ich testhalber eine Benutzerkennung des ursprünglichen Servers auf dem neuen einzutragen, die nur Rechte auf Datenbanken besitzt die auf dem ursprünglichen Server liegen, so bekomme ich folgende Fehlermeldung:
"Fehler 15401: Windows NT-Benutzer oder -Gruppe '<Name>' nicht gefunden. Überprüfen Sie den Namen erneut."

Mittlerweile habe ich noch in einem Dokument vom Microsoft Technet gelesen, dass man den <b>Copy Database Wizard</b> auch für das Update der Datenbanken von 7 auf 2000 verwenden kann. Sind hierüber vielleicht Erfahrungen bekannt?

Vielen Dank für die Hilfe!

MfG

Holge

[Patrick Sack]

Mmmmh,
<br>"Fehler 15401: Windows NT-Benutzer oder -Gruppe '<Name>' nicht gefunden. Überprüfen Sie den Namen erneut."
kann es sein, das der neue Server nicht in der gleichen Domäne ist? (das würde erklären, warum der export der Benutzerdaten mittels DTS nicht funktioniert)
<br>
<br>was passiert eigentlich wenn man:
<br>eine neue leere Datenbank auf dem QuellServer einrichtet (mit einer Tabelle) auf die Sa und die Vordefiniereten Benutzer administrator und Benutzer Zugriff haben (oder am besten gar keine rechte vergeben; einfach create database und create Table und dann export).
<br>Diese nun mittels DTS auf den ZielServer übertragen inkl. Benutzerdaten (wie oben beschrieben).
<br>
<br>Funktioniert das?
<br>
<br>mfg
<br>p

[Holger Möller]

Hallo!

Unsere Umstellung auf SQL Server 2000 ist mittlerweile im Großen und Ganzen abgeschlossen. Letztendlich sind wir folgendermassen vorgegangen (auch wenn nicht alles so geplant war).

Wir haben, nachdem Windows 2000 Server installiert war, einen neuen SQL Server 2000 (Standard Edition) auf ein leeres Raid 5 installiert, und die tempdb, sowie die Transaktionsprotokolle auf ein Raid 10 gelegt. Anschließend mußte ich unsere Datenbanken fast einzeln auf die neuen Raids kopieren und habe sie immer mit <b>sp_attach_db</b> angefügt. Im diesem Zuge habe ich auch neue Initialisierungsgrößen gesetzt um die Fragmentierung geringer zu halten. Ursprünglich wollte ich das Setzen der Größen bereits auf dem alten SQL Server vornehmen, aber der Speicherplatz war zu gering. Für das Anfügen der Datenbanken hatte ich eine Prozedur geschrieben, die ich dann um das Setzen der Größen erweitert habe. Dies war etwas zeitaufwendig, hat aber funktioniert.

Sämtliche alten Benutzernamen waren nach dem Anfügen in der Datenbank enthalten und nach dem ich Windowsbenutzergruppen wieder im Server bekannt gemacht hatte, waren ihre Rechte wie ursprünglich vorhanden. Probleme bereiteten die wenigen lokalen SQL Server-Benutzer, die aus verschiedenen Gründen (Backupsoftware, geplanter Web-Zugriff, etc.) vorhanden sind.
Nachdem ich sie im Server wieder angelegt hatte und unter Sicherheit --> Benutzernamen ihre Zugriffe definieren wollte (sie waren nicht wieder automatisch vorhanden, wie bei den Windowsgruppen), kam es zu Konflikten, da der SQL Server den neu angelegten lokalen Benutzer und die in den Datenbanken vorhanden nicht als indentisch erkannte. Hier habe ich die Benutzer aus den Datenbanken gelöscht und dann im Server neu angelegt und ihre Rechte wieder neu vergeben (war auf Grund unserer Struktur nicht aufwendig).

Damit hatten die Benutzer wieder Zugriff auf die Datenbanken.

Ein weiteres Problem ergab sich aus den, im alten Server angelegten, Repository Paketen. Um sie auf den neuen SQL Server zu portieren, haben wir den alten Server noch einmal gestartet (gut das er noch lauffähig ist) und haben von dort per Enterprise Manager die Pakete auf eine MSDE kopiert. Von dieser MSDE haben wir die dann auf den neuen Server kopiert (da wir nicht beide Server gleichzeitig laufen lassen können). Damit lagen auch sie wieder in der graphischen Form vor. Es gab dabei auch die Möglichkeit sie als <b>dts</b>-Dateien zu speichern, wobei ich aber keine Möglichkeit gefunden habe, diese auf einem anderen Server wieder einzuspielen, so dass die graphische Form wieder vorhanden ist.

Soweit ich das bis jetzt beurteilen kann, war die Umstellung erfolgreich.

Ich möchte mich daher noch mal bei Ihnen für Ihre Hilfe bedanken!

MfG

Holge

[Patrick Sack]

<br>Danke für die Info.
<br>
<br>mfg
<br>P