
Gibt's ne Möglichkeit via genericAgent alte, geschlossene Tickets zu löschen, die GRÖSSER als z.B. 2MB sind -- dabei handelt es sich immer um irgendwelche PDFs die meine User mitschicken und die DB zumüllen. Ideen? -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12200 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 Ralf.Hildebrandt@charite.de | http://www.charite.de

Gibt's ne Möglichkeit via genericAgent alte, geschlossene Tickets zu löschen, die GRÖSSER als z.B. 2MB sind -- dabei handelt es sich immer um irgendwelche PDFs die meine User mitschicken und die DB zumüllen.
Hi Ralph, 2 ansätze: * tickets mit den großen attachments löschen * nur attachments löschen (umstellung auf attachmentstorage=filesystem: (find-script auf filesize-basis löscht dann die dateien => inkonsistenzen in der db?)) evaluierung: speicherplatz, anzahl an attachments, größtes attachment, Select sum(CAST(content_size AS UNSIGNED )), count(CAST(content_size AS UNSIGNED )), max(CAST(content_size AS UNSIGNED )) FROM `article_attachment` WHERE CAST(content_size AS UNSIGNED ) > 2097152; Bei mir macht das bei bezogen auf die größe der article_attachment tabelle: 2mb ca. 15% einsparung, jedoch ist bei mir die article_plain ja fast genauso groß ... würd mich interessieren was dabei rauskommt, da ich das ggf. auch noch weiter verwenden könnte bzw möchte. Lg josy

* it-news (Josef Lahmer)
Gibt's ne Möglichkeit via genericAgent alte, geschlossene Tickets zu löschen, die GRÖSSER als z.B. 2MB sind -- dabei handelt es sich immer um irgendwelche PDFs die meine User mitschicken und die DB zumüllen.
Hi Ralph,
2 ansätze: * tickets mit den großen attachments löschen * nur attachments löschen (umstellung auf attachmentstorage=filesystem: (find-script auf filesize-basis löscht dann die dateien => inkonsistenzen in der db?))
Wäre mir beides Recht. Wenn ich jetzt auf attachmentstorage=filesystem umstelle, habe ich dann wenigstens in zukunft kein Prolem? Bzw. nimmt er für alte Tickets weiterhin DB und für neue das Filesystem?
evaluierung: speicherplatz, anzahl an attachments, größtes attachment, Select sum(CAST(content_size AS UNSIGNED )), count(CAST(content_size AS UNSIGNED )), max(CAST(content_size AS UNSIGNED )) FROM `article_attachment` WHERE CAST(content_size AS UNSIGNED ) > 2097152;
Mal in die SQL box geworfen. Wart Wart Wart.
Bei mir macht das bei bezogen auf die größe der article_attachment tabelle: 2mb ca. 15% einsparung, jedoch ist bei mir die article_plain ja fast genauso groß ...
würd mich interessieren was dabei rauskommt, da ich das ggf. auch noch weiter verwenden könnte bzw möchte.
speicherplatz, anzahl an attachments, größtes attachment, 428.227.851, 105, 10.076.713 -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12200 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 Ralf.Hildebrandt@charite.de | http://www.charite.de

* Ralf Hildebrandt

* Ralf Hildebrandt
Wäre mir beides Recht. Wenn ich jetzt auf attachmentstorage=filesystem umstelle, habe ich dann wenigstens in zukunft kein Prolem? Bzw. nimmt er für alte Tickets weiterhin DB und für neue das Filesystem?
Habe das gerade mal ausprobiert: Die FS Struktur wurde angelegt, OTRS hat mails angenommen, und dann keine Tickets erstellt Schnell wieder zurückgestellt, geht wieder. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12200 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 Ralf.Hildebrandt@charite.de | http://www.charite.de

