RECOVER in eine neue Datenbank die bereits gefüllt wird?

[kandalf]

Hallo zusammen,

habe da mal eine Frage zum Datenbankrecover.
Da ich derzeit einige Probleme mit gecrashten Datenbankdateien habe und die bei Produktivsystemen echt übel ist denke ich über einen Mechanismus nach der diesen Zustand automatisch repariert möglichst ohne Datenverlust.

Da bei unserem System zyklisch neue Daten kommen die eingefügt werden müssen kann ich nicht mal eben das System für einige Zeit anhalten um ein Backup/Restore durchzuführen.
Alle Daten die eingefügt werden müssen verwalte ich intern in einer QUEUE. Ich habe also die Möglichkeit, die Inserts für eine gewissen Zeit anzuhalten um sie dann nachzuholen.
Nun habe ich mit folgendes überlegt:
Sollte ich bei der Fehlerauswertung feststellen, dass die Datenbank corrupt ist dann könnte ich einen Notfallvorgang anstossen.
- Alle aktiven Verbindungen stoppen
- Datenbankdatei umbennen, direkt eine aktuelle neue leere erstellen.
- Alle Verbindungen wieder starten und die Daten in der Queue wieder einfügen
- Nun ein Backup der defekten umbenannten Datei durchführen.

So, nun kommt es. Könnte ich nun die Daten in dieser Backupdatei direkt in die neue bereits mit weiteren Daten gefüllten Datei einfügen?
Ich bräuchte also nicht diese ganzen META Daten sondern nur die reinen Inserts pro Tabelle!

Kann mir jemand von Euch dazu einen Tip geben oder erklären wie da ein vernünftiger Vorgang aussehen würde?

[Heiko Luettge]

Hallo,

zuerst mal solltest du feststellen, wie so die DB crasht.

Aber zu deiner Frage selbst:
Wenn du noch an die Generatoren rankommen könntest, mit denen du deine Primärschlüssel erzeugst, könntest du in der neuen leeren DB einfach die Generatoren schon vor dem ersten neuen Insert höher setzen (set generator gen_XXX to 1000000 zum Bsp.)
Zum Einfügen der alten Daten schreibst du dir entweder ein kleines Tool (select * from tab1 (db_alt) und insert in die neue DB), das ganze über alle Tabellen
oder manuell geht es auch über IBDataPump.

Übrigens muss für ein reines Backup das System nicht angehalten werden.
Du könntest aso auch alle 30min ein Backup zur Sicherheit machen und hättest dann "nur" 30min Datenverlust im Ernstfall.


Heiko

[kandalf]

Hallo,

zuerst mal solltest du feststellen, wie so die DB crasht.

Ich bin ja auf der Suche, muss parallel aber auf jeden Fall schon mal eine Notlösung erstellen.

Aber zu deiner Frage selbst:
Wenn du noch an die Generatoren rankommen könntest, mit denen du deine Primärschlüssel erzeugst, könntest du in der neuen leeren DB einfach die Generatoren schon vor dem ersten neuen Insert höher setzen (set generator gen_XXX to 1000000 zum Bsp.)
Zum Einfügen der alten Daten schreibst du dir entweder ein kleines Tool (select * from tab1 (db_alt) und insert in die neue DB), das ganze über alle Tabellen
oder manuell geht es auch über IBDataPump.

Ich verwende keine IB Tools sondern reinen C-API Zugriff.
Gibt es mit dem Tool gbak die Möglichkeit nur die Inserts aus einer Backupdatei durchzuführen?
An die ID's komme ich denke ich noch ran. Die wollte ich mir dann in einer internen Struktur merken und dann bei der neuen Datenbank direkt setzen. Das war auch mein Plan.

Übrigens muss für ein reines Backup das System nicht angehalten werden.
Du könntest aso auch alle 30min ein Backup zur Sicherheit machen und hättest dann "nur" 30min Datenverlust im Ernstfall.
Heiko

Ja, das weiß ich. Ich habe auch ein Backup drin was ich per Schalter aktivieren könnte. Zyklisch einmal in der Nacht. Alle 30 Minuten ist unmöglich.
Wir haben Systeme die besondere Last beim Einfügen erzeugen und seltener per Abfragen. Es kommt vor, dass wir hier von 100-200 Inserts pro Sekunde sprechen und in Sonderfällen zeitweise noch höher.
Wie gesagt es handelt sich um recht sensible Daten und da ist jeden Verlust sehr schmerzhaft. Wir haben zwar immer alle Daten noch auf einer Partition ohne Filesystem aber ein Recover von dort dauert recht lange und ist nur für Notfälle gedacht.