Maildatenbank vom User (Editor) per Button komprimieren lassen

[Steffen]

Wer kennt es nicht:
Die User haben eine Mailquota, lediglich Editorrechte auf der DB und die Komprimierung findet über Nacht statt. (oder zumind. nicht jetzt sofort wo sie Termine einstellen müssen oder sonst irgendetwas)

Man könnte doch bestimmt einen Button in sagen wir einer vorhandenen Infodatenbank zur Verfügung stellen. Dieser müsste automatisch im Namen des Servers die Datenbank auf Knopfdruck komprimieren. -> oder ist das nur bei Agenten möglich?

Hat das schonmal jemand gemacht oder im Einsatz? Was haltet ihr davon?

Grüße
Steffen

[ascabg]

Hallo,

Darf ich einmal fragen wozu?


Andreas

[Steffen]

Hallo Andreas,

ich meine die Idee an sich. Einen Code selbst für den Knopf hab ich leider ja noch nicht, aber vielleicht hat ja schonjemand dieses Rad mal erfunden?

Grüße
Steffen

[klaussal]

Der Server komprimiert sowieso, wann er will bzw. Zeit dazu hat. Ein Knopf bringt m.E. nix.

[Steffen]

Ich habe mich scheinbar nicht klar genug ausgedrückt, sorry dafür:
Es geht mir um die Datenbankkomprimierung der Maildatenbank des Benutzers die "zu voll ist".
Da der compact nur Nachts bei uns eingestellt ist, komprimiert er auch nur dann.
Der Server macht da mal gar nichts von selbst, nur wann wir den compactbefehl über die DBs laufen lassen. -> die Option alle 5 Stunden find ich auch nicht gut, da die Anrufer ja meißt -sofort- wieder was machen wollen -> grade bei Terminen die eingestellt werden müssen kann ich das gut verstehen ;-)

Also es geht um einen compact auf die MailDB des Users und eine Möglichkeit des Users diese zu komprimieren. (und das mit Editorrechten auf der Datenbank)

[ascabg]

Und das Problem dabei ist, dass Du mit dem Code auch nur eine Anforderung an den Server erstellst, die betreffende DB zu komprimieren.

Ab dann ist es Sache des Servers.
Und wie klauss schon schrieb, dass tut er wann er Zeit dazu hat und er dabei nicht gestoert wird.
(was im laufenden Betrieb, wenn der Anwender noch darin arbeitet, eher unwahrscheinlich ist)


Andreas

[HH]

Bleibt dann noch das Problem, dass der compact-Befehlt auf einen Fehler laufen wird, wenn die Datenbank durch den User geöffnet ist (oder noch im Server-Cache geöffnet ist). Das geplante Vorgehen halte ich für nicht praktikabel.

Ich gehe einmal davon aus, dass auf das Überschreiten der Datenbankgröße durch einen entsprechenden Warnschwellenwert hingewiesen wird.

Wer diese Meldung permanent ignoriert, muss einfach bestraft werden!

Hubert

[Klafu]

Jetzt muss ich doch mal was dazu schreiben.
Ich bekomm auch oft mit, das bei Usern die Mail DB voll ist und dann rufen sie an.
Ein kurzer Compact -b dannach -B und keine 2-3 Minuten später läuft alles.
Da ist es egal, ob der User grad in der DB drin ist. Der Server führt das auch immer direkt aus.

Mir fehlt aber auch die Funktion, das der User das selber macht/Notes den Speicher nach löschen der Mail wieder frei gibt.

Chris

[Steffen]

Ich stimme da Klafu voll und ganz zu, das passiert immer öfter (weils nun mal immer mehr wird bei den Personen) und ein Bestrafen hin oder her, Termine einstellen muß ermöglicht werden, sonst werd ich irgendwann bestraft von ganz oben.....
Und das geht ja auch wenn er anruft, man setzt auf der Konsole einen compact ab oder macht es im Admin oder mit der DB auf der Oberfläche, aber das ist ja eigentlich keine Lösung, denn die Anforderungen werden immer mehr und müssen sofort erledigt werden, welcher Mitarbeiter wartet schon auf diese Anrufe und hat sonst nichts zu tun....
Also wenn es die Möglichkeit gibt den Befehl abzusetzen, denke ich es müsste von Server zumind. in 1-5 Minuten erledigt sein, zumind. hat es noch nie länger gedauert wenn ich es -mitten im Betrieb- angestoßen habe.

[ascabg]

Nun doch noch einmal ein Frage von meiner Seite.