Die FS Struktur wurde angelegt, OTRS hat mails angenommen, und dann keine Tickets erstellt Schnell wieder zurückgestellt, geht wieder.
Ich selbst habs noch nicht umgestellt bzw getestet und bin kein "OTRS" modul programmierer. könnt ja an unix-berechtigung liegen: http://doc.otrs.org/2.3/en/html/c2515.html schön wäre, wenn otrs das direkt machen könnte. meine idee: #) man könnte ja zb einen bestimmten status bzw ein freitextfeld setzen für die tickets, die man raushaben will. (zb alle älter als 6 monate abgeschlossenen tickets) FRAGE AN ALLE: => wie funktioniert so das? *) mit dem generic-agent lösche ich dann alle alten tickets mit dem betreffenden status bzw freitextfeld noch ne idee: feature request bei otrs posten: * wie stellt sich otrs eine alterung/lebenszyklus eines tickets vor? (irrelevante daten entfernen?) schönes we, Lg josy Ps: da kommt bei dir ja ganz schön volumen zusammen. bei mir macht die db in summe grad mal 600mb aus. ;-) ------------------------------------------------------------------ "Duftmarketing! Wann packen Sie Ihre Zielgruppe an der Nase? Vergleichsstudien belegen einen deutlich höheren Response bei bedufteten Mailings." siehe http://www.gugler.at/leistungen/beratung/duftmarketing.html

* it-news (Josef Lahmer)
Die FS Struktur wurde angelegt, OTRS hat mails angenommen, und dann keine Tickets erstellt Schnell wieder zurückgestellt, geht wieder.
Ich selbst habs noch nicht umgestellt bzw getestet und bin kein "OTRS" modul programmierer. könnt ja an unix-berechtigung liegen: http://doc.otrs.org/2.3/en/html/c2515.html
Nee, er halt ja die Verzeichnisse angelegt...
schön wäre, wenn otrs das direkt machen könnte.
meine idee:
#) man könnte ja zb einen bestimmten status bzw ein freitextfeld setzen für die tickets, die man raushaben will. (zb alle älter als 6 monate abgeschlossenen tickets)
FRAGE AN ALLE: => wie funktioniert so das?
*) mit dem generic-agent lösche ich dann alle alten tickets mit dem betreffenden status bzw freitextfeld
noch ne idee: feature request bei otrs posten: * wie stellt sich otrs eine alterung/lebenszyklus eines tickets vor? (irrelevante daten entfernen?)
Gute Frage!
Ps: da kommt bei dir ja ganz schön volumen zusammen.
Sag ich ja! -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12200 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 Ralf.Hildebrandt@charite.de | http://www.charite.de

Ralf Hildebrandt
* Ralf Hildebrandt
: Wäre mir beides Recht. Wenn ich jetzt auf attachmentstorage=filesystem umstelle, habe ich dann wenigstens in zukunft kein Prolem? Bzw. nimmt er für alte Tickets weiterhin DB und für neue das Filesystem?
Habe das gerade mal ausprobiert:
Die FS Struktur wurde angelegt, OTRS hat mails angenommen, und dann keine Tickets erstellt
Hmm, sollte eigentlich klappen. Hast Du mal ins Log geschaut? Btw: nach der Umstellung landen neue Attachments immer im Filesystem, falls allerdings ein Attachment dort nicht gefunden wird, wird es in der Datenbank gesucht. Zugriff auf die alten Attachments ist also in jedem Fall möglich. Viele Grüße Henning -- ((otrs)) :: OTRS AG :: Europaring 4 :: D - 94315 Straubing Fon: +49 (0) 9421 56818 0 :: Fax: +49 (0) 9421 56818 18 http://www.otrs.com/ :: Communication with success! Geschäftssitz: Bad Homburg Amtsgericht Bad Homburg, HRB 10751 Steuernummer: 003 240 97505 Aufsichtsratsvorsitzender: Burchard Steinbild Vorstand: André Mindermann (Vorsitzender), Martin Edenhofer NEU! ENTERPRISE SUBSCRIPTION - JETZT informieren und buchen! http://www.otrs.com/de/support/enterprise-subscription/

* Henning Oschwald
Hmm, sollte eigentlich klappen. Hast Du mal ins Log geschaut?
Klar, nix im Log. Mails waren auch nicht mehr in der Queue, die waren schlichtweg komplett weg.
Btw: nach der Umstellung landen neue Attachments immer im Filesystem, falls allerdings ein Attachment dort nicht gefunden wird, wird es in der Datenbank gesucht. Zugriff auf die alten Attachments ist also in jedem Fall möglich.
Sehr fein, so soll es sein :) -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12200 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 Ralf.Hildebrandt@charite.de | http://www.charite.de
participants (3)
-
Henning Oschwald
-
it-news (Josef Lahmer)
-
Ralf Hildebrandt