MSSQL 2000 Recovery aus Transaktions Log

[patricks82 10]

Hallo,

 

ich habe ein Problem.

Eine SQL Datenbank ist uns zusammengebrochen (harter Serverneustart :/) und nu sitz ich da, da leider kein Backup vorhanden ist (doof ich weiss).

Nun ist die db_log.ldf groß und laut einem externen Tool (ASPEXSQL) auch ok.

Nur wie kann ich aus der Log die DB wiederherstellen?

 

Mit ASPEXSql Log gehts zwar, allerdings kostet eine Lizenz genug Geld.. und bevor ich diesen Schritt wage, wollte ich fragen obs auch Hausmittel gibt?

[Olmi 10]

Im EnterpriseManager steht deine DB dann wohl als "Fehlerverdächtig" da.

 

Also vorab, die .ldf wird dir nicht viel bringen.

 

Beschreib mal ein wenig, was der Enterprise so sagt.

Oder fährt der ganze SQL nicht mehr hoch?

 

Wolfgang

[Cybquest 36]

Ist es sicher, dass die Datenbankdatei defekt ist?

Sollte im EM "Fehlerverdächtig" stehen, kann evtl. auch folgendes helfen (bei mir hat's damals funktioniert):

 

Versions: SS7 Level: Intermediate

Author: The VB2TheMax Team

At times a database appears to be marked as "suspect" in the Enterprise Manager. SQL Server marks a database as suspect with it can't access the database. What happens at a low level is that SQL Server sets one of the bits in the status field in the sysdatabases table.

 

In general, this problem has no trivial solution. A simpler case occurs when the file that hosts the database is renamed from the command prompt or Windows Explorer. In this case, you just have to restore the original file name and then manually restore the bit in the status field with this command:

 

update sysdatabases

set status = status & ~256

where name = 'MySuspectDatabase'

 

Keep in mind that the command above can be successful only after enabling writing to system tables.

When the error isn't so trivial, you should check the error log to determine whether a restore operation is possible. However, when the data in the transaction log has been damaged, the restore procedure can hardly succeed. In this case the best solution is to restore the database from a recent backup. When this isn't possible, you should bring SQL Server in the so-called emergency mode. This state is entered by setting a bit in the status field in the sysdatabases table. The docs in the Books On Line report that you must OR the field contents with the value 32768, but the correct value is -32768. Thus, this is the command you need:

 

update sysdatabases

set status = status | -32768

where name = 'MioSuspectDatabase'

 

After this command you must stop and restart the SQL Server service. The Emergency Mode prevents SQL Server from restoring the suspect database, which now appears to be available. If the database is now accessible, you should be able to read data using standard techniques, such as a bulkcopy command or SELECT INTO commands.

 

...hab ich mal irgendwo im Internetz gefunden und aufgehoben.

[patricks82 10]

Kann das Problem nun etwas einschränken.

 

Und zwar wurden Einträge per Hand gelöscht. Die DB selbst ist in Ordnung und wird im Enterprise Manager als OK dargestellt.

Kann ich aus der Log die gelöschten Einträge wiederherstellen? :)

[Olmi 10]

Hm, wenn die Transaktionen abgeschlossen waren, wovon ich ausgehe, dann sind sie weg.

 

Bevor Du aber jetzt irgendwelche Aktionen unternimmst, erstelle bitte ein Dumpfile! Am besten noch mit einem Zeitplan damit das regelmäßig erfolgt.

 

Aus dem Logfile Daten rausholen..., unter diesen Umständen würde ich mich gedanklich lieber mit anderen Dingen auseinander setzen.

 

Wolfgang

[Cybquest 36]

Glaub ich nicht, dass das ohne ein Backup geht. In der Log steht ja zum Löschzeitpunkt i.Allg. nicht der entspr. Datensatz, sondern nur der Löschbefehl.

[patricks82 10]

Hm, wenn die Transaktionen abgeschlossen waren, wovon ich ausgehe, dann sind sie weg.

 

Bevor Du aber jetzt irgendwelche Aktionen unternimmst, erstelle bitte ein Dumpfile! Am besten noch mit einem Zeitplan damit das regelmäßig erfolgt.

 

Aus dem Logfile Daten rausholen..., unter diesen Umständen würde ich mich gedanklich lieber mit anderen Dingen auseinander setzen.

 

Wolfgang

 

Sicherung ist eingerichtet, natürlich zu spät. Was weiter folgt bleibt anderen Leute überlassen. Meine Aufgabe ist es die Daten schnell wiederherzustellen.

Mit dem oben gen. Programm habe ich ja die Möglichkeit, anhand der Trans. Log die Daten einzusehen. Es wird doch mit Bordmitteln irgendwie möglich sein.

[Cybquest 36]

In den Logs stehen ja nicht die Daten, sondern die Transaktionen.

D.h. du müsstest den (die) Zeitpunkt(e) finden, an dem die gelöschten Daten erzeugt worden sind und die betreffenden INSERTs lokalisieren.

[Olmi 10]

Naja, Paddy,

 

Cybquest und ich stimmen da astrein überein.

Wenn Sicherungen vorliegen würden gäbe es die eine oder andere Möglichkeit. In dem Fall dann aber auch die Möglichkeit einer inkonsistenten Datenbank.

 

Wie dem auch sei. Ab jetzt wird alles anders. :)

 

Wolfgang

[patricks82 10]

In den Logs stehen ja nicht die Daten, sondern die Transaktionen.

D.h. du müsstest den (die) Zeitpunkt(e) finden, an dem die gelöschten Daten erzeugt worden sind und die betreffenden INSERTs lokalisieren.

 

Wie kann ich die LDF ansehen.. ist ja mal wieder properitär :/

[Cybquest 36]

Wie kann ich die LDF ansehen.. ist ja mal wieder properitär :/

 

...hast Du doch oben schon selber beantwortet: APEXSQL...

Oder sowas wie "Lumigent Log Explorer" für 1000$... einfach mal googeln.

[patricks82 10]

...hast Du doch oben schon selber beantwortet: APEXSQL...

Oder sowas wie "Lumigent Log Explorer" für 1000$... einfach mal googeln.

 

Wird meinem Chef wohl nix anderes übrig bleiben.

Teures "Versehen".

 

Danke für die Antworten.