6
SQL DBCC Repair repariert nicht?
Hallo zusammen,
bei uns läuft eine große ERP-Datenbank (MS SQL Server Standard auf MS Server Standard 2019) mit der die WaWi arbeitet. Besagte WaWi hat zudem noch ein FiBu-Programm, welches eine Unterdatenbank für das laufende Geschäftsjahr hat.
Die Buchhaltung meldet mir gestern morgen eine Fehlermeldung bei dem Versuch zu Buchen. Es erscheint immer die gleiche Meldung: "SQL Fehler 9105 - Der bereitgestellte Statistikdatenstrom ist beschädigt." Verschiedene andere Vorgänge, die mit dem Buchen zutun haben, scheitern auch in selbiger Meldung.
Daraufhin habe ich Google bemüht und versucht das Problem zu lösen bei der relativ geringen Menge an Lösungsansätzen.
Dabei wurde mir immer wieder DBCC CHECKDB vorgeschlagen und den Reparaturbefehl.
Gesagt - getan: Erst ein CHECKDB gemacht und dabei drei Fehler erhalten.
Daraufhin habe ich den Reparaturbefehl gestartet mit
DBCC CHECKDB ("Datenbankname"), REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS; GO
(REPAIR_ALLOW_DATA_LOSS wurde mir auch als Mindestanforderung zur Reparatur vorgeschlagen vom DBCHECK)
Ergebnis der Reparatur war vielversprechend:
Das Problem ist nur, dass dann beim Gegenprüfen bzw. erneutes Ausführen von nur dem DBCC CHECKDB genau die gleiche Fehlermeldung von Oben wirft. Als hätte der Reparaturbefehl nichts ausgelöst. Das Buchen im FiBu-Programm hat weiterhin nicht funktioniert.
Habt ihr eine Idee? Wäre um jede Hilfe dankbar! PS: Ich bin kein Datenbank-Profi, also bitte lyncht mich nicht :/
bei uns läuft eine große ERP-Datenbank (MS SQL Server Standard auf MS Server Standard 2019) mit der die WaWi arbeitet. Besagte WaWi hat zudem noch ein FiBu-Programm, welches eine Unterdatenbank für das laufende Geschäftsjahr hat.
Die Buchhaltung meldet mir gestern morgen eine Fehlermeldung bei dem Versuch zu Buchen. Es erscheint immer die gleiche Meldung: "SQL Fehler 9105 - Der bereitgestellte Statistikdatenstrom ist beschädigt." Verschiedene andere Vorgänge, die mit dem Buchen zutun haben, scheitern auch in selbiger Meldung.
Daraufhin habe ich Google bemüht und versucht das Problem zu lösen bei der relativ geringen Menge an Lösungsansätzen.
Dabei wurde mir immer wieder DBCC CHECKDB vorgeschlagen und den Reparaturbefehl.
Gesagt - getan: Erst ein CHECKDB gemacht und dabei drei Fehler erhalten.
Meldung 8948, Ebene 16, Status 6, Zeile 1
Datenbankfehler: Die Seite (1:52854) ist auf der PFS-Seite (1:48528) mit dem falschen Typ gekennzeichnet. PFS-Status 0x70, erwartet 0x50.
Meldung 8948, Ebene 16, Status 6, Zeile 1
Datenbankfehler: Die Seite (1:52855) ist auf der PFS-Seite (1:48528) mit dem falschen Typ gekennzeichnet. PFS-Status 0x70, erwartet 0x50.
Meldung 8948, Ebene 16, Status 2, Zeile 1
Datenbankfehler: Die Seite (1:52853) ist auf der PFS-Seite (1:48528) mit dem falschen Typ gekennzeichnet. PFS-Status 0x50, erwartet 0x70.
Service Broker-Meldung 9675, Status 1: Analysierte Nachrichtentypen: 14.
Service Broker-Meldung 9676, Status 1: Analysierte Dienstverträge: 6.
Service Broker-Meldung 9667, Status 1: Analysierte Dienste: 3.
Service Broker-Meldung 9668, Status 1: Analysierte Dienstwarteschlangen: 3.
Service Broker-Meldung 9669, Status 1: Analysierte Konversationsendpunkte: 0.
Service Broker-Meldung 9674, Status 1: Analysierte Konversationsgruppen: 0.
Service Broker-Meldung 9670, Status 1: Analysierte Remotedienstbindungen: 0.
Service Broker-Meldung 9605, Status 1: Analysierte Konversationsprioritäten: 0.
Von CHECKDB wurden 3 Zuordnungsfehler und 0 Konsistenzfehler gefunden, die keinem einzelnen Objekt zugeordnet sind.Daraufhin habe ich den Reparaturbefehl gestartet mit
DBCC CHECKDB ("Datenbankname"), REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS; GO
(REPAIR_ALLOW_DATA_LOSS wurde mir auch als Mindestanforderung zur Reparatur vorgeschlagen vom DBCHECK)
Ergebnis der Reparatur war vielversprechend:
Meldung 8948, Ebene 16, Status 6, Zeile 1
Datenbankfehler: Die Seite (1:52853) ist auf der PFS-Seite (1:48528) mit dem falschen Typ gekennzeichnet. PFS-Status 0x70, erwartet 0x50.
Der Fehler wurde behoben.
Meldung 8948, Ebene 16, Status 2, Zeile 1
Datenbankfehler: Die Seite (1:52854) ist auf der PFS-Seite (1:48528) mit dem falschen Typ gekennzeichnet. PFS-Status 0x50, erwartet 0x70.
Der Fehler wurde behoben.
Meldung 8948, Ebene 16, Status 2, Zeile 1
Datenbankfehler: Die Seite (1:52855) ist auf der PFS-Seite (1:48528) mit dem falschen Typ gekennzeichnet. PFS-Status 0x50, erwartet 0x70.
Der Fehler wurde behoben.
Von CHECKDB wurden 3 Zuordnungsfehler und 0 Konsistenzfehler gefunden, die keinem einzelnen Objekt zugeordnet sind.
CHECKDB hat 3 Zuordnungsfehler und 0 Konsistenzfehler behoben, die keinem einzelnen Objekt zugeordnet waren.
Von CHECKDB wurden 3 Zuordnungsfehler und 0 Konsistenzfehler in der [Datenbankname]-Datenbank gefunden.
Von CHECKDB wurden 3 Zuordnungsfehler und 0 Konsistenzfehler in der [Datenbankname]-Datenbank behoben.Das Problem ist nur, dass dann beim Gegenprüfen bzw. erneutes Ausführen von nur dem DBCC CHECKDB genau die gleiche Fehlermeldung von Oben wirft. Als hätte der Reparaturbefehl nichts ausgelöst. Das Buchen im FiBu-Programm hat weiterhin nicht funktioniert.
Habt ihr eine Idee? Wäre um jede Hilfe dankbar! PS: Ich bin kein Datenbank-Profi, also bitte lyncht mich nicht :/
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 6016759105
Url: https://administrator.de/contentid/6016759105
Printed on: July 27, 2024 at 16:07 o'clock
6 Comments
Latest comment
Moin,
was sagt den der Support von der unbekannten ERP/WaWi dazu?
Gruß
Jasper
was sagt den der Support von der unbekannten ERP/WaWi dazu?
Gruß
Jasper
2
Moin,
Die Software ist die SelectLine WaWi/FiBu und der Support ist nur aktuell ziemlich eingeschränkt verfügbar. Daher hat er mir diesen Lösungsvorschlag geschickt. Bei Ausführend des ersten EXEC kriege ich eine Menge Informationen zurück, aber keine Info mit Fehler. Daher kann ich den Lösungsvorschlag nicht weiter ausführen.
Es wird auch gesagt, dass es mit der Festplatte zutun haben kann (steht in manchen Antworten auch drin). Ein Austauschserver steht auch schon in den Startlöchern, jedoch würde ich die ganze DB mit selbigen Fehler ja übertragen, daher versuche ich den Fehler vorab zu lösen.
Die Software ist die SelectLine WaWi/FiBu und der Support ist nur aktuell ziemlich eingeschränkt verfügbar. Daher hat er mir diesen Lösungsvorschlag geschickt. Bei Ausführend des ersten EXEC kriege ich eine Menge Informationen zurück, aber keine Info mit Fehler. Daher kann ich den Lösungsvorschlag nicht weiter ausführen.
Es wird auch gesagt, dass es mit der Festplatte zutun haben kann (steht in manchen Antworten auch drin). Ein Austauschserver steht auch schon in den Startlöchern, jedoch würde ich die ganze DB mit selbigen Fehler ja übertragen, daher versuche ich den Fehler vorab zu lösen.
Moin,
was bedeutet Festplatte? Ist das ne baremetal Installation?
Wie schaut denn Storage Unterbau aus?
Gruß
Spirit
was bedeutet Festplatte? Ist das ne baremetal Installation?
Wie schaut denn Storage Unterbau aus?
Gruß
Spirit
Ideen nach Reihenfolge:
#1: Support des Herstellers wie bereits von @JasperBeardley
#2: Restore aus der Datensicherung
Seit wann tritt der Fehler auf? Du kannst den Server zumindest mal parallel aus der Datensicherung holen und dir dort das Verhalten genau anschauen.
#3: Jemanden fragen der sich damit auskennt, Dienstleister / Systemhaus / Betreuer
#4: Selbst frickeln, aber was dann heile bleibt weis man nicht so genau
Ich würde jedenfalls nicht einfach irgendwas mit REPAIR_ALLOW_DATA_LOSS absetzen, wer mal chkdsk blind vertraut hat weiß das dass nicht gut ausgehen kann.
#1: Support des Herstellers wie bereits von @JasperBeardley
#2: Restore aus der Datensicherung
Seit wann tritt der Fehler auf? Du kannst den Server zumindest mal parallel aus der Datensicherung holen und dir dort das Verhalten genau anschauen.
#3: Jemanden fragen der sich damit auskennt, Dienstleister / Systemhaus / Betreuer
#4: Selbst frickeln, aber was dann heile bleibt weis man nicht so genau
Ich würde jedenfalls nicht einfach irgendwas mit REPAIR_ALLOW_DATA_LOSS absetzen, wer mal chkdsk blind vertraut hat weiß das dass nicht gut ausgehen kann.2
Moin,
ich hoffe du hast vor deiner aktion eine datensicherung gemacht (und hast überhaubt eine)!
ist dir klar, was die option REPAIR_ALLOW_DATA_LOSS macht? bei speicheroptimierte Tabellen funktioniert das nicht!
mit viel glück, ist die reperatur geglückt, aber du hast Datenverlust!
wie ist deine DB aufgebaut? was für ein ERP?
Support der ERP lösung anzurufen, und die Datensicherung vom vortag aus dem spind zu holen.....
Frank
ich hoffe du hast vor deiner aktion eine datensicherung gemacht (und hast überhaubt eine)!
ist dir klar, was die option REPAIR_ALLOW_DATA_LOSS macht? bei speicheroptimierte Tabellen funktioniert das nicht!
mit viel glück, ist die reperatur geglückt, aber du hast Datenverlust!
wie ist deine DB aufgebaut? was für ein ERP?
PS: Ich bin kein Datenbank-Profi, also bitte lyncht mich nicht :/
ok... weil heute Freitag ist, gibbet nur nen tritt in den allerwertesten- dein erster und bester weg, wäre gewesen - denSupport der ERP lösung anzurufen, und die Datensicherung vom vortag aus dem spind zu holen.....
Frank
Moin,
die Hinweise zu Support und Datensicherung hast Du ja schon erhalten, deswegen gehe ich nicht auch noch darauf ein.
Für eine Reparatur muß Deine Datenbank im Einzelbenutzermodus sein. Den stellst Du entweder im Managementstudio bei den Datenbankeigenschaften unter Optionen ein, unter "Zugriff beschränken" oder aber per Befehl im selben Fenster, in dem Du den Reparaturbefehl startest:
Das Gegenstück dazu, das Du nach der Reparatur ausführen mußt, damit mehr als einer die DB nutzen können, heißt:
Nach der Reparatur solltest Du auch nochmal Deine Constraints prüfen:
Gruß und schönes Wochenende, Mad Max
die Hinweise zu Support und Datensicherung hast Du ja schon erhalten, deswegen gehe ich nicht auch noch darauf ein.
Für eine Reparatur muß Deine Datenbank im Einzelbenutzermodus sein. Den stellst Du entweder im Managementstudio bei den Datenbankeigenschaften unter Optionen ein, unter "Zugriff beschränken" oder aber per Befehl im selben Fenster, in dem Du den Reparaturbefehl startest:
alter database [XYZ] set single_userDas Gegenstück dazu, das Du nach der Reparatur ausführen mußt, damit mehr als einer die DB nutzen können, heißt:
alter database [XYZ] set multi_userNach der Reparatur solltest Du auch nochmal Deine Constraints prüfen:
dbcc checkconstraintsGruß und schönes Wochenende, Mad Max
2