Vollständiger Ex- und Import wegen fehlerhafter Datenbank - Reihenfolge?

[Dejotler]

Hallo,

die Datenbank ist fehlerhaft und kann nicht repariert werden.
Es muss also alles, wirklich alles an Daten aus der alten Datenbank ex- und in die neue Datenbank importiert werden.
Per Ameise.

Welche Reihenfolge muss hier eingehalten werden, damit die Aktion gelingt?


Vielen Dank und schönen Gruß,


Boris

 

[mh1]

die Datenbank ist fehlerhaft und kann nicht repariert werden.
Es muss also alles, wirklich alles an Daten aus der alten Datenbank ex- und in die neue Datenbank importiert werden.

Was ist denn fehlerhaft, bzw. was bringt dich zu dem Schluss, dass alles exportiert werden muss (KÖNNTE denn überhaupt - angesichts des offensichtlich bereits analysierten Fehlers - noch was exportiert werden)?

 

[Dejotler]

Hi Michael,

der Servicepartner sagt, dass unicorn 2 sich so in die Datenbank eingemischt hat, dass diese irreparabel beschädigt ist. Es gab Versuche, zu reparieren, aber es hilft nichts: Es muss eine neue Datenbank her und alles übertragen werden.
Wie es aussieht, kann die Ameise arbeiten.

 

[John]

Wende Dich mal an Robert Wall von T4DT GmbH @T4DT.GmbH - der hat wohl mit am meisten Erfahrung und kann vielleicht retten bzw. mit Export/Import helfen.

https://t4dt.com/

 

[Dejotler]

Unten ist ein Screenshot der Fehlermeldung aus der Datenbank. Eine genauere Meldung gibt es leider nicht.

Es wurde eine neue Instanz erstellt um ein Backup der Datenbank dort einzupflegen und eine Datenbank Reparatur durchgeführt, im Anschluss dann sogar eine DB Reparatur mit Allow Data Loss versucht in der Testinstanz, leider ohne Erfolg. Zuletzt wurde versucht in eine neue Instanz nur die mdf und die ldf zu importieren, was den Fehler aber auch mit übernommen hat. Damit waren alle internen Möglichkeiten zur Reparatur ausgeschöpft.

Das Problem wurde mir kurz so erklärt: Die SQL Datenbank weiß von einer Objekt ID in einer Spalte, welche aber nicht mehr zu existieren scheint.

 

[mh1]

Du kannst ja mal im Management Studio mit "Generate Scripts" zwei Skripte erzeugen lassen: Einmal das Schema und einmal nur die Daten

Dann in deiner Testinstanz das Schema der eazybusiness erzeugen lassen mit dem ersten Skript.

Und aber dann bevor du das Skript mit den Daten einspielst, alle Constaraints und alle Trigger in allen Tabellen temporär deaktivieren
Sowas in der Art:

sp_msforeachtable @command1="print '?'", @command2= "ALTER TABLE ? NOCHECK CONSTRAINT all"
sp_msforeachtable @command1="print '?'", @command2="ALTER TABLE ? DISABLE TRIGGER  all"

Dann das Skript mit den Daten einspielen und danach wieder alle Constraints und Trigger aktivieren. Also wie oben nur CHECK CONSTRAINT all und ENABLE TRIGGER all

Ich habe das Vorgehen aber nicht getestet. Das ist jetzt nur so eine Idee, wie ich es probieren würde...

Überleg dir aber, wie du nachher die Inhalte deiner neuen DB prüfen kannst.
Evtl. stichprobenhaft eine Summe über alle Rechnungen aus der alten DB mit der gleichen Checksumme aus der neuen DB vergleichen. Und andere Prüfungen...