Datenbank ist read-only nach nbackup lock

[romankassebaum]

Hallo zusammen,

ich sichere eine Datenbank mit nbackup. Dazu nutze ich die Option -L, die die Datenbank locked. Nach dem locken kopiere ich die Datenbank und unlocke sie (-N).

Obwohl die Firebird-Dokumentation sagt, dass die Datenbank weiterhin beschreibbar ist (“Locking” means here that the main database file is frozen temporarily, not that no changes can be made to the database), bekomme ich eine Fehlermeldung (no permission for read-write access to database), falls ich mich während des Kopiervorgangs mit der Datenbank verbinde.

Hat jemand eine Idee, wo das Problem liegen könnte?

--
Roman

[tsteinmaurer]

Hallo Roman,

das sollte schon klappen. Wenn sich eine Datenbank im Locked Zustand befindet, dann werden Änderungen nach dem -L in ein oder mehrere Delta-Files geschrieben dann beim -N wieder mit der Hauptdatenbankdatei gemerged werden.

Ich kann das auch nicht wirklich so nachstellen, d.h. bei mir funktioniert es. Es gibt zwar die Möglichkeit, dass man den Ort für die Delta-Files ändert und hiermit ev. in ein Berechtigungsproblem auf Dateisystemebene reinfällt, aber ich bezweifle, dass du etwas in diese Richtung gemacht hast? http://www.firebirdsql.org/manual/nb...deltafile.html

Ist das unter Windows oder Linux?

[romankassebaum]

Hallo Thomas,

mir sind drei Dinge aufgefallen.

1. Das Sweep-Intervall ist 0, Sweepen wird manuell in der Nacht aufgerufen. Das sollte eigentlich keine Auswirkungen haben.
2. Der Server ist ein Windows 2008 Server. Dadurch hat Firebird standardmäßig den direkten Zugriff auf die Datenbank (-D on). Das sollte aber auch kein Problem an.
3. Es ist keine Deltadatei definiert. Ich habe bisher gedacht, dass die Deltadatei automatisch definiert ist. Ich habe das jetzt einmal nachgeholt (alter database add difference file 'path-and-filename').

--
Vielen Dank,

Roman

[tsteinmaurer]

Die Delta-Datei, sofern nicht anders angegeben, kommt in das selbe Verzeichnis wie die Datenbankdatei. Das sollte eigentlich nicht der Grund sein. Kann es sein, dass vielleicht dein Kopier/Backup-Tool die Datei dann auf Read-Only setzt?

[romankassebaum]

Hallo Thomas,

Du hast Recht, das Kopiertool verursacht das Problem. Ich kopiere mit der Copy File Action des FinalBuilder Server. Stattdessen versuche ich jetzt die Robocopy Action.

--
Vielen Dank,

Roman

[romankassebaum]

Robocopy geht auch nicht, ich habe jetzt ein selbst geschriebenes Tool genommen, welches funktioniert. :)

--
Roman

[tsteinmaurer]

:thumb:

[Uwe Raabe]

Sollte das nicht direkt in Firebird abgefangen werden? Immerhin erwähnt die Dokumentation, daß eine gelockte Datei beliebig kopiert werden kann. Wenn nun einige anerkannte Kopiermechanismen diese Datei während des Kopiervorgangs als Read-Only markieren (was ja durchaus angemessen ist), dann sollte Firebird damit umgehen können.

[tsteinmaurer]

Hallo Uwe,

ich denke, wir sprechen hier von dem Read-Only Attribut auf OS Dateiebene und nicht von dem FB-spezifischen Read-Only Flag.

lg,
Thomas

[Uwe Raabe]

Zitat:

Zitat von tsteinmaurer (Beitrag 1196467)

ich denke, wir sprechen hier von dem Read-Only Attribut auf OS Dateiebene und nicht von dem FB-spezifischen Read-Only Flag.

Genau das meine ich ja. Irgendwo in Firebird wird ja auf Read-Only abgeprüft und offenbar eine neue Verbindung verweigert. Dies sollte aber problemlos möglich sein, da Firbird auf die gelockte Datei ja sowieso nicht schreiben will. Insofern sollte ein Read-Only Flag auf OS-Ebene bei einer gelockten Datei auch durchaus zulässig sein.

Ich weiß nicht, welche Funktion die Finalbuilder Action benutzt (vermutlich ein simples CopyFile), aber RoboCopy ist nun nicht so ungewöhnlich als Backup-Lösung. Es gibt m.W. auch keine Option, mit der man das Setzen des Read-Only Attributs verhindern kann.

Das in diesem durchaus plausiblen Fall eine Fehlermeldung beim Verbinden mit Firebird kommt, ist zumindest etwas unerwartet.