Firebird-Restore: auch ohne exclusiven Zugriff möglich?

[Lemmy]

nicht dass ich wüsste... Aber vielleicht erklärst Du ein paar Takte was das Problem ist bzw. für was das wichtig ist.
Möglich wäre: Restore mit einem anderen Namen, dann wäre die Downtime relativ kurz.... (2 Dateien umbenennen)

Grüße

[hoika]

Hallo Lemmy,
DB (+Firebird) ist auf dem Server (Zimmer abgeschlossen),
einer ist angemeldet auf dem Rechner im Zimmer.

Restore wäre notwendig, geht nicht, weil DB offen ...

[Delphi.Narium]

Monitoringtabellen von FireBird benutzen?

In MON$STATEMENTS stehen die laufenden SQL-Statements, in MON$ATTACHMENTS stehen die offenen Verbindungen.

Mit DELETE FROM MON$STATEMENTS WHERE MON$ATTACHMENT_ID = :ATTACHMENT_ID beendest Du ein laufendes Statement, mit DELETE FROM MON$ATTACHMENTS WHERE MON$ATTACHMENT_ID = :ATTACHMENT_ID beendest Du eine aktive Datenbankverbindung (jeweils ohne Rücksicht auf Verluste, ohne Nachfrage, ...)

Sinngemäß ungetestet hingedaddelt:

Delphi-Quellcode:

// Statement für das Löschen einer bestimmten Verbingung erstellen
qryExec.SQL.Text := 'DELETE FROM MON$ATTACHMENTS WHERE MON$ATTACHMENT_ID = :ATTACHMENT_ID; commit;';
// Alle Attachment_IDs zu offenen Verbindungen ermitteln, 
// sofern Du dich als letzter User an der DB angemeldet hast, 
// wird Deine eigene Verbindung zuletzt beendet.
// Oder halt die eigene ATTACHMENT_ID vorher ermitteln und per Where-Bedingung ausklammern.
qry.SQL.Text := 'select MON$ATTACHMENT_ID as ATTACHMENT_ID from MON$ATTACHMENTS order by MON$ATTACHMENT_ID';
qry.Open;
while not qry.EoF do begin
  qryExec.SQL.ParamByName('ATTACHMENT_ID').AsInteger := qry.FieldByName('ATTACHMENT_ID').AsInteger;
  qryExec.ExecSQL;
  qry.Next;
end;
qry.Close;

Damit sollten dann alle Datenbankverbindungen weg sein, einschließlich Deiner eigenen Verbindung.

Eventuell geht es ja auch mit

Delphi-Quellcode:

qryExec.SQL.Add('execute block as');
qryExec.SQL.Add('begin');
qryExec.SQL.Add('  DELETE FROM MON$ATTACHMENTS;');
qryExec.SQL.Add('  commit;');
qryExec.SQL.Add('end');
qryExec.SQL.ExecSQL;

Da damit dann auch die eigene Verbindung weg ist, könnte ein Try-Execpt drumrum nicht schaden

Und: Diese Lösung ist (wenn sie so funktioniert) garantiert äußerst grenzwertig

[lxo]

Du könntest auch einfach die Datenbank herunterfahren und damit alle Verbindungen trennen.

https://firebirdsql.org/rlsnotesh/rn...util-gfix.html

[himitsu]

Ja, natürlich kannst du zuerst mal alle offenen Connections trennen.
es sollte ein SQL geben, welche dir alle liefert, und dann damit das Disconnect.
https://stackoverflow.com/questions/...ip-in-firebird
https://www.firebirdfaq.org/faq10/
https://www.firebirdfaq.org/faq64/
firebird colse all active connections


Den DB-Inhalt als SQL-Text (CreateTable und Inserts und eventuell DeleteOhneWhere, falls Tabellen schon da sind) exportieren
(dafür eventuell es erstmal auf einer temporäten lokalen DB importieren/restoren)
und dann einfach das/die SQL-Scripte in der eigentlichen DM


