compact -c locked die Datenbank anscheinend nicht

[SD]

Hallo allerseits,

vielleicht kann mir ja hier jemand einen Tipp geben, was ich falsch mache.

Ich habe hier die ein oder andere etwas größere Maildatenbank (~10GB), bei denen ich gerne mal einen compact -c machen würde. Leider scheitere ich bisher jedes Mal wegen "Compaction of the database was stopped prematurely because another user modified it while it was being compacted.". Ich habe den compact auch schon getimed, dass er irgendwann mitten in der Nacht läuft, hilft aber auch nichts. Der compact läuft so lange, dass immer irgendwas ist, das ihn abbricht.

Eiiiigentlich war ich aber der Meinung der compact -c müsste die Datenbank locken, sodass andere Prozess gar nicht mehr draufkommen, um irgendwas zu verändern. Irgendwas tut es aber trotzdem und bringt den compact jedes Mal zu Abbruch.

Was ich sagen kann, ist dass es ein 8.5.2FP3 Server ohne Cluster ist, mit DAOS und LZ1 aktiv. Kann mir das dazwischenfunken? Kann ich das irgendwie erzwingen, dass die Datenbank in Ruhe gelassen wird, solange der compact läuft? (am besten ohne den ganzen Server herunterfahren zu müssen )

[eknori]

versuche mal compact -c -L

Enables users to continue to access databases during compacting. If a user edits a database during compacting, compacting is cancelled. Useful only when copy-style compacting is done.​

Ich bin mir nicht sicher, wie der Satz genau zu verstehen ist.

1. Mit diesem Parameter bricht der compact ab, wenn ein User zugreift
2. User kann zugreifen, aber der compact läuft weiter. Ohne den Parameter kann User nicht zugreifen

Wenn 1, dann bedeutet das ja im Umkehrschluss, daß ohne den Parameter kein User zugreifen kann, solange der Compact läuft ( was logisch wäre ). Ist das korrekt, dann gibt es offensichtlich einen Bug. 

[SD]

Damit habe ich den selben Abbruch. Bei dem Versuch eben war es, so wie es aussieht, eine einkommende Mail, die zum Abbruch geführt hat.

Normalerweise kommt bei einem reinen -c kein User mehr auf die Datenbank. Das funktioniert auch, eben nochmal getestet. Aber andere Prozesse, wie z.B. der Router, können offenbar trotzdem noch drauf und pfuschen dann auch während dem compact in den Daten rum. Ich hatte auch mal an einem Abend den Router gestoppt, aber irgendwas hat den compact trotzdem abgebrochen. Ich hatte auch schon den Indexer im Verdacht. Keine Ahnung, ob der einen compact -c zum Abbruch bringen kann.

 

[eknori]

Tjo, dann erstelle mal bei IBM einen SPR

[elektron]

Hallo,

wenn ich tagsüber ein Mailfile komprimieren will, nehme ich load compact -B -T
Das funktioniert dann ohne Abbruch.

Gruss
Toralf

[MCPvsTron]

@Toralf,   -B komprimiert aber in Place, das locked die Datenbank nicht, -T aktiviert Transaction Logging und hat mit dem Problem nichts zu tun.

Das von dem Thread Ersteller beschriebene Verhalten ist mir aber auch neu, wir haben allerdings kein DAOS im Einsatz, die LZ1 Komprimierung sollte damit eigentlich nichts zu tun haben.

VG
Christian

[SD]

Witzigerweise scheint ein compact -B die Datenbank bei mir tatsächlich zu locken. Beim Eingang einer neuen Mail kommt dabei:

Router: Unable to deliver message 004A252F, 004A22EB to xyz from abc
Operation cannot be performed at the current time - database compaction in progress.

Transaction logging ist bereits aktiv, das hatte ich noch vergessen.

Tja, dann werde ich wohl mal IBM von meinem Paralleluniversum erzählen müssen, wo alles genau andersrum ist, als es sein sollte.
Danke für die Tipps auf jeden Fall mal.

[Pfefferminz-T]

Moin,

in einem OpenMic-Call im März 2011 wurde das mit dem compact -c auch angesprochen. Anscheinend kommt es in Einzelfällen wirklich zum Anhalten des compact-Tasks, wenn eine Mail für diese Datenbank einläuft. Als Lösung wurde nur der offline-Compact genannt, den ich bei dieser Datenbankgrösse sowieso empfehlen würde da die Last für den Server wahrscheinlich relativ hoch wird und der Compact "etwas" länger laufen wird...

Grüsse,
Thorsten