Discussion:
Datenbank Rücksicherung ***INCOMPLETE***
(zu alt für eine Antwort)
Thomas Bayer
2009-06-22 13:22:03 UTC
Permalink
Hallo,
habe einen 64 Bit SQL Server 2005.
Als Notfallsystem habe ich jetzt ein 32 Bit System in einer Virtuellen
Maschine aufgesetzt.
Beim Versuch, eine Datenbank-Sicherung in das Notfallsystem einzulesen,
steht sofort nach der Auswahl der Sicherungsdatei
"*** INCOMPLETE ***" im Namen drin.
etwa eine Minute nach dem Start bricht dann der Import mit folgender
Fehlermeldung ab:
Fehler bei Wiederherstellen für Server 'BACKUP'. (Microsoft.SqlServer.Smo)
ZUSÄTZLICHE INFORMATIONEN:
System.Data.SqlClient.SqlError: RESTORE hat beim Lesen der Daten vom
Sicherungssatz einen Fehler auf der Seite (0:0) in der "Produktiv"-Datenbank
gefunden. (Microsoft.SqlServer.Smo)

In dem 64 Bit System können die Sicherungen ohne Probleme eingespielt
werden.
Was mache ich falsch?
Elmar Boye
2009-06-22 15:21:33 UTC
Permalink
Hallo Thomas,
Post by Thomas Bayer
habe einen 64 Bit SQL Server 2005.
Als Notfallsystem habe ich jetzt ein 32 Bit System in einer Virtuellen
Maschine aufgesetzt.
Gleiches Service Pack und Hotfix Level?
Das muß sichergestellt sein, damit eine Wiederherstellung klappt.

Grundsätzlich empfohlen ist mind. Service Pack 3.
Post by Thomas Bayer
Beim Versuch, eine Datenbank-Sicherung in das Notfallsystem einzulesen,
steht sofort nach der Auswahl der Sicherungsdatei
"*** INCOMPLETE ***" im Namen drin.
Das dürfte vom RESTORE HEADERONLY kommen, das für die
Auswahl aufgerufen wird, und dort bereits erkennt, das
die Datei nicht vollständig/defekt ist.
Post by Thomas Bayer
In dem 64 Bit System können die Sicherungen ohne Probleme eingespielt
werden.
Sind die Dateien vollständig?
Wenn die Dateigröße augenscheinlich stimmt,
auch mal einen Hash ermitteln, ob die Dateien
das Übertragen heile überstanden haben.
Hilfreich dafür z. B.:
http://support.microsoft.com/kb/841290
"Availability and description of the File Checksum Integrity Verifier utility"

Gruß Elmar
Thomas Bayer
2009-06-23 06:28:56 UTC
Permalink
Hallo Elmar, danke für die Infos.
Post by Elmar Boye
Hallo Thomas,
Post by Thomas Bayer
habe einen 64 Bit SQL Server 2005.
Als Notfallsystem habe ich jetzt ein 32 Bit System in einer Virtuellen
Maschine aufgesetzt.
Gleiches Service Pack und Hotfix Level?
Das muß sichergestellt sein, damit eine Wiederherstellung klappt.
Grundsätzlich empfohlen ist mind. Service Pack 3.
Hallo, der Stand ist exakt der gleiche, mit Ausnahme der 32 und 64 Bit
Version:
Microsoft SQL Server 2005 - 9.00.4035.00 (X64) Nov 24 2008 16:17:31
Copyright (c) 1988-2005 Microsoft Corporation Standard Edition (64-bit) on
Windows NT 5.2 (Build 3790: Service Pack 2)
Microsoft SQL Server 2005 - 9.00.4035.00 (Intel X86) Nov 24 2008 13:01:59
Copyright (c) 1988-2005 Microsoft Corporation Standard Edition on Windows
NT 5.2 (Build 3790: Service Pack 2)
Post by Elmar Boye
Post by Thomas Bayer
Beim Versuch, eine Datenbank-Sicherung in das Notfallsystem einzulesen,
steht sofort nach der Auswahl der Sicherungsdatei
"*** INCOMPLETE ***" im Namen drin.
Das dürfte vom RESTORE HEADERONLY kommen, das für die
Auswahl aufgerufen wird, und dort bereits erkennt, das
die Datei nicht vollständig/defekt ist.
Habe ein mal eine gepackte Datei auf dem Backupsystem entpackt und eine
andere ungepackt direkt rübergezogen.
Beide lassen sich auf dem 32 Bit System nicht importieren, aber auf dem 64
Bit System.
Habe dies mit einer weiteren Backup Datei getestet, mit dem gleichen
Ergebnis.
Post by Elmar Boye
Post by Thomas Bayer
In dem 64 Bit System können die Sicherungen ohne Probleme eingespielt
werden.
Hat das 32 Bit System evntl. ein Problem mit dem 64 Bit Backup?
Gruß Thomas!
Elmar Boye
2009-06-23 06:57:16 UTC
Permalink
Hallo Thomas,
Post by Thomas Bayer
Post by Thomas Bayer
habe einen 64 Bit SQL Server 2005.
Habe ein mal eine gepackte Datei auf dem Backupsystem entpackt und eine
andere ungepackt direkt rübergezogen.
Wie gesagt ein Prüfsumme solltest Du ermitteln, um
sicherzustellen, das nicht der "Bock" beim Kopieren entsteht.
Da Du eine VM verwendest, mag da irgendeine Instabilität auftreten.

