64
Defekte SQL-Datenbank reparieren
Hallo,
wir nutzen einen Microsoft SQL-Server 14.0.2052.1.
Dort gibt es 2 aktive Datenbanken.
Nachdem ich eine der beiden Datenbanken manuall sichern wollte, bevor ich ein Update für die entsprechende Software installiere, brach die Sicherung immer wieder bei 70% ab.
Wir haben einen IT-Dienstleister, dem aber bis dahin auch noch nicht aufgefallen war, dass auch die tägliche Sicherung dieser Datenbank über eine Backup-Software schon seit längerer Zeit nicht mehr funktioniert hatte. OK... das ist jedoch jetzt nicht das Hauptthema
Jedenfalls wurden schon sämtliche Methoden ausprobiert, die offensichtlich defekte SQL-Datenbank zu reparieren.
Bisher leider ohne Erfolg.
Auch das Klonen des entspr. virtuellen Servers (auf dem die DB liegt) funktioniert nicht und bricht ab... offenbar ebenfalls aufgrund der defekten Datenbank.
Unser IT-Dienstleister hat nun schon den Microsoft-Support zur Hilfe genommen und mit deren Hilfe verschiedene Reparaturversuche für die SQL-Datenbank durchgeführt.
Wenn ich dann mal wieder eine Email erhalte mit "versuchen Sie jetzt nochmal, die entspr. Datenbank zu sichern", geht es bisher immer so aus, dass diese Sicherung bei 70% abbricht. Das war auch gestern wieder so.
Offenbar sind unser IT-Dienstleister... aber wohl auch der Microsoft-Support... derzeit mit ihrem Latein am Ende.
Daher dachte ich, dass ich diesen Thread mal hier reinstelle, in der Hoffnung, dass vielleicht jemand von Euch noch eine Idee hat, was man machen könnte.
Das Problem ist, dass die letzte Sicherung, die funktioniert hat, von Anfang 2024 ist... und das könnte u.U. katastrophal sein.
Grüße von
Yan
wir nutzen einen Microsoft SQL-Server 14.0.2052.1.
Dort gibt es 2 aktive Datenbanken.
Nachdem ich eine der beiden Datenbanken manuall sichern wollte, bevor ich ein Update für die entsprechende Software installiere, brach die Sicherung immer wieder bei 70% ab.
Wir haben einen IT-Dienstleister, dem aber bis dahin auch noch nicht aufgefallen war, dass auch die tägliche Sicherung dieser Datenbank über eine Backup-Software schon seit längerer Zeit nicht mehr funktioniert hatte. OK... das ist jedoch jetzt nicht das Hauptthema
Jedenfalls wurden schon sämtliche Methoden ausprobiert, die offensichtlich defekte SQL-Datenbank zu reparieren.
Bisher leider ohne Erfolg.
Auch das Klonen des entspr. virtuellen Servers (auf dem die DB liegt) funktioniert nicht und bricht ab... offenbar ebenfalls aufgrund der defekten Datenbank.
Unser IT-Dienstleister hat nun schon den Microsoft-Support zur Hilfe genommen und mit deren Hilfe verschiedene Reparaturversuche für die SQL-Datenbank durchgeführt.
Wenn ich dann mal wieder eine Email erhalte mit "versuchen Sie jetzt nochmal, die entspr. Datenbank zu sichern", geht es bisher immer so aus, dass diese Sicherung bei 70% abbricht. Das war auch gestern wieder so.
Offenbar sind unser IT-Dienstleister... aber wohl auch der Microsoft-Support... derzeit mit ihrem Latein am Ende.
Daher dachte ich, dass ich diesen Thread mal hier reinstelle, in der Hoffnung, dass vielleicht jemand von Euch noch eine Idee hat, was man machen könnte.
Das Problem ist, dass die letzte Sicherung, die funktioniert hat, von Anfang 2024 ist... und das könnte u.U. katastrophal sein.
Grüße von
Yan
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: 82382636888
Url: https://administrator.de/contentid/82382636888
Printed on: July 27, 2024 at 12:07 o'clock
64 Comments
Latest comment
Kannst du denn auf die Datenbank noch zugreifen? Also zumindest auf bestimmte Inhalte? Du sagst nur das Backup geht nicht und die VM lässt sich nicht Klonen (online?), was eigentlich gar nicht sein kann. Eine defekte Datei kann ich ja auch immer kopieren, macht sie nur nicht heile. Sollte aber natürlich unbedingt VORHER passierten, um nicht am lebenden Patienten zu operieren.
Hallo, was ist mit der Software die die nutzt?
Wie Komplext ist die DB? Hersteller der Software noch verfügbar?
Du kannst auch alles via T-SQL in eine neue DB kopieren. Ist aber nur der Inhalt. Trigger, Views etc. vorhanden? Tabellen Rationen bekannt?
Wenn die Relationen einfach nachzuvollziehen sind und einige Tabellen sogar für sich allein stehen können, dann könnte es mit T-SQL eine Option sein.
Wobei man auch Views, Trigger exportieren und nachbauen kann.
SQL Server ist für Entwickler kostenlos. Man könnte die DB mal in eine gleiche SQL Standard Version hängen oder in eine neuere SQL Version.
Wird wirklich beim Backup abgebrochen oder sind das verbundene Task für Index Neuaufbau u.ä.?
MS zu fragen ist so eine Sache. Was läuft auf der DB? Im Zweifel kann der Author der SQL Snippets bzw. Software, die die DB nutzt, mehr sagen!
Je nach Umfang kann man auch Backup durch einfaches Kopieren von A nach B erzielen. Dazu muss man die DB kennen! Besonders wie gesagt Trigger, Views und Stored Procedures.
Erst dann kann man sagen wie groß der Schaden ist und was genau betroffen ist.
Es gibt auch Authoren die Temp Tabellen anlegen. Oder Tabellen, deren Inhalt diurch Prozeduren oder Programme von Extern wieder gefüllt werden kann.
Hängt von so vielen Dingen ab.
Wichtig ist ggf. dann erstmal mit den Programmieren zu sprechen. Oder erstmal zu klären, was da überhaupt drauf läuft!
Wie Komplext ist die DB? Hersteller der Software noch verfügbar?
Du kannst auch alles via T-SQL in eine neue DB kopieren. Ist aber nur der Inhalt. Trigger, Views etc. vorhanden? Tabellen Rationen bekannt?
Wenn die Relationen einfach nachzuvollziehen sind und einige Tabellen sogar für sich allein stehen können, dann könnte es mit T-SQL eine Option sein.
Wobei man auch Views, Trigger exportieren und nachbauen kann.
SQL Server ist für Entwickler kostenlos. Man könnte die DB mal in eine gleiche SQL Standard Version hängen oder in eine neuere SQL Version.
Wird wirklich beim Backup abgebrochen oder sind das verbundene Task für Index Neuaufbau u.ä.?
MS zu fragen ist so eine Sache. Was läuft auf der DB? Im Zweifel kann der Author der SQL Snippets bzw. Software, die die DB nutzt, mehr sagen!
Je nach Umfang kann man auch Backup durch einfaches Kopieren von A nach B erzielen. Dazu muss man die DB kennen! Besonders wie gesagt Trigger, Views und Stored Procedures.
Erst dann kann man sagen wie groß der Schaden ist und was genau betroffen ist.
Es gibt auch Authoren die Temp Tabellen anlegen. Oder Tabellen, deren Inhalt diurch Prozeduren oder Programme von Extern wieder gefüllt werden kann.
Hängt von so vielen Dingen ab.
Wichtig ist ggf. dann erstmal mit den Programmieren zu sprechen. Oder erstmal zu klären, was da überhaupt drauf läuft!
Backup....
wie genau macht ihr das Backup, per software oder per SQL Server Task oder hast schon mal manuellen dump gemacht?
Per SQL Command:
Datenbankname anpassen und pfad nach belieben.
Und die entscheidenede Frage was für einen Fehler wirft der Server den, Eventlog, SQL Server Log oder sonst wo muss ja im Detail was stehen was sein problem ist.
Das herausfinden und hier posten oder googeln.
und ne andere Frage - läuft die Datenbank so wie sie ist aktuell noch?
dann wie sind die settings z.b. fürs datenbank fiule und log file der datenbank.
eventuell ist das log file begrenzt von der grösse und kann nicht auf die grösse anschwellen was es eigentlich braucht.
wie genau macht ihr das Backup, per software oder per SQL Server Task oder hast schon mal manuellen dump gemacht?
Per SQL Command:
BACKUP DATABASE datenbankname TO DISK='c:\datenbank.bak' Datenbankname anpassen und pfad nach belieben.
Und die entscheidenede Frage was für einen Fehler wirft der Server den, Eventlog, SQL Server Log oder sonst wo muss ja im Detail was stehen was sein problem ist.
Das herausfinden und hier posten oder googeln.
und ne andere Frage - läuft die Datenbank so wie sie ist aktuell noch?
dann wie sind die settings z.b. fürs datenbank fiule und log file der datenbank.
eventuell ist das log file begrenzt von der grösse und kann nicht auf die grösse anschwellen was es eigentlich braucht.
Sollte noch Zugriff auf die DB bestehen, würde ich ein gleichwertiges System aufbauen und dann anfangen, jede Db, Tabelle, Trigger und Functions einzeln von der alten auf die neue DB zu synchronisieren. Tools wie Navicat for SQL Server können das auch automatisiert. Erstens kann man damit den defekten Teil recht einfach finden und zweites weiß man dann, welche Daten verloren sind und welche nicht.
Das hört sich eher nach einem Defekt der gesamten VM an, als ein Fehler der Datenbank. Das Klonen sollte unabhängig von der DB funktionieren.
Gruß
max
Auch das Klonen des entspr. virtuellen Servers (auf dem die DB liegt) funktioniert nicht und bricht ab.
Das hört sich eher nach einem Defekt der gesamten VM an, als ein Fehler der Datenbank. Das Klonen sollte unabhängig von der DB funktionieren.
Gruß
max
1
Erstmal posten ob auf die DB noch zugegriffen werden kann und ob z.B. der Datenbank-Dienst schon mal angehalten und neu gestartet wurde. Wenn das mit Sicherheit geht, kann man den Dienst anhalten und die mdb und ldf weg sichern und mit dem Klon spielen.
Wenn du nicht weißt, ob die Datenbank wieder startet, aktuell aber Zugriff möglich ist, dann würde ich alles händisch klonen, meist sind diese Datenbanken nicht so wahnsinnig komplex. Oder mal mit dem Hersteller der Software brain stormen.
Wenn du nicht weißt, ob die Datenbank wieder startet, aktuell aber Zugriff möglich ist, dann würde ich alles händisch klonen, meist sind diese Datenbanken nicht so wahnsinnig komplex. Oder mal mit dem Hersteller der Software brain stormen.
Puuuuuuuuh, da hab ich ja was losgetreten
Seid mir nicht böse, aber die meisten Fragen (vor allem die sehr spezifischen von @Crusher79) kann ich selbst überhaupt nicht beantworten. Aber ich versuche mal, all die zu beantworten, die ich kann...
Es gibt ja 2 Datenbanken auf diesem SQL-Server.
Man kann mit beiden Programmen arbeiten und es gibt dort auch keine Probleme.
Eine der beiden Datenbanken kann ich auch manuell sichern. Das funktioniert einwandfrei. Das mache ich direkt über das "MS SQL Server Management Studio".
Warum das Klonen dieses virt. Servers nicht funktioniert, kann ich so nicht sagen. Hat mich aber auch gewundert. Hier bekomme ich halt nur die Infos per Email od. Telefon durch unseren IT-Dienstleister.
Der Hersteller der Software, dessen DB nicht gesichert werden kann, war schon in das Procedere eingebunden. Auch die konnten wohl bisher nicht helfen.
Solche Dinge, wie z.B. "via T-SQL in eine neue DB kopieren..." etc. könnte ich selbst nicht durchführen, da ich mich mit SQL-Servern od. -Datenbanken so gut wie nicht auskenne.
Ich werde gleich den Vorschlag von @ThePinky777 mal testen. Also das
...natürlich mit den passenden Einträgen.
Hier mal die übliche Fehlermeldung, die bei der Sicherung der DB auftritt:
Mein eher persönliches Problem:
Vielleicht könnt Ihr verstehen, dass mein pers. Problem im Moment natürlich ist, dass wir ja einen IT-Dienstleister haben, den wir natürlich auch bezahlen (Wartungs-/Servicevertrag).
Da wir aber nicht weiterkommen, war mir heute Morgen eingefallen, einfach mal hier im Forum nachzufragen.
Da ich die meisten Fragen ja nun nicht beantworten kann, müsste ich diese ja eigentlich an den IT-Dienstleister weitergeben... Das ist ja irgendwie auch ein bisschen peinlich (für den, aber für mich auch ein bisschen).
Wie seht Ihr das und wie würdet Ihr da jetzt vorgehen?
Grüße von
Yan
Seid mir nicht böse, aber die meisten Fragen (vor allem die sehr spezifischen von @Crusher79) kann ich selbst überhaupt nicht beantworten. Aber ich versuche mal, all die zu beantworten, die ich kann...
Es gibt ja 2 Datenbanken auf diesem SQL-Server.
Man kann mit beiden Programmen arbeiten und es gibt dort auch keine Probleme.
Eine der beiden Datenbanken kann ich auch manuell sichern. Das funktioniert einwandfrei. Das mache ich direkt über das "MS SQL Server Management Studio".
Warum das Klonen dieses virt. Servers nicht funktioniert, kann ich so nicht sagen. Hat mich aber auch gewundert. Hier bekomme ich halt nur die Infos per Email od. Telefon durch unseren IT-Dienstleister.
Der Hersteller der Software, dessen DB nicht gesichert werden kann, war schon in das Procedere eingebunden. Auch die konnten wohl bisher nicht helfen.
Solche Dinge, wie z.B. "via T-SQL in eine neue DB kopieren..." etc. könnte ich selbst nicht durchführen, da ich mich mit SQL-Servern od. -Datenbanken so gut wie nicht auskenne.
Ich werde gleich den Vorschlag von @ThePinky777 mal testen. Also das
BACKUP DATABASE datenbankname TO DISK='c:\datenbank.bak' ...natürlich mit den passenden Einträgen.
Hier mal die übliche Fehlermeldung, die bei der Sicherung der DB auftritt:
Mein eher persönliches Problem:
Vielleicht könnt Ihr verstehen, dass mein pers. Problem im Moment natürlich ist, dass wir ja einen IT-Dienstleister haben, den wir natürlich auch bezahlen (Wartungs-/Servicevertrag).
Da wir aber nicht weiterkommen, war mir heute Morgen eingefallen, einfach mal hier im Forum nachzufragen.
Da ich die meisten Fragen ja nun nicht beantworten kann, müsste ich diese ja eigentlich an den IT-Dienstleister weitergeben... Das ist ja irgendwie auch ein bisschen peinlich (für den, aber für mich auch ein bisschen).
Wie seht Ihr das und wie würdet Ihr da jetzt vorgehen?
Grüße von
Yan
Zitat von @Yan2021:
Mein eher persönliches Problem:
Vielleicht könnt Ihr verstehen, dass mein pers. Problem im Moment natürlich ist, dass wir ja einen IT-Dienstleister haben, den wir natürlich auch bezahlen (Wartungs-/Servicevertrag).
Da wir aber nicht weiterkommen, war mir heute Morgen eingefallen, einfach mal hier im Forum nachzufragen.
Da ich die meisten Fragen ja nun nicht beantworten kann, müsste ich diese ja eigentlich an den IT-Dienstleister weitergeben... Das ist ja irgendwie auch ein bisschen peinlich (für den, aber für mich auch ein bisschen).
Wie seht Ihr das und wie würdet Ihr da jetzt vorgehen?
Grüße von
Yan
Mein eher persönliches Problem:
Vielleicht könnt Ihr verstehen, dass mein pers. Problem im Moment natürlich ist, dass wir ja einen IT-Dienstleister haben, den wir natürlich auch bezahlen (Wartungs-/Servicevertrag).
Da wir aber nicht weiterkommen, war mir heute Morgen eingefallen, einfach mal hier im Forum nachzufragen.
Da ich die meisten Fragen ja nun nicht beantworten kann, müsste ich diese ja eigentlich an den IT-Dienstleister weitergeben... Das ist ja irgendwie auch ein bisschen peinlich (für den, aber für mich auch ein bisschen).
Wie seht Ihr das und wie würdet Ihr da jetzt vorgehen?
Grüße von
Yan
Moin,
ich sehe es eigentlich ganz unkritisch. Ja klar man bezahlt einen IT Dienstleister damit dieser einen unterstützt. Aber auch das sind am Ende nur Menschen, die sich nicht mit allen Problemen auskennen.
Jedoch sollte man sich als Dienstleister schon irgendwo wissen wie man sich weiterhilft durch andere Personen etc.
Denke mal du solltest deinem Dienstleister die Fragen zukommen lassen. Kann dieser als eine Art Weiterbildung sehen ;)
Letzten Endes soll das Problem gelöst werden und wie ist nicht so entscheidend. Meiner ist auch nicht allwissend, jedoch arbeiten wir dann zusammen an einer Lösung und weiter gehts...
Gruß,
DGI
Hier das Ergebnis der Abfrage über SQL-Command:
Ist ebenso gescheitert. Könnte in diesem Fall aber auch daran liegen, dass MA gerade im Programm arbeiten.
Grüße von
Yan
Ist ebenso gescheitert. Könnte in diesem Fall aber auch daran liegen, dass MA gerade im Programm arbeiten.
Grüße von
Yan
Wie seht Ihr das und wie würdet Ihr da jetzt vorgehen?
Wurde der Server schon mal erfolgreich neu gestartet in der Zeit, wo die DB den CRC Fehler gemacht hat?
Wenn ja: Anwender aus der Anwendung raus, Datenbank-Dienst anhalten, mdf + ldf Datei kopieren, Server neu starten, Zugriff testen.
(Wenn nein bitte nicht weiter machen ohne vorher das Risiko zu bewerten!)
Wenn das klappt kannst du mit den kopierten Dateien testen. Dazu eine VM mit SQL Express (ruhig auch die neueste Version) aufsetzen und die Kopie der mdf im SQL Management Studio dort "anhängen". Dann als erstes mal testen ob sich die Datenbank dort sichern lässt.
...jetzt sind alle MA aus dem Programm ausgestiegen.
Aber die Fehlermeldung bleibt die Gleiche. Hat also nicht funktioniert.
Grüße von
Yan
Aber die Fehlermeldung bleibt die Gleiche. Hat also nicht funktioniert.
Grüße von
Yan
Ja, der Server wurde durch den IT-Dienstleister schon neugestartet. Das war so ziemlich das Erste, was getan wurde.
DB-Dienst anhalten und die mdf + ldf Datei kopieren wurde ganz am Anfang schon gemacht, soweit ich mich erinnere (die Problemsuche läuft schon seit Wochen...).
Ich kann das aber nochmal testen. Wie halte ich den DB-Dienst an?
Und wie kopiere ich die beiden Dateien dann?
Grüße von,
Yan
DB-Dienst anhalten und die mdf + ldf Datei kopieren wurde ganz am Anfang schon gemacht, soweit ich mich erinnere (die Problemsuche läuft schon seit Wochen...).
Ich kann das aber nochmal testen. Wie halte ich den DB-Dienst an?
Und wie kopiere ich die beiden Dateien dann?
Grüße von,
Yan
Hallo
Da die Datenbank sonst noch normal funktioniert und der CRC Fehler nur beim Backup auftritt tippe ich auf defekte Sektoren auf der Platte in einem sonst ungenutzten Datenbereich.
Ich würde so wie oben schon mehrfach erwähnt schnellstens die Tabellen, Trigger, Views, Stored Procedures, usw. manuell in eine neue DB übernehmen.
Denn ich vermute, dass das Problem noch größer werden wird wenn es sich wirklich um defekte Sektoren handelt.
Tom
Da die Datenbank sonst noch normal funktioniert und der CRC Fehler nur beim Backup auftritt tippe ich auf defekte Sektoren auf der Platte in einem sonst ungenutzten Datenbereich.
Ich würde so wie oben schon mehrfach erwähnt schnellstens die Tabellen, Trigger, Views, Stored Procedures, usw. manuell in eine neue DB übernehmen.
Denn ich vermute, dass das Problem noch größer werden wird wenn es sich wirklich um defekte Sektoren handelt.
Tom
2
...ich nehme an, dass mit "DB-Dienst anhalten" entspr. Dienste gemeint sind, die beendet werden müssen.
Welche denn von denen hier?
Grüße von
Yan
Welche denn von denen hier?
Grüße von
Yan
Einfach alle SQL Dienste. Theoretisch reicht auch die (MSSQLSERVER) Instanz oder SFIRM, je nachdem, was kaputt ist.
Die kopierte mdf/ldf in einem ansonsten neu installierten Server einhängen sollte gehen. Wenn die Datei dann wirklich noch eine Macke hat, müsste ja auch hier das Backup scheitern. Wenn das Backup gehen sollte dann könnte man sich das mit Tabellen und Triggern sparen.
Die kopierte mdf/ldf in einem ansonsten neu installierten Server einhängen sollte gehen. Wenn die Datei dann wirklich noch eine Macke hat, müsste ja auch hier das Backup scheitern. Wenn das Backup gehen sollte dann könnte man sich das mit Tabellen und Triggern sparen.
OK und danke.
Wenn ich die SQL Server-Instanz (ich vermute der im obigen Screenshot markierte Eintrag) anhalte, dann ist ja auch die zweite DB nicht mehr nutzbar... richtig?
Dann müsste ich die entspr. Kollegen dann auch zuvor bitten, aus dem entspr. Programm auszusteigen.
Und... wie genau kopiere ich dann die mdf + ldf Datei?
Geht das in SQL über "Tasks >> Datenbank kopieren"?
Grüße von
Yan
Wenn ich die SQL Server-Instanz (ich vermute der im obigen Screenshot markierte Eintrag) anhalte, dann ist ja auch die zweite DB nicht mehr nutzbar... richtig?
Dann müsste ich die entspr. Kollegen dann auch zuvor bitten, aus dem entspr. Programm auszusteigen.
Und... wie genau kopiere ich dann die mdf + ldf Datei?
Geht das in SQL über "Tasks >> Datenbank kopieren"?
Grüße von
Yan
Instanz hält alles an was darunter läuft.
MDF und LDF kann man normal wie DOC oder andere Dateien kopieren und auf neuen System einhängen.
Ohne laufende Instanz sind SQL Werkzeuge still gelegt. Explorer.
MDF und LDF kann man normal wie DOC oder andere Dateien kopieren und auf neuen System einhängen.
Ohne laufende Instanz sind SQL Werkzeuge still gelegt. Explorer.
Die andere Instanz müsste weiter laufen. Aber schaden wird es nicht, muss ja nicht sofort gemacht werden. mdf und lfd liegen auf dem Dateisystem, wo kannst du vorher im Management Studio nachgucken.
Wenn man die umebennnen kann, ist die Instanz unten.
Um sie mit den "kaputten" Server oder auch später wieder zu verwenden, muss man den Namen zurück ändern.
Sonst muss man den explzit beim verbinden in den erweiterten Eigeschaft ggf. korrigieren.
Munter ein "x" davor geschrieben und nix hält die DB momentan fest....
Um sie mit den "kaputten" Server oder auch später wieder zu verwenden, muss man den Namen zurück ändern.
Sonst muss man den explzit beim verbinden in den erweiterten Eigeschaft ggf. korrigieren.
Munter ein "x" davor geschrieben und nix hält die DB momentan fest....
Hmmm... habe es jetzt versucht.
Die im obigen Screenshot markierte Instanz (wenn es denn die Instanz ist) angehalten.
Die darunter sind somit wohl autom. angehalten.
Dann habe ich den Speicherplatz der mdf-Datei ermittelt.
Dann wollte ich die mdf-Datei kopieren, aber erhalte dann die folgende Fehlermeldung, die ich überhaupt nicht verstehe:
Das MS SQL-Management Studio ist definitiv geschlossen.
Und... eine "ldf"-Datei gibt es von der Problem-DB garnicht...
Grüße von
Yan
Die im obigen Screenshot markierte Instanz (wenn es denn die Instanz ist) angehalten.
Die darunter sind somit wohl autom. angehalten.
Dann habe ich den Speicherplatz der mdf-Datei ermittelt.
Dann wollte ich die mdf-Datei kopieren, aber erhalte dann die folgende Fehlermeldung, die ich überhaupt nicht verstehe:
Das MS SQL-Management Studio ist definitiv geschlossen.
Und... eine "ldf"-Datei gibt es von der Problem-DB garnicht...
Grüße von
Yan
Hast du denn schon mal die Platte oder SSD auf Schreib/Lesefehler überprüft? Sieht für mich eher nach einem Hardware defekt der Platte/SSD aus als ein DB Problem (das ist nur die Auswirkung des Defekts).
Das steht letztendlich auch in der Fehlermeldung: "Fehler beim Lesen auf …". Das würde gleichzeitig das Problem mit dem Klonen der VM erklären.
Das steht letztendlich auch in der Fehlermeldung: "Fehler beim Lesen auf …". Das würde gleichzeitig das Problem mit dem Klonen der VM erklären.
...ok und danke für den Tipp.
Werde das mal weitergeben an unseren IT-Dienstleister... ob der darauf auch schon gekommen ist
Grüße von
Yan
Werde das mal weitergeben an unseren IT-Dienstleister... ob der darauf auch schon gekommen ist
Grüße von
Yan
Hallo Yan,
mich wundert gerade ein bisschen, daß beim Stichwort "Defekte Datenbank" noch keiner den Befehl dbcc erwähnt hat. Damit kann man eine Datenbank prüfen und auch reparieren, je nach Schweregrad mit oder ohne Datenverlust.
Um die Datenbank zu prüfen gib mal im Management Studio "dbcc checkdb" ein, das prüft Deine Datenbank auf Schäden hin.
Um die Datenbank zu reparieren gibt es die Befehle
dbcc checkdb (<Datenbank>, repair_rebuild)
und
dbcc checkdb (<Datenbank>, repair_allow_data_loss)
repair_rebuild funktioniert ohne Datenverlust, repair_allow_data_loss kann Datenverlust nach sich ziehen. Ich vermute mal, ohne Datenverlust wirst Du nicht rauskommen.
Vor der DB-Reparatur mußt Du die DB auf Einzelbenutzermodus setzen, wie das geht, kannst Du da nachlesen: SQL DBCC Repair repariert nicht?
Gruß, Mad Max
mich wundert gerade ein bisschen, daß beim Stichwort "Defekte Datenbank" noch keiner den Befehl dbcc erwähnt hat. Damit kann man eine Datenbank prüfen und auch reparieren, je nach Schweregrad mit oder ohne Datenverlust.
Um die Datenbank zu prüfen gib mal im Management Studio "dbcc checkdb" ein, das prüft Deine Datenbank auf Schäden hin.
Um die Datenbank zu reparieren gibt es die Befehle
dbcc checkdb (<Datenbank>, repair_rebuild)
und
dbcc checkdb (<Datenbank>, repair_allow_data_loss)
repair_rebuild funktioniert ohne Datenverlust, repair_allow_data_loss kann Datenverlust nach sich ziehen. Ich vermute mal, ohne Datenverlust wirst Du nicht rauskommen.
Vor der DB-Reparatur mußt Du die DB auf Einzelbenutzermodus setzen, wie das geht, kannst Du da nachlesen: SQL DBCC Repair repariert nicht?
Gruß, Mad Max
Und noch ein Nachtrag zur Sicherung der Datenbank:
Wenn ich davon ausgehe, daß Ihr das Wiederherstellungsmodell "Vollständig" eingestellt habt, dann solltet Ihr auch das Transaktionsprotokoll regelmäßig sichern. Du kannst dann nochmal das letzte Transaktionslog sichern, damit Du den letzten Stand von der Datenbank hast, und dann mit der Datenbanksicherung vom Januar und allen Transaktionslogs danach die Datenbank wiederherstellen.
Das wäre dann sogar ohne Datenverlust.
Gruß, Mad Max
Wenn ich davon ausgehe, daß Ihr das Wiederherstellungsmodell "Vollständig" eingestellt habt, dann solltet Ihr auch das Transaktionsprotokoll regelmäßig sichern. Du kannst dann nochmal das letzte Transaktionslog sichern, damit Du den letzten Stand von der Datenbank hast, und dann mit der Datenbanksicherung vom Januar und allen Transaktionslogs danach die Datenbank wiederherstellen.
Das wäre dann sogar ohne Datenverlust.
Gruß, Mad Max
Wie funktioniert denn deine Software? Denn wenn es (was ich mal vermute) ne Client/Server-Software ist dann sollte die Anwendung auf den Clients ja nicht zwingend direkt auf die DB gehen... Daher würde ich mal _ALLE_ Software beenden (also alle Clients und auch den Serverteil der Software) und die Sicherung dann versuchen. Es kann ja durchaus sein das die im Hintergrund irgendwelche Aktionen macht und du damit Datenbestände hast die sich permanent ändern...
Wobei ich bei der Fehlermeldung auch eher auf nen Hardware-Problem bei den Festplatten tippen würde -> aber wäre ja auch nich die erste Software die Fehlermeldungen wirft die einfach mal völlig sinnlos sind...
Wobei ich bei der Fehlermeldung auch eher auf nen Hardware-Problem bei den Festplatten tippen würde -> aber wäre ja auch nich die erste Software die Fehlermeldungen wirft die einfach mal völlig sinnlos sind...
Moin,
Mein Gedanke beim Lesen des Ausgangspost war im übrigen: „da wird die Festplatte ein Prblem haben“ das bitte unbedingt checken.
Zitat von @Yan2021:
Dann wollte ich die mdf-Datei kopieren, aber erhalte dann die folgende Fehlermeldung, die ich überhaupt nicht verstehe:
Das MS SQL-Management Studio ist definitiv geschlossen.
Das studio ist nur eine GUI zum verwalten. Du musst die SQL-Dienste beenden (findest du unter Dienste)Dann wollte ich die mdf-Datei kopieren, aber erhalte dann die folgende Fehlermeldung, die ich überhaupt nicht verstehe:
Das MS SQL-Management Studio ist definitiv geschlossen.
Und... eine "ldf"-Datei gibt es von der Problem-DB garnicht...
Mein Gedanke beim Lesen des Ausgangspost war im übrigen: „da wird die Festplatte ein Prblem haben“ das bitte unbedingt checken.
Ich bin immer erst für eine Kopie der Dateien. Danach kann man alles versuchen, je nach Server Hardware würde ich eventuell die Hardware + OS + DB Installation komplett neu machen und mich gar nicht mit dem alten ### belasten. Zumindest nicht um eine DB Sicherung zu testen oder die DB zu prüfen.
Die Datei wird nicht als unlesbar gemeldet sondern als geöffnet. Sogar als geöffnet durch "SQL Server (MSSQLSERVER)". Das kann nur ein SQL Dienst sein, auch eine Serveranwendung / Dienst greift nicht direkt auf die mdf zu. MSSQL ist schließlich ein DBMS und nicht nur eine DB.
Zur Not alle Dienste mit SQL auf Deaktiviert setzen und neu starten. Im Anschluss sollte keine Meldung zu geöffnet mehr kommen. Gibt es eventuell einen Task der die Datenbank-Instanz neu startet? Klingt alles nicht unbedingt nach einer Software, die sich groß um ihre Datenbank kümmert. Die haben bestimmt sowas "sinnvolles" eingebaut.
Die Datei wird nicht als unlesbar gemeldet sondern als geöffnet. Sogar als geöffnet durch "SQL Server (MSSQLSERVER)". Das kann nur ein SQL Dienst sein, auch eine Serveranwendung / Dienst greift nicht direkt auf die mdf zu. MSSQL ist schließlich ein DBMS und nicht nur eine DB.
Zur Not alle Dienste mit SQL auf Deaktiviert setzen und neu starten. Im Anschluss sollte keine Meldung zu geöffnet mehr kommen. Gibt es eventuell einen Task der die Datenbank-Instanz neu startet? Klingt alles nicht unbedingt nach einer Software, die sich groß um ihre Datenbank kümmert. Die haben bestimmt sowas "sinnvolles" eingebaut.
Hallo, da es ja einfach sein soll probier mal den SQL Server Migration Assistant von Microsoft ob der den Inhalt der DB auf einen anderen SQL Server kopieren kann.
Reperaturversuche direkt an der Datenbank wie von @MadMax beschrieben würde ich erst machen wenn ich eine Kopie der Datenbanken habe.
Hier erst wie schon geschrieben den Dienst des SQL Servers stoppen, danach kann man normalerweise die Dateien kopieren, ich befürchte hier aber wieder den CRC Fehler
Reperaturversuche direkt an der Datenbank wie von @MadMax beschrieben würde ich erst machen wenn ich eine Kopie der Datenbanken habe.
Hier erst wie schon geschrieben den Dienst des SQL Servers stoppen, danach kann man normalerweise die Dateien kopieren, ich befürchte hier aber wieder den CRC Fehler
1
Hallo und danke für die weiteren Infos und Tipps.
Bei meinen Versuchen gestern hatte ich die Dienste ja beendet (siehe meine entspr. Nachrichten dazu). Und ich hatte auch gecheckt, ob wirklich alle Dienste deaktiviert sind... das war so.
Das mit dem Transaktionsprotokoll ( @MadMax: ) habe ich noch nicht so ganz verstanden. Vielleicht kannst Du mir nochmal genauer erklären, was Du meinst und wie ich das mache.
Bezüglich der DB-Prüfung (Check) bin ich natürlich sicher, dass unser IT-Dienstleister das bereits gemacht hat... und selbst wenn nicht, hätte der Microsoft-Support diesen Vorschlag ganz sicher auch gemacht.
Und es wurden ja bereits mehrere Versuche gemacht, die DB zu reparieren. Daher ist ja dann eigentlich auch klar, dass sie vorher gecheckt wurde.
@maretz:
Die Software war definitiv beendet und nicht mehr aktiv. Ich hatte auch im IIS-Manager die entspr. Webseite angehalten, was ich auch immer mache, bevor ich ein Update installiere, damit wirklich Niemand mehr auf das Programm zugreifen kann.
Ich habe den IT-Dienstleister gestern per Email plus entsp. Screenshots über meine gescheiterten Versuche informiert und dabei auch das Thema "defekte Festplatte..." angesprochen. Bisher kam noch keine Reaktion.
Sobald hier was kommt, würde ich nochmal hier antworten.
Grüße,
Werker
Bei meinen Versuchen gestern hatte ich die Dienste ja beendet (siehe meine entspr. Nachrichten dazu). Und ich hatte auch gecheckt, ob wirklich alle Dienste deaktiviert sind... das war so.
Das mit dem Transaktionsprotokoll ( @MadMax: ) habe ich noch nicht so ganz verstanden. Vielleicht kannst Du mir nochmal genauer erklären, was Du meinst und wie ich das mache.
Bezüglich der DB-Prüfung (Check) bin ich natürlich sicher, dass unser IT-Dienstleister das bereits gemacht hat... und selbst wenn nicht, hätte der Microsoft-Support diesen Vorschlag ganz sicher auch gemacht.
Und es wurden ja bereits mehrere Versuche gemacht, die DB zu reparieren. Daher ist ja dann eigentlich auch klar, dass sie vorher gecheckt wurde.
@maretz:
Die Software war definitiv beendet und nicht mehr aktiv. Ich hatte auch im IIS-Manager die entspr. Webseite angehalten, was ich auch immer mache, bevor ich ein Update installiere, damit wirklich Niemand mehr auf das Programm zugreifen kann.
Ich habe den IT-Dienstleister gestern per Email plus entsp. Screenshots über meine gescheiterten Versuche informiert und dabei auch das Thema "defekte Festplatte..." angesprochen. Bisher kam noch keine Reaktion.
Sobald hier was kommt, würde ich nochmal hier antworten.
Grüße,
Werker
Hallo Yan,
eine Empfehlung von mir:
- Was steht im Log vom SQL-Server bei der fehlerhaften Sicherung ?
- Hat das Datenbankfile / Log-File der Datenbank noch freien Festplattenplatz zur Verfügung ? (Ist die max. Größe
erreicht ?)
- Ist eine Voll-Sicherung der Datenbank mit der Datensicherungssoftware möglich ? -> So kann das Log-File der
Datenbank verkleinert werden.
Nette Grüße
Scout71
eine Empfehlung von mir:
- Was steht im Log vom SQL-Server bei der fehlerhaften Sicherung ?
- Hat das Datenbankfile / Log-File der Datenbank noch freien Festplattenplatz zur Verfügung ? (Ist die max. Größe
erreicht ?)
- Ist eine Voll-Sicherung der Datenbank mit der Datensicherungssoftware möglich ? -> So kann das Log-File der
Datenbank verkleinert werden.
Nette Grüße
Scout71
Bei meinen Versuchen gestern hatte ich die Dienste ja beendet (siehe meine entspr. Nachrichten dazu). Und ich hatte auch gecheckt, ob wirklich alle Dienste deaktiviert sind... das war so.
In welcher Instanz (MSSQLServer oder SFIRM) hängt die oh.mdf?Zudem spricht das Bild deines Screenshots was anderes. Irgendwas hat noch auf die mdf zugegriffen. Du musst folgende Dienste checken:
- SQL Server
- SQL Server Agent
- SQL Server Browser
- SQL Server Reporting Services
- SQL Server VSS Writer
Und dabei auch prüfen, ob die Prozesse wirklich beendet sind.
Am sichersten, wie bereits weiter oben (von @ukulele-7 ?) vorgeschlagen: Dienste alle auf "deaktiviert" setzen und den Server rebooten.
Fernab dessen:
versuch mal, die Sicherung nicht nach D:\MSSQLDaten\BACKUP anlegen zu lassen, sondern (ich weiss gar nicht, ob das geht) auf ein Netzwerkshare (vorher per Net-Use mounten) oder ein anderes Volume.
Schlimmstenfalls eine SSD per USB anschließen und darauf sichern.
Habt ihr eigentlich mal probiert, die mdf per LiveLinux o. ä. wegzukopieren?
Also Server herunterfahren, Knoppix oder was auch immer auf einen Stick packen und dann davon booten...
Hallo,
ich habe jetzt wirklich alle SQL-Dienste DEAKTIVIERT!!
Über den IIS-Manager auch die Webseite (für das eigentliche Programm) beendet.
Dann die "oh.mdf" kopieren wollen und erhielt wieder die gleiche Fehlermeldung, wie weiter oben schon. Also dass die "Datei in SQL-Server (MSSQLSERVER) geöffnet" sei. Siehe hier:
Und natürlich sind alle User aus dem Programm ausgestiegen und können auch nicht damit arbeiten, da die Webseite beendet ist.
Bei 70% kam dann diese Fehlermeldung:
Danach habe ich dann mal "überspringen" ausgewählt. Aber da wurde dann überhaupt nichts kopiert.
Was nun?
Grüße von
Yan
ich habe jetzt wirklich alle SQL-Dienste DEAKTIVIERT!!
Über den IIS-Manager auch die Webseite (für das eigentliche Programm) beendet.
Dann die "oh.mdf" kopieren wollen und erhielt wieder die gleiche Fehlermeldung, wie weiter oben schon. Also dass die "Datei in SQL-Server (MSSQLSERVER) geöffnet" sei. Siehe hier:
Und natürlich sind alle User aus dem Programm ausgestiegen und können auch nicht damit arbeiten, da die Webseite beendet ist.
Bei 70% kam dann diese Fehlermeldung:
Danach habe ich dann mal "überspringen" ausgewählt. Aber da wurde dann überhaupt nichts kopiert.
Was nun?
Grüße von
Yan
ich habe jetzt wirklich alle SQL-Dienste DEAKTIVIERT!!
Deaktiviert heißt nicht, dass die Dienste beendet sind. Laufen die Dienste also noch (Status = ausgeführt)?Die musst du dann noch beenden!
siehe Screenshot. Alle Dienste sind beendet und deaktiviert.
Grüße von
Yan
Grüße von
Yan
...ich würde in ein paar Minuten aber die Dienste wieder starten wollen, damit die Kollegen weiterarbeiten können.
Vielleicht hat aber noch jemand einen Tipp vorher...
Der IT-Dienstleister hat übrigens noch immer nicht auf meine Email von gestern geantwortet mit den Screenshots sowie dem Hinweis auf die evtl. defekte Festplatte
Grüße von
Yan
Vielleicht hat aber noch jemand einen Tipp vorher...
Der IT-Dienstleister hat übrigens noch immer nicht auf meine Email von gestern geantwortet mit den Screenshots sowie dem Hinweis auf die evtl. defekte Festplatte
Grüße von
Yan
der ist zum Zeitpunkt meines Posts noch nicht dagewesen.
Irgendwas greift da noch drauf zu. Hast du, nachdem die Dienste deaktiviert und beendet wurden, den Server einmal neugestartet?
Wenn der schreibt kann nicht gelesen werden, kann der CRC Fehler auch der Grund sein. Im Schlimmsten Fall ne kopie mit Linux DD. Aber probier doch wirklich mal den Migrations Assistent nlvon Microsoft. Wenn du mit der DB arbeiten kannst, vielleicht hast du Glück.
Hallo Yan,
ein Backup ist nur eine Momentaufnahme Deiner Datenbank. Was auf der DB passiert, wird aber ständig mitprotokolliert. Wenn das Wiederherstellungsmodell "Vollständig" ist (DB-Eigenschaften, Seite "Optionen"), dann wird dieses Protokoll erst gelöscht, wenn es gesichert wurde, ansonsten wächst es immer weiter. Dein IT-Dienstleister sollte Dir die Frage beantworten können, wie oft es gesichert wird und ob Eure Protokollsicherungen bis zur letzten Vollsicherung zurückreichen.
Wenn Ihr die Protokollsicherungen alle habt, dann mußt Du nur noch den letzten Teil, der noch nicht gesichert wurde, sichern und kannst dann erst die Vollsicherung und anschließend alle nachfolgenden Protokolle einspielen und hast den aktuellen Stand der DB.
Was die Prüfung angeht: im Prinzip hast Du recht, da sollten sowohl Dein Dienstleister, als auch der MS-Support dran gedacht haben. Aber auch hier hat niemand was dazu gesagt vor mir und hier sind einige fähige Leute versammelt. Und vielleicht hat auch der MS-Support gedacht, daß man einem erfahrenen Admin sowas nicht erzählen muß
Ich muß aber sagen: Die Prüfung dauert ein paar Minuten. Wenn Du einem Admin, der ein halbes Jahr lang nicht bemerkt, daß die Sicherung nicht läuft, so vertraust, daß Du es nicht nochmal selber prüfen willst, dann ok.
Gruß, Mad Max
ein Backup ist nur eine Momentaufnahme Deiner Datenbank. Was auf der DB passiert, wird aber ständig mitprotokolliert. Wenn das Wiederherstellungsmodell "Vollständig" ist (DB-Eigenschaften, Seite "Optionen"), dann wird dieses Protokoll erst gelöscht, wenn es gesichert wurde, ansonsten wächst es immer weiter. Dein IT-Dienstleister sollte Dir die Frage beantworten können, wie oft es gesichert wird und ob Eure Protokollsicherungen bis zur letzten Vollsicherung zurückreichen.
Wenn Ihr die Protokollsicherungen alle habt, dann mußt Du nur noch den letzten Teil, der noch nicht gesichert wurde, sichern und kannst dann erst die Vollsicherung und anschließend alle nachfolgenden Protokolle einspielen und hast den aktuellen Stand der DB.
Was die Prüfung angeht: im Prinzip hast Du recht, da sollten sowohl Dein Dienstleister, als auch der MS-Support dran gedacht haben. Aber auch hier hat niemand was dazu gesagt vor mir und hier sind einige fähige Leute versammelt. Und vielleicht hat auch der MS-Support gedacht, daß man einem erfahrenen Admin sowas nicht erzählen muß
Ich muß aber sagen: Die Prüfung dauert ein paar Minuten. Wenn Du einem Admin, der ein halbes Jahr lang nicht bemerkt, daß die Sicherung nicht läuft, so vertraust, daß Du es nicht nochmal selber prüfen willst, dann ok.
Gruß, Mad Max
Also es macht tatsächlich den Eindruck, das die Meldung "ist noch geöffnet" nicht aufgrund einer geöffneten DB-Datei kommt, vor allem, wenn das erst bei 70% Kopiervorgang erscheint - sonderbar. Du kannst du prüfen, ob die Datei eventuell über das Netzwerk geöffnet wurde
Computerverwaltung \ Freigegebene Ordner \ Geöffnete Dateien
das sollte natürlich bei einer mdf ldf nicht der Fall sein! Ansonsten macht ein Versuch unter Live Linux Sinn.
An einem gewissen Punkt musst du eventuell entscheiden, wie wichtig dir die Daten sind. Wenn sich das nicht kopieren lässt und dein Systemhaus auch nur probiert und du mit unserer Hilfe auch nur probierst kommt vielleicht irgendwann der Moment, wo man etwas verschlimmert. Du könntest die Serverfestplatten (ist das eine VM oder direkt bare metal?) auch z.B. bei Ontrack einschicken und eine Datenrettung machen lassen. Die Kosten dürften sich eventuell im Rahmen halten und eine Cyberversicherung würde das vermutlich bezahlen. Derzeit arbeitest du quasi ohne "Sicherheitsnetz" an der einzigen Kopie, da sollte man schon mal in sich gehen.
Natürlich wäre es nach wie vor eine gute Option, alle Tabellen etc. von einem Verbundenen SQL Server aus händisch zu kopieren oder mit irgendeinem Migrationstool, wie bereits vorgeschlagen, zu versuchen, die Daten umzuziehen oder zu klonen. Das ist aber mit Sicherheit auch viel Aufwand, vor allem, wenn der Software-Hersteller so toll mit wirkt.
Computerverwaltung \ Freigegebene Ordner \ Geöffnete Dateien
das sollte natürlich bei einer mdf ldf nicht der Fall sein! Ansonsten macht ein Versuch unter Live Linux Sinn.
An einem gewissen Punkt musst du eventuell entscheiden, wie wichtig dir die Daten sind. Wenn sich das nicht kopieren lässt und dein Systemhaus auch nur probiert und du mit unserer Hilfe auch nur probierst kommt vielleicht irgendwann der Moment, wo man etwas verschlimmert. Du könntest die Serverfestplatten (ist das eine VM oder direkt bare metal?) auch z.B. bei Ontrack einschicken und eine Datenrettung machen lassen. Die Kosten dürften sich eventuell im Rahmen halten und eine Cyberversicherung würde das vermutlich bezahlen. Derzeit arbeitest du quasi ohne "Sicherheitsnetz" an der einzigen Kopie, da sollte man schon mal in sich gehen.
Natürlich wäre es nach wie vor eine gute Option, alle Tabellen etc. von einem Verbundenen SQL Server aus händisch zu kopieren oder mit irgendeinem Migrationstool, wie bereits vorgeschlagen, zu versuchen, die Daten umzuziehen oder zu klonen. Das ist aber mit Sicherheit auch viel Aufwand, vor allem, wenn der Software-Hersteller so toll mit wirkt.
Weiterarbeiten mit der DB ist semi-optimal.
So oder so muss rasch eine Lösung her, damit der Schade nicht zu groß wird.
https://www.stellarinfo.com/blog/de/sql-datenbank-fehler-bei-der-zyklisc ...
Da nochmal Infos zu CRC Fehlern und möglichen Lösungsansätzen.
So oder so muss rasch eine Lösung her, damit der Schade nicht zu groß wird.
https://www.stellarinfo.com/blog/de/sql-datenbank-fehler-bei-der-zyklisc ...
Da nochmal Infos zu CRC Fehlern und möglichen Lösungsansätzen.
Hallo und ich hoffe, Ihr hattet ein schönes WE...
Ich habe mir eben mal die Eigenschaften / Optionen der Datenbank angeschaut.
Das Wiederherstellungsmodell steht nur auf "Einfach" und unten bei Seitenüberprüfung steht "CHECKSUM".
Eben habe ich mal eine Abfrage ausgeführt mit "dbcc checkdb", wie ja vorgeschlagen wurde.
Auch da kam eine Fehlermeldung mit weiterem Text. Siehe hier:
Ich habe nur die beiden ersten Ergebnis-Zeilen hier einkopiert. Davon gibt es noch eine riesige Menge weiterer Einträge. Ganz unten das ist die letzte Zeile mit einer Art Gesamtergebnis.
Der IT-Dienstleister hat mir auf meine Fragen auch bis jetzt noch nicht geantwortet.... hmmm... ist vielleicht auch ein gewisses Zeichen
Den Link von @Crusher79 gebe ich nun auch mal an unseren IT-Dienstleister weiter.
Ich hoffe, Ihr versteht mich.
Ich tue mich etwas schwer damit, manche der von Euch vorgeschlagenen Prüfungen / Arbeiten an der DB durchzuführen. Falls da etwas schief läuft und die DB dann wirklich im Eimer ist, dann habe ich natürlich den "Schwarzen Peter" und der IT-Dienstleister ist dann fein raus...
Ich werde Eure Tipps aber Stück für Stück an den IT-Dienstleister weitergeben, wenn er mir denn endlich mal antwortet. Falls bis heute Mittag nix gekommen ist, werde ich ihn mal anrufen und fragen.
Also bitte nicht böse sein, dass ich Eure guten Vorschläge nicht gleich umsetze...
Danke jedenfalls für die super Unterstützung bis dahin.
Grüße von
Yan
Ich habe mir eben mal die Eigenschaften / Optionen der Datenbank angeschaut.
Das Wiederherstellungsmodell steht nur auf "Einfach" und unten bei Seitenüberprüfung steht "CHECKSUM".
Eben habe ich mal eine Abfrage ausgeführt mit "dbcc checkdb", wie ja vorgeschlagen wurde.
Auch da kam eine Fehlermeldung mit weiterem Text. Siehe hier:
DBCC-Ergebnis für "ohdas".
Meldung 8921, Ebene 16, Status 1, Zeile 1
Die CHECK-Anweisung wurde beendet. Fehler beim Sammeln von Fakten. Möglicherweise ist kein freier Speicherplatz mehr in "tempdb" vorhanden, oder eine Systemtabelle ist inkonsistent. Überprüfen Sie die vorherigen Fehler.
DBCC-Ergebnis für "sys.sysrscols".
Es sind 10713 Zeilen auf 170 Seiten für das sys.sysrscols-Objekt vorhanden.
DBCC-Ergebnis für "sys.sysrowsets".
Es sind 2133 Zeilen auf 20 Seiten für das sys.sysrowsets-Objekt vorhanden.
...
...
...
Es sind 522652 Zeilen auf 43035 Seiten für das payment-Objekt vorhanden.
Von CHECKDB wurden 0 Zuordnungsfehler und 0 Konsistenzfehler in der ohdas-Datenbank gefunden.Ich habe nur die beiden ersten Ergebnis-Zeilen hier einkopiert. Davon gibt es noch eine riesige Menge weiterer Einträge. Ganz unten das ist die letzte Zeile mit einer Art Gesamtergebnis.
Der IT-Dienstleister hat mir auf meine Fragen auch bis jetzt noch nicht geantwortet.... hmmm... ist vielleicht auch ein gewisses Zeichen
Den Link von @Crusher79 gebe ich nun auch mal an unseren IT-Dienstleister weiter.
Ich hoffe, Ihr versteht mich.
Ich tue mich etwas schwer damit, manche der von Euch vorgeschlagenen Prüfungen / Arbeiten an der DB durchzuführen. Falls da etwas schief läuft und die DB dann wirklich im Eimer ist, dann habe ich natürlich den "Schwarzen Peter" und der IT-Dienstleister ist dann fein raus...
Ich werde Eure Tipps aber Stück für Stück an den IT-Dienstleister weitergeben, wenn er mir denn endlich mal antwortet. Falls bis heute Mittag nix gekommen ist, werde ich ihn mal anrufen und fragen.
Also bitte nicht böse sein, dass ich Eure guten Vorschläge nicht gleich umsetze...
Danke jedenfalls für die super Unterstützung bis dahin.
Grüße von
Yan
UPDATE:
Soeben habe ich eine Antwort des IT-Dienstleisters erhalten.
Er schreibt, dass ich richtig lag mit meiner Vermutung (womit er unwissenderweise natürlich EUCH meint ). Durch den Ausfall der 3 physischen Festplatten, welche kürzlich bei uns gewechselt wurden, ist die „virtuelle“ Festplatte des entspr. Servers beschädigt. Dadurch auch die Abbrüche beim Kopieren der mdf-Datei, dem Klonen des Servers oder dem Erstellen eines Backups mit dem Programm "Altaro".
Er schreibt weiterhin, dass er erst dadurch ja ursprünglich darauf aufmerksam geworden sei, dass die physischen Festplatten beschädigt waren.
Aus diesem Grund fährt er aktuell auch zweigleisig:
- zum einen versucht er, die virtuelle Festplatte bzw. das Dateisystem zu reparieren, und zum anderen
- die Datenbank selbst zu reparieren.
Er schreibt noch, dass er nun auch nochmal Rückmeldung von Microsoft erhalten hat mit weiteren Möglichkeiten, welche er heute Vormittag umsetzen will.
Das als Zwischeninfo...
Grüße von
Yan
Soeben habe ich eine Antwort des IT-Dienstleisters erhalten.
Er schreibt, dass ich richtig lag mit meiner Vermutung (womit er unwissenderweise natürlich EUCH meint
). Durch den Ausfall der 3 physischen Festplatten, welche kürzlich bei uns gewechselt wurden, ist die „virtuelle“ Festplatte des entspr. Servers beschädigt. Dadurch auch die Abbrüche beim Kopieren der mdf-Datei, dem Klonen des Servers oder dem Erstellen eines Backups mit dem Programm "Altaro".Er schreibt weiterhin, dass er erst dadurch ja ursprünglich darauf aufmerksam geworden sei, dass die physischen Festplatten beschädigt waren.
Aus diesem Grund fährt er aktuell auch zweigleisig:
- zum einen versucht er, die virtuelle Festplatte bzw. das Dateisystem zu reparieren, und zum anderen
- die Datenbank selbst zu reparieren.
Er schreibt noch, dass er nun auch nochmal Rückmeldung von Microsoft erhalten hat mit weiteren Möglichkeiten, welche er heute Vormittag umsetzen will.
Das als Zwischeninfo...
Grüße von
Yan
Hallo Yan,
wir hatten mal einen ähnlichen Fall.
Wir hatten ein Problem im SQL-Cluster, dass sich nicht mehr lösen lies.
Ich kann nur soviel sagen. Von Seiten Microsoft kam nichts, WIRKLICH gar nichts. Also richtig uncool.
Sie konnten unsere DB NICHT mehr zum Laufen bringen.
Unser sehr guter Dienstleister, der ausschließlich DB's macht, war ebenfalls an seine Grenzen gekommen.
Wir mussten letztendlich auf einen neuen SQL Server wechseln und das letzte Backup zurück spielen.
War ganz uncool und logischerweise mit Datenverlust verbunden.
Die Datenbank Sicherung sollte UNBEDINGT bei euch überwacht werden, was ein guter SLA Partner eigentlich machen MUSS. Selbst wenn ihr mit Boardmiteln, wie wir, eure Backup's fahrt, ist hier ein Alerting per eMail problemlos einzurichten. Damit erhaltet ihr sofort eMails, wenn das Backup NICHT 100% lief.
Ich wünsche euch viel Glück und unbedingt daraus lernen.
Gruss Roland
wir hatten mal einen ähnlichen Fall.
Wir hatten ein Problem im SQL-Cluster, dass sich nicht mehr lösen lies.
Ich kann nur soviel sagen. Von Seiten Microsoft kam nichts, WIRKLICH gar nichts. Also richtig uncool.
Sie konnten unsere DB NICHT mehr zum Laufen bringen.
Unser sehr guter Dienstleister, der ausschließlich DB's macht, war ebenfalls an seine Grenzen gekommen.
Wir mussten letztendlich auf einen neuen SQL Server wechseln und das letzte Backup zurück spielen.
War ganz uncool und logischerweise mit Datenverlust verbunden.
Die Datenbank Sicherung sollte UNBEDINGT bei euch überwacht werden, was ein guter SLA Partner eigentlich machen MUSS. Selbst wenn ihr mit Boardmiteln, wie wir, eure Backup's fahrt, ist hier ein Alerting per eMail problemlos einzurichten. Damit erhaltet ihr sofort eMails, wenn das Backup NICHT 100% lief.
Ich wünsche euch viel Glück und unbedingt daraus lernen.
Gruss Roland
Hallo nochmal...
Ich wollte nur nochmal kurz mitteilen, dass heute ein weiterer Reparaturversuch durchgeführt wird, wozu auch ein vorheriger Server-Neustart nötig ist. Dieser Versuch wird durch unseren IT-Dienstleister durchgeführt und der Tipp kam erneut vom Microsoft-Support. Ich hoffe, dass er diesmal Erfolg hat
Das nur als Zwischen-Info. Werde weiter berichten...
Grüße von
Yan
Ich wollte nur nochmal kurz mitteilen, dass heute ein weiterer Reparaturversuch durchgeführt wird, wozu auch ein vorheriger Server-Neustart nötig ist. Dieser Versuch wird durch unseren IT-Dienstleister durchgeführt und der Tipp kam erneut vom Microsoft-Support. Ich hoffe, dass er diesmal Erfolg hat
Das nur als Zwischen-Info. Werde weiter berichten...
Grüße von
Yan
1
Hallo mal wieder...
Der neue Reparaturversuch durch unseren IT-Dienstleister hat wohl auch nichts gebracht.
Er bat mich heute Morgen, nochmal die Sicherung der SQL-DB durchzuführen.
Leider brach die Sicherung erneut bei 70% ab
Er will sich das aber nochmal anschauen (was er natürlich schon zig mal getan hat innerhalb der letzten Wochen)...
So langsam befürchte ich, dass wir so nicht mehr weiterkommen und ggf. doch weitere Schritte unternehmen müssen, wie ja hier auch bereits vorgeschlagen. Ich weiß jedoch nicht, welche Schritte im Einzelnen bereits durchgeführt wurden. Vielleicht sollte ich den IT-Dienstleister genau das mal fragen - oder was meint Ihr?
Grüße von
Yan
Der neue Reparaturversuch durch unseren IT-Dienstleister hat wohl auch nichts gebracht.
Er bat mich heute Morgen, nochmal die Sicherung der SQL-DB durchzuführen.
Leider brach die Sicherung erneut bei 70% ab
Er will sich das aber nochmal anschauen (was er natürlich schon zig mal getan hat innerhalb der letzten Wochen)...
So langsam befürchte ich, dass wir so nicht mehr weiterkommen und ggf. doch weitere Schritte unternehmen müssen, wie ja hier auch bereits vorgeschlagen. Ich weiß jedoch nicht, welche Schritte im Einzelnen bereits durchgeführt wurden. Vielleicht sollte ich den IT-Dienstleister genau das mal fragen - oder was meint Ihr?
Grüße von
Yan
Ich weiß jedoch nicht, welche Schritte im Einzelnen bereits durchgeführt wurden. Vielleicht sollte ich den IT-Dienstleister genau das mal fragen - oder was meint Ihr?
Bitte unbedingt.Was du aber weiterhin selbst machen kannst (und oben auch schon mehrfach erwähnt wurde):
- Server herunterfahren
- Server von einem LiveLinux (knoppix, ...) booten
- Speicherort der mdf + ldf "ansteuern"
- Beide Dateien woanders hinkopieren (auf eine andere VHD, oder einen zu mountenden Netzwerkshare)
Und dann mal schauen, ob sich die DB woanders einbinden ließe...
Ich würde auch mal die DB File's (gestoppter Dienst) kopieren und an einen anderen SQL-Server anbinden.
Hier gäbe es sicherlich mehr Spielraum um zu testen und "rumreisen", ohne dass die Produktion davon betroffen wäre, wenn was schief geht bzw. in Mitleidenschaft gezogen würde.
Hier kann der Dienstleister und oder Microsoft sich mal richtig austoben.
Vielleicht gibt es ja wirklich auch "nur" ein Problem mit dem NTFS/Block/Sektor, was dann bei Kopieren vermutlich auch zum Vorschein kommen würde. Dann wüsste man zumindest, dass es kein SQL/DB Problem wäre.
Viel Glück
Hier gäbe es sicherlich mehr Spielraum um zu testen und "rumreisen", ohne dass die Produktion davon betroffen wäre, wenn was schief geht bzw. in Mitleidenschaft gezogen würde.
Hier kann der Dienstleister und oder Microsoft sich mal richtig austoben.
Vielleicht gibt es ja wirklich auch "nur" ein Problem mit dem NTFS/Block/Sektor, was dann bei Kopieren vermutlich auch zum Vorschein kommen würde. Dann wüsste man zumindest, dass es kein SQL/DB Problem wäre.
Viel Glück
es kommt ja beim Kopieren nach 70% auch der Fehler, das die Quelldatei nicht gelesen werden kann.
Scheint dann eher ein Filesystem oder Hardwareproblem zu sein.
Scheint dann eher ein Filesystem oder Hardwareproblem zu sein.
Dann hilft auch der Microsoft SQL Support nichts.
Aber wie oben schon geschrieben.
Verschlimmbessern scheint nicht mehr weit zu sein.
Früher oder später musst du ein Notfallszenario in Betracht ziehen.
Die Produktion stoppen und retten, was zu retten ist und eine neue DB anfangen. (auf einen neuen SQL Server).
Den bestehenden SQL-Server würde ich sooo nicht mehr weiterverwenden.
Ich hoffe du/ihr habt da die Geschäftsleitung schon mal informiert, da sie dies logischerweise mittragen müssen.
Aber wie oben schon geschrieben.
Verschlimmbessern scheint nicht mehr weit zu sein.
Früher oder später musst du ein Notfallszenario in Betracht ziehen.
Die Produktion stoppen und retten, was zu retten ist und eine neue DB anfangen. (auf einen neuen SQL Server).
Den bestehenden SQL-Server würde ich sooo nicht mehr weiterverwenden.
Ich hoffe du/ihr habt da die Geschäftsleitung schon mal informiert, da sie dies logischerweise mittragen müssen.
Meine Rede, irgendwann muss jemand Entscheiden, was diese Daten Wert sind. Niemand sollte da "mal was versuchen" sondern eine Kopie der VM oder des ganzen RAIDs auf dem das ganze liegt oder zumindest der Datenbank-Dateien sollte Priorität A sein, noch über dem laufenden Geschäftsbetrieb. Und das kann auch nur der Verantwortliche entscheiden.
Bei dem, was bisher schon an Aufwand betreiben wurde, um gegen Symptome zu kämpfen, hätte OnTrack vielleicht schon ganz easy eine Bit-Kopie aller intakten Blöcke gezogen und mit weiteren Kopien kann man auf einem anderen Server spielen.
Ihr versucht im Moment immer wieder, den zweiten vor dem ersten Schritt zu gehen und die Datenbank einfach nur irgendwie wieder lauffähig machen zu wollen. Dabei vergeht viel Zeit. Zeit, in der es kein Backup und kein Fallback-Szenario für euren Geschäftsbetrieb gibt. Was passiert denn, wenn weitere Sektoren der HDDs Lesefehler werfen? Was plant ihr denn, auf welche Platten zieht ihr eure VMs um? Wollt ihr wirklich mit dem Server so weiter machen?
Bei dem, was bisher schon an Aufwand betreiben wurde, um gegen Symptome zu kämpfen, hätte OnTrack vielleicht schon ganz easy eine Bit-Kopie aller intakten Blöcke gezogen und mit weiteren Kopien kann man auf einem anderen Server spielen.
Ihr versucht im Moment immer wieder, den zweiten vor dem ersten Schritt zu gehen und die Datenbank einfach nur irgendwie wieder lauffähig machen zu wollen. Dabei vergeht viel Zeit. Zeit, in der es kein Backup und kein Fallback-Szenario für euren Geschäftsbetrieb gibt. Was passiert denn, wenn weitere Sektoren der HDDs Lesefehler werfen? Was plant ihr denn, auf welche Platten zieht ihr eure VMs um? Wollt ihr wirklich mit dem Server so weiter machen?
Hallo Yan,
Ihr habt beim Sichern der DB einen Lesefehler bekommen, also würde ich mal annehmen, daß Ihr die Datei oh.mdf auch im Dateisystem nicht kopieren könnt. Das heißt nicht, daß Ihr das nicht versuchen solltet. Aber vorher die Datenbank beenden oder aber mit Linux starten, wie es ja auch schon oben hieß.
Trotzdem bleibe ich dabei, Du solltest feststellen, was überhaupt kaputt ist in Eurer DB. Das mit dem dbcc checkdb hat ja einen Fehler gebracht. Der läßt sich aber vermeiden: "dbcc checkdb (<Datenbank>) with tablock". Mit dem "with tablock" läßt sich der "Fehler beim Sammeln von Fakten" umgehen, weil er dann die Tabellen und womöglich die ganze DB sperrt. Deswegen solltest Du auch den Befehl von einer anderen DB aus starten und dafür den DB-Namen eintragen.
Wenn Du Glück hast, sind entweder gar keine Tabellen betroffen oder nur irgendwelche unwichtigen. Wenn es wichtige sind, dann solltet Ihr möglicherweise in Erwägung ziehen, die HDD professionell auslesen zu lassen, damit die Daten gerettet werden.
Gruß, Mad Max
Ihr habt beim Sichern der DB einen Lesefehler bekommen, also würde ich mal annehmen, daß Ihr die Datei oh.mdf auch im Dateisystem nicht kopieren könnt. Das heißt nicht, daß Ihr das nicht versuchen solltet. Aber vorher die Datenbank beenden oder aber mit Linux starten, wie es ja auch schon oben hieß.
Trotzdem bleibe ich dabei, Du solltest feststellen, was überhaupt kaputt ist in Eurer DB. Das mit dem dbcc checkdb hat ja einen Fehler gebracht. Der läßt sich aber vermeiden: "dbcc checkdb (<Datenbank>) with tablock". Mit dem "with tablock" läßt sich der "Fehler beim Sammeln von Fakten" umgehen, weil er dann die Tabellen und womöglich die ganze DB sperrt. Deswegen solltest Du auch den Befehl von einer anderen DB aus starten und dafür den DB-Namen eintragen.
Wenn Du Glück hast, sind entweder gar keine Tabellen betroffen oder nur irgendwelche unwichtigen. Wenn es wichtige sind, dann solltet Ihr möglicherweise in Erwägung ziehen, die HDD professionell auslesen zu lassen, damit die Daten gerettet werden.
Gruß, Mad Max
Hallo und danke für die vielen weitere Antworten.
Es wird immer wieder empfohlen, die mdf-Datei zu kopieren.
Aber kopieren geht nicht. Nicht nur die Sicherung bricht jedesmal bei 70% ab, sondern auch jeder Kopiervorgang (egal womit).
Den Tipp mit "dbcc checkdb datenbank with tablock" würde ich gerne mal testen.
Gebe ich das so ein, wie hier in den "" geschrieben? Also den Namen der Datenbank einfach so, wie hier geschrieben?
Vorher muss ich die DB wieder beenden... richtig?
Ich habe den IT-Dienstleister schon darum gebeten, mir mal alle Schritte und Versuche mitzuteilen, die bisher unternommen wurden. Bisher weiß ich ja überhaupt nicht, ob einige Eurer Tipps hier längst versucht wurden (z.B. Linux etc.). Das muss ich zunächst mal abwarten. Man hat mir bereits geantwortet, dass ich diese Aufstellung in Kürze bekomme.
Grüße von
Yan
Es wird immer wieder empfohlen, die mdf-Datei zu kopieren.
Aber kopieren geht nicht. Nicht nur die Sicherung bricht jedesmal bei 70% ab, sondern auch jeder Kopiervorgang (egal womit).
Den Tipp mit "dbcc checkdb datenbank with tablock" würde ich gerne mal testen.
Gebe ich das so ein, wie hier in den "" geschrieben? Also den Namen der Datenbank einfach so, wie hier geschrieben?
dbcc checkdb db-name with tablockVorher muss ich die DB wieder beenden... richtig?
Ich habe den IT-Dienstleister schon darum gebeten, mir mal alle Schritte und Versuche mitzuteilen, die bisher unternommen wurden. Bisher weiß ich ja überhaupt nicht, ob einige Eurer Tipps hier längst versucht wurden (z.B. Linux etc.). Das muss ich zunächst mal abwarten. Man hat mir bereits geantwortet, dass ich diese Aufstellung in Kürze bekomme.
Grüße von
Yan
Yan vergiss nicht parallel schon anfangen einen Notfallplan zu "stricken".
Wenn das im Desaster endet hast du die Zeit vergeudet.
Du bist schon seit 2 Wochen an dem Problem; und jeden Tag mehr, wo es kein Backup gibt.
Bedeutet alles was jeden Tag neu in die DB hinzukommt, ist nachher auch "verloren", sollte dies ins Unglück laufen.
Ein Entscheidungsträger hätte hier schon LÄNGST die Reisleine gezogen und die "Produktion" gestoppt.
Also entweder ist die DB doch nicht sonderlich kritisch oder du handelst etwas blauäugig (fahrlässig).
Viel Glück (was anderes ist nach 2 Wochen nicht mehr realistisch)
Gruss Roland
Wenn das im Desaster endet hast du die Zeit vergeudet.
Du bist schon seit 2 Wochen an dem Problem; und jeden Tag mehr, wo es kein Backup gibt.
Bedeutet alles was jeden Tag neu in die DB hinzukommt, ist nachher auch "verloren", sollte dies ins Unglück laufen.
Ein Entscheidungsträger hätte hier schon LÄNGST die Reisleine gezogen und die "Produktion" gestoppt.
Also entweder ist die DB doch nicht sonderlich kritisch oder du handelst etwas blauäugig (fahrlässig).
Viel Glück (was anderes ist nach 2 Wochen nicht mehr realistisch)
Gruss Roland
da ja das Sichern und Klonen der VM scheinbar auch nicht geht, würde ich als erstes die VM herunterfahren und die Files der VM irgendwo hin kopieren.
Dann kann man eine Reparatur ausprobieren
Dann kann man eine Reparatur ausprobieren
Den Tipp mit "dbcc checkdb datenbank with tablock" würde ich gerne mal testen.
Am besten du legst den Server noch in die Mikrowelle, vielleicht hilft das ja. Irgendwann isses dann halt soweit.1Es wird immer wieder empfohlen, die mdf-Datei zu kopieren.
Aber kopieren geht nicht. Nicht nur die Sicherung bricht jedesmal bei 70% ab, sondern auch jeder Kopiervorgang (egal womit).
und das womit ist was genau?Aber kopieren geht nicht. Nicht nur die Sicherung bricht jedesmal bei 70% ab, sondern auch jeder Kopiervorgang (egal womit).
- ct's Notfall-Windows
- ct's desinfect?
- Knoppix?
- Und hast du auch z. B. ein
ddrescueder gesamten virtuellen Disk probiert?
Das alles geht hier nicht draus hervor.
Wir haben jetzt hier schon mehrfach geschrieben, dass du die VM herunterfahren und mit einem anderen System hochfahren bzw. die VHDX/ VMDK irgendwo hinkopieren sollst.
Hast du dies explizit gemacht oder nicht?
Moin @Yan2021,
hast du den die DB respektiven den SQL-Server beendet bevor du begonnen hast die mdf zu kopieren?
Des weiteren, ich kann dir nur empfehlen, den MS-Support auf keinen Fall an euere produktive Datenbank ranzulassen, schon gar nicht, wenn ihr dafür kein Aktuelles Backup habt. Ich habe nach solchen MS-Support-Aktionen, leider schon oft genug nur noch Scherben zusammenkehren können. 😔
Kopiert wie hier schon mehrfach vorgeschlagen wurde, die entsprechende VM auf ein anderes System und exorziert den Fehler bitte zuerst auf dieser heraus!
Und wenn das mit dem Kopieren der VM funktioniert, dann bitte nochmals eine Kopie angelegen und diese in den Tresor legen, dann habt ihr auch wieder ein halbwegs funktionierendes und aktuelles Backup. 😉
Gruss Alex
Es wird immer wieder empfohlen, die mdf-Datei zu kopieren.
Aber kopieren geht nicht. Nicht nur die Sicherung bricht jedesmal bei 70% ab, sondern auch jeder Kopiervorgang (egal womit).
Aber kopieren geht nicht. Nicht nur die Sicherung bricht jedesmal bei 70% ab, sondern auch jeder Kopiervorgang (egal womit).
hast du den die DB respektiven den SQL-Server beendet bevor du begonnen hast die mdf zu kopieren?
Des weiteren, ich kann dir nur empfehlen, den MS-Support auf keinen Fall an euere produktive Datenbank ranzulassen, schon gar nicht, wenn ihr dafür kein Aktuelles Backup habt. Ich habe nach solchen MS-Support-Aktionen, leider schon oft genug nur noch Scherben zusammenkehren können. 😔
Kopiert wie hier schon mehrfach vorgeschlagen wurde, die entsprechende VM auf ein anderes System und exorziert den Fehler bitte zuerst auf dieser heraus!
Und wenn das mit dem Kopieren der VM funktioniert, dann bitte nochmals eine Kopie angelegen und diese in den Tresor legen, dann habt ihr auch wieder ein halbwegs funktionierendes und aktuelles Backup. 😉
Gruss Alex
Moin @Yan2021,
ähm ...
... das habe ich jetzt erst gesehen und ich kann dir jetzt schon sagen, dass wenn du die VM weder Klonen noch Kopieren kannst, du vor einem sehr grossen Problem stehst, weil die VM nicht von innen, sondern von aussen deffekt ist. 😔
Und das ...
... also bei einem solchen Defekt versuchen die SQL-Datenbank selbst innerhalb der VM zu Reparieren, zeugt einfach nur von absoluter Ahnungslosigkeit (der gilt übrigens hauptsächlich dem MS-Support und auch dem entsprechenden Dienstleister), weil absolut der falsche Schritt!
Denn, Falls du bereits schon die VM im heruntergefahrenen Zustand nicht mehr kopieren kannst, dann liegt der Defekt nicht innerhalb der VM sondern wie schon geschrieben eher ausserhalb. Daher ist jede Aktion in der laufenden VM, schlichtweg sinnlos. Im Gegenteil, damit könnt ihr den bisherigen Schaden, eigentlich nur noch vergrössern. 😔
Daher, falls euch die Daten dieser DB wirklich wichtig sind, dann stoppt bitte augenblicklich jeglichen Rettungsversuch innerhalb der VM! Denn das ist schlichtweg für die Katz, weil bereits schon das Dateisystem auf dem die virtuellen Platten des SQL-Servers liegen, einen Schaden hat und diesen kann man ganz sicher nicht innerhalb einer VM beheben.
Das was du jetzt benötigst ist nicht ein SQL-Spezialist, sondern einer der sich mit dem Dateisystem des entsprechenden Hypervisors 1A auskennt.
Welchen Hypervisor (VMware, Hyper-V, Proxmox) setzt ihr eigentlich ein?
Wenn Hyper-V.
Dann führe mal als nächstes ein "chkdsk" auf dem entsprechenden Volume aus und zwar ohne jeglichen Reparaturparameter ...
Beispiel:
... sprich nur mal scannen.
Gruss Alex
ähm ...
Auch das Klonen des entspr. virtuellen Servers (auf dem die DB liegt) funktioniert nicht und bricht ab... offenbar ebenfalls aufgrund der defekten Datenbank.
... das habe ich jetzt erst gesehen und ich kann dir jetzt schon sagen, dass wenn du die VM weder Klonen noch Kopieren kannst, du vor einem sehr grossen Problem stehst, weil die VM nicht von innen, sondern von aussen deffekt ist. 😔
Und das ...
Unser IT-Dienstleister hat nun schon den Microsoft-Support zur Hilfe genommen und mit deren Hilfe verschiedene Reparaturversuche für die SQL-Datenbank durchgeführt.
... also bei einem solchen Defekt versuchen die SQL-Datenbank selbst innerhalb der VM zu Reparieren, zeugt einfach nur von absoluter Ahnungslosigkeit (der gilt übrigens hauptsächlich dem MS-Support und auch dem entsprechenden Dienstleister), weil absolut der falsche Schritt!
Denn, Falls du bereits schon die VM im heruntergefahrenen Zustand nicht mehr kopieren kannst, dann liegt der Defekt nicht innerhalb der VM sondern wie schon geschrieben eher ausserhalb. Daher ist jede Aktion in der laufenden VM, schlichtweg sinnlos. Im Gegenteil, damit könnt ihr den bisherigen Schaden, eigentlich nur noch vergrössern. 😔
Daher, falls euch die Daten dieser DB wirklich wichtig sind, dann stoppt bitte augenblicklich jeglichen Rettungsversuch innerhalb der VM! Denn das ist schlichtweg für die Katz, weil bereits schon das Dateisystem auf dem die virtuellen Platten des SQL-Servers liegen, einen Schaden hat und diesen kann man ganz sicher nicht innerhalb einer VM beheben.
Das was du jetzt benötigst ist nicht ein SQL-Spezialist, sondern einer der sich mit dem Dateisystem des entsprechenden Hypervisors 1A auskennt.
Welchen Hypervisor (VMware, Hyper-V, Proxmox) setzt ihr eigentlich ein?
Wenn Hyper-V.
Dann führe mal als nächstes ein "chkdsk" auf dem entsprechenden Volume aus und zwar ohne jeglichen Reparaturparameter ...
Beispiel:
chkdsk d:... sprich nur mal scannen.
Gruss Alex
2
Hallo und danke Euch Allen nochmal.
Viele Eurer Fragen kann ich gar nicht beantworten, da die Reparatur etc. ja durch unseren IT-Dienstleister durchgeführt wird. Ich warte noch auf die Aufstellung darüber, was genau schon versucht wurde bisher...
Der SQL-Spezialist, den ich im vorherigen Post genannt hatte, ist der Mitarbeiter des Herstellers der Software der betroffenen Datenbank. Daher fand ich es wichtig, ihn mit ins Boot zu nehmen.
Ich habe nun mal 2 Tests mit "chkdsk" gemacht, wie ja hier vorgeschlagen wurde.
Die Daten liegen auf "d:", aber ich habe Laufwerk "c:" auch noch prüfen lassen.
Es wurden aber offensichtlich keine Fehler gefunden.
Hier die Ergebnisse:
...und hier nochmal mit Laufwerk C:\
Demnach scheint ja auf dem Dateisystem alles OK zu sein.
Ich habe übrigens eben den Inhalt Deines Postes (@MysticFoxDE) mal an meinen IT-Dienstleister weitergeleitet.
Habe ihm dann auch das Ergebnis der beiden "chkdsk"-Tests schon mitgeteilt.
Mal schauen, wie er reagiert...
Grüße von
Yan
Viele Eurer Fragen kann ich gar nicht beantworten, da die Reparatur etc. ja durch unseren IT-Dienstleister durchgeführt wird. Ich warte noch auf die Aufstellung darüber, was genau schon versucht wurde bisher...
Der SQL-Spezialist, den ich im vorherigen Post genannt hatte, ist der Mitarbeiter des Herstellers der Software der betroffenen Datenbank. Daher fand ich es wichtig, ihn mit ins Boot zu nehmen.
Ich habe nun mal 2 Tests mit "chkdsk" gemacht, wie ja hier vorgeschlagen wurde.
Die Daten liegen auf "d:", aber ich habe Laufwerk "c:" auch noch prüfen lassen.
Es wurden aber offensichtlich keine Fehler gefunden.
Hier die Ergebnisse:
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. Alle Rechte vorbehalten.
C:\Users\Administrator.xxxxx>chkdsk d:
Der Typ des Dateisystems ist NTFS.
Die Volumebezeichnung lautet Daten.
WARNUNG! Der Parameter /F wurde nicht angegeben.
CHKDSK wird im schreibgeschützten Modus ausgeführt.
Phase 1: Die Basisdatei-Systemstruktur wird untersucht...
3072 Datensätze verarbeitet.
Dateiüberprüfung beendet.
0 große Datensätze verarbeitet.
0 ungültige Datensätze verarbeitet.
Phase 2: Die Dateinamenverknüpfung wird untersucht...
3152 Indexeinträge verarbeitet.
Indexüberprüfung beendet.
0 nicht indizierte Dateien überprüft.
0 nicht indizierte Dateien wiederhergestellt.
Phase 3: Sicherheitsbeschreibungen werden untersucht...
Überprüfung der Sicherheitsbeschreibungen beendet.
41 Datendateien verarbeitet.
CHKDSK überprüft USN-Journal...
13723856 USN-Bytes verarbeitet.
Die Überprüfung von USN-Journal ist abgeschlossen.
Dateisystem wurde überprüft, keine Probleme festgestellt.
Keine weiteren Aktionen erforderlich.
314569727 KB Speicherplatz auf dem Datenträger insgesamt
165707156 KB in 87 Dateien
52 KB in 42 Indizes
0 KB in fehlerhaften Sektoren
92463 KB vom System benutzt
65536 KB von der Protokolldatei belegt
148770056 KB auf dem Datenträger verfügbar
4096 Bytes in jeder Zuordnungseinheit
78642431 Zuordnungseinheiten auf dem Datenträger insgesamt
37192514 Zuordnungseinheiten auf dem Datenträger verfügbar...und hier nochmal mit Laufwerk C:\
C:\Users\Administrator.xxxxxxxx>chkdsk c:
Der Typ des Dateisystems ist NTFS.
WARNUNG! Der Parameter /F wurde nicht angegeben.
CHKDSK wird im schreibgeschützten Modus ausgeführt.
Phase 1: Die Basisdatei-Systemstruktur wird untersucht...
1260800 Datensätze verarbeitet.
Dateiüberprüfung beendet.
144139 große Datensätze verarbeitet.
0 ungültige Datensätze verarbeitet.
Phase 2: Die Dateinamenverknüpfung wird untersucht...
1584254 Indexeinträge verarbeitet.
Indexüberprüfung beendet.
0 nicht indizierte Dateien überprüft.
0 nicht indizierte Dateien wiederhergestellt.
Phase 3: Sicherheitsbeschreibungen werden untersucht...
Überprüfung der Sicherheitsbeschreibungen beendet.
161728 Datendateien verarbeitet.
CHKDSK überprüft USN-Journal...
41491184 USN-Bytes verarbeitet.
Die Überprüfung von USN-Journal ist abgeschlossen.
Dateisystem wurde überprüft, keine Probleme festgestellt.
Keine weiteren Aktionen erforderlich.
314057727 KB Speicherplatz auf dem Datenträger insgesamt
169979024 KB in 454365 Dateien
424300 KB in 161729 Indizes
0 KB in fehlerhaften Sektoren
1392275 KB vom System benutzt
65536 KB von der Protokolldatei belegt
142262128 KB auf dem Datenträger verfügbar
4096 Bytes in jeder Zuordnungseinheit
78514431 Zuordnungseinheiten auf dem Datenträger insgesamt
35565532 Zuordnungseinheiten auf dem Datenträger verfügbarDemnach scheint ja auf dem Dateisystem alles OK zu sein.
Ich habe übrigens eben den Inhalt Deines Postes (@MysticFoxDE) mal an meinen IT-Dienstleister weitergeleitet.
Habe ihm dann auch das Ergebnis der beiden "chkdsk"-Tests schon mitgeteilt.
Mal schauen, wie er reagiert...
Grüße von
Yan
So, ich habe jetzt eine Antwort des IT-Dienstleisters erhalten.
Er schreibt, dass sie aktuell zweigleisig fahren:
Überprüfung der VM und Versuch die DB Direkt zu sichern.
Da als Host ein ESXI im Einsatz ist, muss man über einen Wartungszugang per SSH arbeiten
Das Ergebnis:
Somit wird die virtuelle Festplatte eher als Ursache ausgeschlossen oder zumindest zurückgestellt, da sie von außen (vmkfstools) und von innen (chkdsk) geprüft wurde und beide die Fehlerfreiheit bestätigen.
Der Sicherungsversuch per Powershell gibt folgenden Fehler aus:
Das mal als Zwischenantwort.
Der IT-Dienstleister hat mit dem Datenbank-Spezialist bereits Kontakt aufgenommen.
Grüße von
Yan
Er schreibt, dass sie aktuell zweigleisig fahren:
Überprüfung der VM und Versuch die DB Direkt zu sichern.
Da als Host ein ESXI im Einsatz ist, muss man über einen Wartungszugang per SSH arbeiten
Das Ergebnis:
Somit wird die virtuelle Festplatte eher als Ursache ausgeschlossen oder zumindest zurückgestellt, da sie von außen (vmkfstools) und von innen (chkdsk) geprüft wurde und beide die Fehlerfreiheit bestätigen.
Der Sicherungsversuch per Powershell gibt folgenden Fehler aus:
Das mal als Zwischenantwort.
Der IT-Dienstleister hat mit dem Datenbank-Spezialist bereits Kontakt aufgenommen.
Grüße von
Yan
Moin @Yan2021,
leider nein, weil nicht richtiges vorgehen. 😔
https://www.diskinternals.com/vmfs-recovery/check-vmfs-metadata/
https://de.diskinternals.com/vmfs-recovery/fix-vmfs-corruption/
Und der sagt eigentlich genau das aus was ich vermutet habe, sprich dass die Daten korrupt/beschädigt sind. 😬
Welchen Storage-Typ habt ihr am ESXi hängen?
Lasst den SQL-Spezialisten noch in Ruhe, der kann bei diesem Problem nicht wirklich weiterhelfen.
Gruss Alex
Da als Host ein ESXI im Einsatz ist, muss man über einen Wartungszugang per SSH arbeiten
Das Ergebnis:
Somit wird die virtuelle Festplatte eher als Ursache ausgeschlossen oder zumindest zurückgestellt, da sie von außen (vmkfstools) und von innen (chkdsk) geprüft wurde und beide die Fehlerfreiheit bestätigen.
Das Ergebnis:
Somit wird die virtuelle Festplatte eher als Ursache ausgeschlossen oder zumindest zurückgestellt, da sie von außen (vmkfstools) und von innen (chkdsk) geprüft wurde und beide die Fehlerfreiheit bestätigen.
leider nein, weil nicht richtiges vorgehen. 😔
https://www.diskinternals.com/vmfs-recovery/check-vmfs-metadata/
https://de.diskinternals.com/vmfs-recovery/fix-vmfs-corruption/
Der Sicherungsversuch per Powershell gibt folgenden Fehler aus:
Und der sagt eigentlich genau das aus was ich vermutet habe, sprich dass die Daten korrupt/beschädigt sind. 😬
Welchen Storage-Typ habt ihr am ESXi hängen?
Der IT-Dienstleister hat mit dem Datenbank-Spezialist bereits Kontakt aufgenommen.
Lasst den SQL-Spezialisten noch in Ruhe, der kann bei diesem Problem nicht wirklich weiterhelfen.
Gruss Alex
Moin @Yan2021,
kannst du zu dem oberen Punkt vielleicht noch ein paar Takte mehr dazu sagen, denn hier liegt glaube ich der Hund begraben. 😔
Was für ein Speichersystem nutzt ihr an diesem ESXi Host und wie waren die Laufwerke in diesem konfiguriert, sprich, welches RAID Level mit wie vielen Laufwerken?
Denn meine Kristallkugel sagt bisher das Folgende.
Die Daten des ESXi liegen in einem RAID6 Verbund und bei diesem Verbund sind euch ohne das ihr das gemerkt habt nach und nach die HDD's kaputt gegangen und als die dritte rausgeflogen ist, ist das System stehen geblieben.
Dann habt ihr die HDD, die zuletzt herausgeflogen ist wieder Online erzwungen und danach ein Rebuild angestossen.
Ist das bis hierhin korrekt so?
Gruss Alex
Durch den Ausfall der 3 physischen Festplatten, welche kürzlich bei uns gewechselt wurden, ist die „virtuelle“ Festplatte des entspr. Servers beschädigt.
kannst du zu dem oberen Punkt vielleicht noch ein paar Takte mehr dazu sagen, denn hier liegt glaube ich der Hund begraben. 😔
Was für ein Speichersystem nutzt ihr an diesem ESXi Host und wie waren die Laufwerke in diesem konfiguriert, sprich, welches RAID Level mit wie vielen Laufwerken?
Denn meine Kristallkugel sagt bisher das Folgende.
Die Daten des ESXi liegen in einem RAID6 Verbund und bei diesem Verbund sind euch ohne das ihr das gemerkt habt nach und nach die HDD's kaputt gegangen und als die dritte rausgeflogen ist, ist das System stehen geblieben.
Dann habt ihr die HDD, die zuletzt herausgeflogen ist wieder Online erzwungen und danach ein Rebuild angestossen.
Ist das bis hierhin korrekt so?
Gruss Alex
Ich möchte noch einmal an dieser Stelle ganz deutlich sagen das meine hier genannten Ideen alle auf der Annahme basieren das
a) die Verantwortlichen Personen Kenntnis von dem Problem haben und sich der Gewichtigkeit der Situation bewusst sind und das
b) jegliche Rettungsversuche unter der Prämisse stehen, das bei der Datenrettung nur das absolut nötigste am betroffenen System gemacht wird.
Bisher wurde das System ja sogar noch produktiv genutzt, so lese ich das raus. Für mich absolut unverantwortlich, wenn ein Datenverlust mit schweren Konsequenzen einhergeht.
Wenn jetzt eine Kopie der ganzen VM irgendwo auf Dateisystemebene (des VM Storage) oder auf Storage Ebene scheitert, wenn jeglicher Kopierversuch im OS der VM scheitert, dann könnte "der SQL Spezialist" bzw. der Hersteller der Software sehr wohl einen guten Dienst erbringen. Da sich die VM und SQL ja starten lassen könnt ihr einen Defektfreien Server ins Netz stellen und alle SQL Tabellen, Daten, Trigger, Prozeduren, Funktionen, Berechtigungen etc. händisch kopieren. Über einen Verbindungsserver kann man so manuell mit ein wenig Zeit und Geduld sauber alles in eine neue Datenbank auf einer neuen Hardware übernehmen.
Ggf. müssen dann noch Daten von außerhalb des SQL kopiert übernommen werden, das ist klar. Dann wird die Software mit der Kopie der Daten neu aufgebaut - die alte Hardware wird nicht mehr produktiv eingesetzt.
a) die Verantwortlichen Personen Kenntnis von dem Problem haben und sich der Gewichtigkeit der Situation bewusst sind und das
b) jegliche Rettungsversuche unter der Prämisse stehen, das bei der Datenrettung nur das absolut nötigste am betroffenen System gemacht wird.
Bisher wurde das System ja sogar noch produktiv genutzt, so lese ich das raus. Für mich absolut unverantwortlich, wenn ein Datenverlust mit schweren Konsequenzen einhergeht.
Wenn jetzt eine Kopie der ganzen VM irgendwo auf Dateisystemebene (des VM Storage) oder auf Storage Ebene scheitert, wenn jeglicher Kopierversuch im OS der VM scheitert, dann könnte "der SQL Spezialist" bzw. der Hersteller der Software sehr wohl einen guten Dienst erbringen. Da sich die VM und SQL ja starten lassen könnt ihr einen Defektfreien Server ins Netz stellen und alle SQL Tabellen, Daten, Trigger, Prozeduren, Funktionen, Berechtigungen etc. händisch kopieren. Über einen Verbindungsserver kann man so manuell mit ein wenig Zeit und Geduld sauber alles in eine neue Datenbank auf einer neuen Hardware übernehmen.
Ggf. müssen dann noch Daten von außerhalb des SQL kopiert übernommen werden, das ist klar. Dann wird die Software mit der Kopie der Daten neu aufgebaut - die alte Hardware wird nicht mehr produktiv eingesetzt.
1
Moin @ukulele-7,
ja damit hast du absolut recht, aber das kann eine sehr aufwendige Rettungsmethode werden.
Daher habe ich bisher ja auch nur geschrieben, dass der TO den SQL-Spezialisten nicht mit der Lösung des CRC Fehler unnötig beschäftigen soll, weil er hierbei nicht wirklich helfen kann.
Wenn der Defekt auf den übergeordneten Storage-Ebenen jedoch irreparabel ist, dann bleibt das was du beschrieben hast, eh als Einziges noch übrig.
Gruss Alex
dann könnte "der SQL Spezialist" bzw. der Hersteller der Software sehr wohl einen guten Dienst erbringen. Da sich die VM und SQL ja starten lassen könnt ihr einen Defektfreien Server ins Netz stellen und alle SQL Tabellen, Daten, Trigger, Prozeduren, Funktionen, Berechtigungen etc. händisch kopieren. Über einen Verbindungsserver kann man so manuell mit ein wenig Zeit und Geduld sauber alles in eine neue Datenbank auf einer neuen Hardware übernehmen.
Ggf. müssen dann noch Daten von außerhalb des SQL kopiert übernommen werden, das ist klar. Dann wird die Software mit der Kopie der Daten neu aufgebaut - die alte Hardware wird nicht mehr produktiv eingesetzt.
Ggf. müssen dann noch Daten von außerhalb des SQL kopiert übernommen werden, das ist klar. Dann wird die Software mit der Kopie der Daten neu aufgebaut - die alte Hardware wird nicht mehr produktiv eingesetzt.
ja damit hast du absolut recht, aber das kann eine sehr aufwendige Rettungsmethode werden.
Daher habe ich bisher ja auch nur geschrieben, dass der TO den SQL-Spezialisten nicht mit der Lösung des CRC Fehler unnötig beschäftigen soll, weil er hierbei nicht wirklich helfen kann.
Wenn der Defekt auf den übergeordneten Storage-Ebenen jedoch irreparabel ist, dann bleibt das was du beschrieben hast, eh als Einziges noch übrig.
Gruss Alex
Mahlzeit Yan,
hast du mal einen Skript-Export der Datenbank getestet?
Damit könntest du wenigstens die Inhalte in Sicherheit bringen, falls der Export funktioniert. Es scheint ja, dass sich die Daten lesen lassen.
https://docs.telerik.com/devtools/aspnet-ajax/knowledge-base/common-impo ...
In jedem Fall scheint es ja so, als ob euer RAID eine Macke abbekommen hat - da würde ich mittelfristig einen Neuaufbau des RAID-Volumes empfehlen, bei darunterliegenden Hardwaredefekten wie in eurem Fall kann es sonst sein, dass du weitere Probleme in ähnlicher Form mitschleppst, die erst später auffallen.
Viele Grüße
mxrecord
hast du mal einen Skript-Export der Datenbank getestet?
Damit könntest du wenigstens die Inhalte in Sicherheit bringen, falls der Export funktioniert. Es scheint ja, dass sich die Daten lesen lassen.
https://docs.telerik.com/devtools/aspnet-ajax/knowledge-base/common-impo ...
In jedem Fall scheint es ja so, als ob euer RAID eine Macke abbekommen hat - da würde ich mittelfristig einen Neuaufbau des RAID-Volumes empfehlen, bei darunterliegenden Hardwaredefekten wie in eurem Fall kann es sonst sein, dass du weitere Probleme in ähnlicher Form mitschleppst, die erst später auffallen.
Viele Grüße
mxrecord