Eventuell auch noch die Trigger und Checks disablen, damit nichts verändert wird und die Reihenfolge der Tabellen egal ist.

[IBExpert]

exklusiv ist beim restore immer erforderlich, weil u.a. auch die Systemtabellen neu erzeugt werden und beim restore am ende erst indizes erzeugt werden und trigger und foreign keys aktiviert werden und das darf nicht durch irgendwelche operationen vorher mit ungültigen daten das verhindern.

Früher (interbase <= 5.5) konnte man während des Restores schon an die Datenbank, war aber eine blöde idee, damit haben kunden dann zum Teil ihre db so zerstört, das eine reparatur ziemlich aufwändig bis unmöglich war.

Wichtig ist auch das beim Restore die Transaktionscounter resettet werden müssen und das kann man nicht mit altdaten mischen.

Was aber geht wenn es beim restore nicht um das Transaktionslimit geht (als next transaction in der datenbankstatistik von fb<=2.5 in der nähe von 2 Milliarden ist):
Nutze ein geeignetes Tool und mache einfach eine abgleich zwischen der restorten datenbank und deiner produktionsdatenbank
mir fällt da gerade das hier ein https://www.ibexpert.net/ibe/pmwiki....leDataComparer
das geht damit auch nur für von dir ausgewählte Tabellen und kann wenn Primärschlüssel oder unique constraints super gut auch insert/update/delete automatisch erkennen und teile der tabellen sogar durch extra where bedingungen in der ibeblock funktion https://www.ibexpert.net/ibe/index.p..._CompareTables nutzen

fazit aber: mit gbak zwingend exklusiv, während des restores kommst du gar nicht erst an die db mit einer zweiten connection, weil der restore im shutdown single user mode läuft, daher ist der hinweis auf die Mon$ Tabellen nicht hilfreich.

wenn es nur darum geht, das aktive Connections der restore verhinden, machst du am besten vorher ein shutdown mit gfix oder https://www.ibexpert.net/ibe/pmwiki....utdownDatabase, mit full shutdown werden alle user rausgeschmissen ob die wollen oder nicht und können sich auch nicht neu anmelden. danach geht das restore mit replace ziemlich sicher ohne probleme, ist aber wie oben geschildert bis zur fertigstellung auch im shutdown single user mode und keiner kann währenddessen an die daten.

[Delphi.Narium]

Zitat von IBExpert:

daher ist der hinweis auf die Mon$ Tabellen nicht hilfreich.

Wieso nicht?

Wenn ich gbak starte und 'ne Meldung bekomme, dass dies nicht möglich ist, weil nicht exklusiv zugegriffen werden kann, so kann ich in dieser Situation doch in die Mon$-Tabellen schauen und prüfen, ob noch Datenbankverbindungen bestehen.

Wenn ja, kann ich auch sehen, von welchem Client auf die Datenbank zugegriffen wird und statt die Verbindungen zu trennen, könnte ich auch den / die entsprechenden User bitten, ihre Datenbankverbindung zu beenden, um dann weiter arbeiten zu können.

Natürlich: Wenn (aus welchem Grund auch immer) kein Zugriff auf die Mon$-Tabellen möglich ist, hab' ich noch ein anderes Problem, als nur noch laufenden SQL-Statements oder einfach nicht beendete Datenbankverbindungen.

Aber bei nicht möglichem Exklusivzugriff für gbak, halte ich es durchaus für einen zielführenden Versuch, zuerst mal in die Mon$-Tabellen zu schauen, um zu ermitteln, was da ggfls. den Exklusivzugriff verhindert. Es könnte ja durchaus die Möglichkeit bestehen, dass da noch sinnvolle Arbeiten auf der Datenbank ausgeführt werden und ein hartes Beenden der SQL-Statements bzw. der Datenbankverbindungen ggfls. eher geschäftsschädigende Auswirkungen nach sich ziehen könnte.