Erstelle ggf. zuerst eine kleine Testdatenbank (wie Northwind etc.)
und ein neues Backup und verifiziere damit.
Post by Thomas Bayer
Hat das 32 Bit System evntl. ein Problem mit dem 64 Bit Backup?
Normalerweise nicht, die Dateiformate sind unabhängig von der Prozessor
Bit-Breite.
Allerdings erinnere ich mich mal etwas bezüglich unbeabsichtigter
Inkompatibilitäten gelesen zu haben, konnte das gestern trotz
längerer Suche nicht mehr wiederfinden -
nur da mag es sich aber auf die RTM Version bezogen haben,
und solche Probleme dürften bei SP3 behoben sein.

<URL:http://msdn.microsoft.com/de-de/library/ms178062(SQL.90).aspx>
enthält noch einen Hinweis auf Änderungen im MTF Format, was
ggf. bei einem älteren Backup Programm eine Rolle spielen könnte.

Gruß Elmar
Thomas Bayer
2009-06-23 12:07:15 UTC
Permalink
Post by Elmar Boye
Hallo Thomas,
Post by Thomas Bayer
Post by Thomas Bayer
habe einen 64 Bit SQL Server 2005.
Habe ein mal eine gepackte Datei auf dem Backupsystem entpackt und eine
andere ungepackt direkt rübergezogen.
Wie gesagt ein Prüfsumme solltest Du ermitteln, um
sicherzustellen, das nicht der "Bock" beim Kopieren entsteht.
Da Du eine VM verwendest, mag da irgendeine Instabilität auftreten.
Erstelle ggf. zuerst eine kleine Testdatenbank (wie Northwind etc.)
und ein neues Backup und verifiziere damit.
Post by Thomas Bayer
Hat das 32 Bit System evntl. ein Problem mit dem 64 Bit Backup?
Normalerweise nicht, die Dateiformate sind unabhängig von der Prozessor
Bit-Breite.
Allerdings erinnere ich mich mal etwas bezüglich unbeabsichtigter
Inkompatibilitäten gelesen zu haben, konnte das gestern trotz
längerer Suche nicht mehr wiederfinden -
nur da mag es sich aber auf die RTM Version bezogen haben,
und solche Probleme dürften bei SP3 behoben sein.
Hallo Elmar,
nochmals vielen Dank für deine Hilfe!
Ich werde in den nächsten Tagen auf beiden Servern SP3 installieren,
die Daten erneut rüberziehen und die Prüfsumme checken.
Falls es dann noch Probleme geben sollte,
poste ich noch mal.
Schöne Woche noch,
Gruß Thomas!
Elmar Boye
2009-06-23 13:14:10 UTC
Permalink
Hallo Thomas,
Post by Thomas Bayer
Post by Elmar Boye
Post by Thomas Bayer
Hat das 32 Bit System evntl. ein Problem mit dem 64 Bit Backup?
Normalerweise nicht, die Dateiformate sind unabhängig von der Prozessor
Bit-Breite.
nur da mag es sich aber auf die RTM Version bezogen haben,
und solche Probleme dürften bei SP3 behoben sein.
Ich werde in den nächsten Tagen auf beiden Servern SP3 installieren,
Verwirr mich jetzt nicht ;-))