Von welcher "Quota" reden wir?

Der "Warning-Size" oder der realen "Quota".

Durch das Setzen der "Warning" auf einen realen/treffenden Wert, wird der Anwedner doch schon rechtzeitig genug daran erinnert, dass seine Mailbox sich der kritischen Groesse naehert und er etwas dagegen unternehmen soll.

Wenn er es nicht tut, dann muss er auch gegebenenfalls mit den daraus resultierenden Konsequenzen leben.
- wie immer werden hier die VIP's natuerlich ausgenommen  -

Andreas

[Steffen]

Die angesprochene Kalendersituation, also dass die Berater keine Termine mehr eintragen können  kommt wenn der User über der Quota, also der maximal eingestellten Größe für seine MailDB kommt.
Der Warnungsschwellwert ist ja nur ne Info die bei uns 10% vorm "Ende" kommt. Da aber wenige PPTs, ein Urlaub, eine Krankheit oder sonstwas schon ausreichend sind um diese 10% zu "überspringen" ist das auch keine absolute Ausrede für die Nichtfunktion danach.
Meins Erachtens kann ich das mit dem Nichtspeichern im Gesendet noch vertreten als "Strafe" aber das Nichtspeichern der Termine, das geht gar nicht und braucht unbedingt eine schnelle einfache Lösung. (das Heraufsetzen der Quotas ist nur eine Lösung auf Zeit wie wir alle wissen  )

[Pidray]

Hmmm, ich habe zwar diesen Thread nur flüchtig überflogen, aber ...

reicht es denn nicht, auf dem Arbeitsbereich -> Datenbank-Eigenschaft INFO den Komprimieren-Button zu nutzen ?

LG
Katrin

[ascabg]

@Pidray (Katrin)

Den hat man aber nur dann zur Verfuegung, wenn man hoehere Rechte als die Anwender - in diesem Fall Editor - haben.


Andreas

[Pidray]

@Andreas

hoehere Rechte als die Anwender - in diesem Fall Editor -

axo;
bei uns hat jeder User Manager-Rechte auf seine eigene Maildatei ...

Gruß
Katrin

[ascabg]

Was aber lt. IBM seit Version 6 nicht mehr notwendig ist, da die Punkte, die hoehere Rechte erfordern, z.B. ACL anpassen wegen Vertreterregelung, durch die Anwender ueber Admin-Requests an den Server abgegeben werden.


Andreas

[Banni]

Hallo,

@Steffen
Ich hab so ein bißchen den Eindruck, daß Du Dich von den Usern in ihrer Mail-Sammelwut "erpressen" läßt. Du wirst nicht umhinkommen, irgndein Kompromiß finden zu müssen, bei dem die User mit im Boot sind.

Du sagst selbst, Quotaerhöhung oder auch Entfernen der Quota kann nur eine temporäre Lösung sein. Da geb ich Dir Recht, schließlich gibt es ja die Chefs, die dann immer gleich die "Kostenkeule" rausholen, falls 'ne neue Festplatte nötig wird.
Wenn allerdings bei einem Warnschwellenwert 10% unter der Quota schon ein paar Mails reichen um die Quota zu sprengen, sollt man vielleicht drüber nachdenken, ob die Quota nicht doch zu klein bemessen ist oder man den Warnschwellenwert oberhalb der 10% ansiedeln sollte.

Wie auch immer, die User müssen auch begreifen, daß die Mail-DB kein "Mülleimer" ist, der unbegrenztes Fassungsvermögen hat.

Gruß Jan

[Wolfgang]

Hallo Steffen,

wenn Du Transaction Logging einsetzt, kannst Du das Ganze so konfigurieren, dass der Server die tatsächlich verwendete Größe der Mail-DB prüft.

Beispiel:
Mailquota von 100 MB erreicht.
User löscht 10 MB aus seiner Mail-DB (und leert den Papierkorb!).
Beim nächsten Zustellversuch erkennt der Router, dass von der 100 MB großen Datenbank effektiv nur 90 MB genutzt werden und stellt wieder Mails zu. Da muss zwischendurch überhaupt nicht komprimiert werden. Das ist meiner Meinung nach die beste und schnellste Lösung für Dein Problem.

Ergänzung: Setzt man Transaction Logging ein, funktioniert die Schaltfläche "Komprimieren" nicht mehr, auch wenn der User Manager der DB ist. Das ist jedoch beabsichtigt, da das Komprimieren Einfluss auf die Komplettsicherung der DB hat.

Gruß
Wolfgang