Denn laut Deinen Informationen von heute morgen ist bereits SP3
installiert => Microsoft SQL Server 2005 - 9.00.4035.00

Gruß Elmar
Thomas Bayer
2009-06-24 07:42:09 UTC
Permalink
Post by Elmar Boye
Hallo Thomas,
Post by Thomas Bayer
Post by Elmar Boye
Post by Thomas Bayer
Hat das 32 Bit System evntl. ein Problem mit dem 64 Bit Backup?
Normalerweise nicht, die Dateiformate sind unabhängig von der Prozessor
Bit-Breite.
nur da mag es sich aber auf die RTM Version bezogen haben,
und solche Probleme dürften bei SP3 behoben sein.
Ich werde in den nächsten Tagen auf beiden Servern SP3 installieren,
Verwirr mich jetzt nicht ;-))
Denn laut Deinen Informationen von heute morgen ist bereits SP3
installiert => Microsoft SQL Server 2005 - 9.00.4035.00
Gruß Elmar
Muuuaaaah,
ich hab SP 2 gelesen, aber das bezieht sich ja auf Windows.
Ich wollte gleich den Hash prüfen, habe aber ein Problem mit dem Tool
fciv.exe.
Wenn ich die Option -v auswähle möchte das Programm den -xml Parameter mit
haben.
Main Backup heißt db.bak und mit dem Befehl:
fciv.exe -v -xml db.bak erhalte ich immer die Fehlermeldung:
"Error loading XML document. Unable to open database. Exiting..."
Was muss dort stehen?
Gruß Thomas!
Elmar Boye
2009-06-24 08:50:43 UTC
Permalink
Hallo Thomas,
Post by Thomas Bayer
Ich wollte gleich den Hash prüfen, habe aber ein Problem mit dem Tool
fciv.exe.
Wenn ich die Option -v auswähle möchte das Programm den -xml Parameter mit
haben.
-v dient zum späteren Abgleich, dabei stehen die Daten in einer
XML Datei, die z. B. durch fciv -list erstellt wurde.
Das Format ist unten im KB Artikel beschrieben.
Für eine einzelne Datei kann man die Daten aber direkt ausgeben
lassen und kopieren.
Die kürzeste Variante wäre
fciv -add db.bak
(für md5)
fciv -sha1 -add db.bak
(liefert sha1 Hash - ist etwas größer und zuverlässiger)

Gruß Elmar
Thomas Bayer
2009-06-25 07:36:05 UTC
Permalink
Post by Elmar Boye
Hallo Thomas,
Post by Thomas Bayer
Ich wollte gleich den Hash prüfen, habe aber ein Problem mit dem Tool
fciv.exe.
Wenn ich die Option -v auswähle möchte das Programm den -xml Parameter
mit haben.
-v dient zum späteren Abgleich, dabei stehen die Daten in einer
XML Datei, die z. B. durch fciv -list erstellt wurde.
Das Format ist unten im KB Artikel beschrieben.
Für eine einzelne Datei kann man die Daten aber direkt ausgeben
lassen und kopieren.
Die kürzeste Variante wäre
fciv -add db.bak
(für md5)
fciv -sha1 -add db.bak
(liefert sha1 Hash - ist etwas größer und zuverlässiger)
Vielen Dank!
Gruß Thomas!

Thomas Bayer
2009-06-24 08:45:34 UTC
Permalink
Post by Elmar Boye
Hallo Thomas,
Post by Elmar Boye
Post by Thomas Bayer
Hat das 32 Bit System evntl. ein Problem mit dem 64 Bit Backup?
Normalerweise nicht, die Dateiformate sind unabhängig von der Prozessor
Bit-Breite.
nur da mag es sich aber auf die RTM Version bezogen haben,
und solche Probleme dürften bei SP3 behoben sein.
Hallo Elmar,
hab gerade noch einen Test (zu erst mit einer kleinen, dan mit einer großen
DB) gemacht.
Es hat in beiden Fällen funktioniert.Deine Vermutung war also richtig (ich
hätte bis vorhin noch dagegen gewettet).
Damit ist das Problem erledigt :-)
Recht vielen Dank für die Tips und die Hilfe!!!
Gruß Thomas!
Loading...