AW: [otrs-de] Datenbankexport > 2 GB, Problem Attachments
Ich schliesse mich an, ich habe das gleiche 'Problem'. Gruss, Peter Koch Schlund + Partner AG mailto:peter.koch@schlund.de -----Ursprüngliche Nachricht----- Von: otrs-de-bounces@otrs.org [mailto:otrs-de-bounces@otrs.org] Im Auftrag von Thomas Börnert Gesendet: Dienstag, 5. Oktober 2004 16:25 An: otrs-de@otrs.org Betreff: [otrs-de] Datenbankexport > 2 GB, Problem Attachments Hallo zusammen, wollte gerade mal bei einem Kunden eine OTRS-DB exportieren, aber die article_attachment Tabelle ist mittlerweile größer als 2 GB und läßt sich nicht exportieren. kommt dann filesize exeeded ... :-( Habe dann otrs=> delete from article_attachment where create_time < '2004-07-31'; gemacht, ist aber nicht unbedingt Sinn und Zweck der Sache. Gibt es Ideen bzw. Möglichkeiten 1. Die Attachments wegzuschneiden bevor sie ins OTRS kommen ? Weil das ist der Tod für die Datenbank, die Attachments liegen eigentlich besser direkt auf der Platte. 2. Die Tabelle irgendwie anders zu sichern ? Danke schon mal... Gruß Thomas _______________________________________________ OTRS Mailingliste: otrs-de - Webpage: http://otrs.org/ Archiv: http://lists.otrs.org/pipermail/otrs-de/ Listenabo verwalten: http://lists.otrs.org/cgi-bin/listinfo/otrs-de/ Support oder Consulting fuer Ihr OTRS System? => http://www.otrs.de/
On Thu, Oct 14, _ pkliste wrote:
Ich schliesse mich an, ich habe das gleiche 'Problem'.
IMO ist das ein Filesystem-Problem und hat eher weniger mit dem OTRS zu tun. Wenn das Filesystem max nur 2 GB Grosse Dateien zulässt, dann ist es natürlich für das Backup-Script unmöglich eine grössere Datei zu schreiben. Habt Ihr mal den "-j" Schalter für die Kompression ausprobiert? Alternativ auf einer anderen Partition ein Filesystem einrichten, das mit so grossen Dateien zu Rande kommt. Gruss Stefan Wintermeyer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
alle 32-Bit-Betriebssystem habe die begrenzung mit 2 GB! angefangen von linux über windows 200x bis HP-Unix .... mit otrs hat das schon was zu tun. ich finde attachments haben in der datenbank nix zu suchen. das bläht die daten- bank unnötig auf und suchen kann man innerhalb der attachments sowieso nix. also warum sind die dann da drin. man könnte sie besser im filesystem ablegen und dann über einen geschützten link darauf zugreifen oder per file open an den browser schicken. gruß thomas On Thu, 2004-10-14 at 11:46, Stefan Wintermeyer wrote:
On Thu, Oct 14, _ pkliste wrote:
Ich schliesse mich an, ich habe das gleiche 'Problem'.
IMO ist das ein Filesystem-Problem und hat eher weniger mit dem OTRS zu tun. Wenn das Filesystem max nur 2 GB Grosse Dateien zulässt, dann ist es natürlich für das Backup-Script unmöglich eine grössere Datei zu schreiben. Habt Ihr mal den "-j" Schalter für die Kompression ausprobiert? Alternativ auf einer anderen Partition ein Filesystem einrichten, das mit so grossen Dateien zu Rande kommt.
Gruss Stefan Wintermeyer -- Mit freundlichen Grüßen Best regards
Thomas Börnert Geschäftsführer Senior IT Consultant & Manager BSI lizenzierter IT-Grundschutz Auditor DO NOT GIVE OUR ADDRESS TO THIRD PARTYS, WE HATE JUNK-MAIL ___________________________________________________________________ TBits.net GmbH | Telefon: +49 (0)7172 18391-0 Thomas Börnert | Telefax: +49 (0)7172 18391-99 Seeweg 6 | Service: +49 (0)700 TBITSNET D-73553 Alfdorf | Auto: +49 (0)170 6744415 www.tbits.net | eMail: tb@tbits.net Key fingerprint = 8602 2EF5 78FD 3C04 B148 2506 5D4F 6A49 E4E2 9D15
TB> alle 32-Bit-Betriebssystem habe die begrenzung mit 2 GB! TB> angefangen von linux über windows 200x bis HP-Unix .... nicht richtig! mein XP hat keine Probleme mit Dateien die mehr als 4Gb gross sind. N. Thursday, October 14, 2004, 1:15:02 PM, you wrote: TB> alle 32-Bit-Betriebssystem habe die begrenzung mit 2 GB! TB> angefangen von linux über windows 200x bis HP-Unix .... TB> mit otrs hat das schon was zu tun. ich finde attachments TB> haben in der datenbank nix zu suchen. das bläht die daten- TB> bank unnötig auf und suchen kann man innerhalb der attachments TB> sowieso nix. also warum sind die dann da drin. man könnte sie TB> besser im filesystem ablegen und dann über einen geschützten link TB> darauf zugreifen oder per file open an den browser schicken. TB> gruß thomas TB> On Thu, 2004-10-14 at 11:46, Stefan Wintermeyer wrote:
On Thu, Oct 14, _ pkliste wrote:
Ich schliesse mich an, ich habe das gleiche 'Problem'.
IMO ist das ein Filesystem-Problem und hat eher weniger mit dem OTRS zu tun. Wenn das Filesystem max nur 2 GB Grosse Dateien zulässt, dann ist es natürlich für das Backup-Script unmöglich eine grössere Datei zu schreiben. Habt Ihr mal den "-j" Schalter für die Kompression ausprobiert? Alternativ auf einer anderen Partition ein Filesystem einrichten, das mit so grossen Dateien zu Rande kommt.
Gruss Stefan Wintermeyer
otrs-de-bounces@otrs.org schrieb am 14.10.2004 13:18:18:
TB> alle 32-Bit-Betriebssystem habe die begrenzung mit 2 GB! TB> angefangen von linux über windows 200x bis HP-Unix ....
nicht richtig! mein XP hat keine Probleme mit Dateien die mehr als 4Gb gross sind.
N.
schon mein NT 4 konnte das....
Thursday, October 14, 2004, 1:15:02 PM, you wrote:
TB> alle 32-Bit-Betriebssystem habe die begrenzung mit 2 GB! TB> angefangen von linux über windows 200x bis HP-Unix ....
TB> mit otrs hat das schon was zu tun. ich finde attachments TB> haben in der datenbank nix zu suchen. das bläht die daten- TB> bank unnötig auf und suchen kann man innerhalb der attachments TB> sowieso nix. also warum sind die dann da drin. man könnte sie TB> besser im filesystem ablegen und dann über einen geschützten link TB> darauf zugreifen oder per file open an den browser schicken.
TB> gruß thomas
TB> On Thu, 2004-10-14 at 11:46, Stefan Wintermeyer wrote:
On Thu, Oct 14, _ pkliste wrote:
Ich schliesse mich an, ich habe das gleiche 'Problem'.
IMO ist das ein Filesystem-Problem und hat eher weniger mit dem OTRS
zu
tun. Wenn das Filesystem max nur 2 GB Grosse Dateien zulässt, dann ist es natürlich für das Backup-Script unmöglich eine grössere Datei zu schreiben. Habt Ihr mal den "-j" Schalter für die Kompression ausprobiert? Alternativ auf einer anderen Partition ein Filesystem einrichten, das mit so grossen Dateien zu Rande kommt.
Gruss Stefan Wintermeyer
_______________________________________________ OTRS Mailingliste: otrs-de - Webpage: http://otrs.org/ Archiv: http://lists.otrs.org/pipermail/otrs-de/ Listenabo verwalten: http://lists.otrs.org/cgi-bin/listinfo/otrs-de/ Support oder Consulting fuer Ihr OTRS System? => http://www.otrs.de/
problem between keyboard and chair :) http://www.winnetmag.com/Article/ArticleID/27253/27253.html wir sind doch im 21. jahrhundert und jeden tag brenne ich DVD's die natuerlich groesser als 3-4Gb sind. Das waehre absurd wenn es so ein limit gaebe :) N. Thursday, October 14, 2004, 2:52:30 PM, you wrote: TB> Windows 2003 Server kann es nicht, das habe ich nämlich TB> getestet :-(.
nicht richtig! mein XP hat keine Probleme mit Dateien die mehr als 4Gb gross sind.
N.
schon mein NT 4 konnte das....
Hallo Thomas, On Thursday 14 October 2004 13:52, Thomas Boernert wrote:
Windows 2003 Server kann es nicht, das habe ich nämlich getestet :-(.
Du musst W2k3 schon auf NTFS installieren, FAT32 kann das nicht. Stefan -- Stefan Schmidt Email: jsj@jsj.dyndns.org
Hallo Thomas, On Thursday 14 October 2004 12:15, Thomas Boernert wrote:
alle 32-Bit-Betriebssystem habe die begrenzung mit 2 GB! angefangen von linux über windows 200x bis HP-Unix ....
In gewisser Hinsicht schon, allerdings kann man inzwischen sehr wohl Dateien mit eine Grösse von mehr als 2GB auf 32bit-Systemen abspeichern. Reiserfs oder ext3 sowie XFS können das auf jeden Fall.
mit otrs hat das schon was zu tun. ich finde attachments haben in der datenbank nix zu suchen. das bläht die daten- bank unnötig auf und suchen kann man innerhalb der attachments sowieso nix. also warum sind die dann da drin. man könnte sie besser im filesystem ablegen und dann über einen geschützten link darauf zugreifen oder per file open an den browser schicken.
Ja, und das kannst Du auch so konfigurieren, in $OTRS_HOME/Kernel/Config/Defaults.pm steht: ===== # TicketStorageModule (Don't use it for big emails/attachments!) # (where attachments and co is stored - switch from fs -> db possible # but not from db -> fs - old attachments are not shown) $Self->{TicketStorageModule} = 'Kernel::System::Ticket::ArticleStorageDB'; # FS is faster but webserver user should be the otrs user) # $Self->{TicketStorageModule} = 'Kernel::System::Ticket::ArticleStorageFS'; ===== Schalte auf ArticleStorageFS um, und schon sind die Attachments nicht mehr in der Datenbank.
gruß thomas
Stefan -- Stefan Schmidt Email: jsj@jsj.dyndns.org
In gewisser Hinsicht schon, allerdings kann man inzwischen sehr wohl Dateien mit eine Grösse von mehr als 2GB auf 32bit-Systemen abspeichern. Reiserfs oder ext3 sowie XFS können das auf jeden Fall.
Was muß man da dann machen ? Ich habe ext3 und trotzdem nur 2GB :-(.
Ja, und das kannst Du auch so konfigurieren, in $OTRS_HOME/Kernel/Config/Defaults.pm steht: ===== # TicketStorageModule (Don't use it for big emails/attachments!) # (where attachments and co is stored - switch from fs -> db possible # but not from db -> fs - old attachments are not shown) $Self->{TicketStorageModule} = 'Kernel::System::Ticket::ArticleStorageDB'; # FS is faster but webserver user should be the otrs user) # $Self->{TicketStorageModule} = 'Kernel::System::Ticket::ArticleStorageFS'; =====
Schalte auf ArticleStorageFS um, und schon sind die Attachments nicht mehr in der Datenbank.
ok, ich gebe mich geschlagen, sorry ... aber: jetzt kommt ein fehler von der smrsh vom sendmail, wenn er das /opt/otrs/bin/PostMaster.pl ausführt: stat=Deferred: prog mailer (/usr/sbin/smrsh) exited with EX_TEMPFAIL Wo will er da die Attachments speichern ? Die Doku ist da ziemlich dünn. Gruß Thomas
On Thu, Oct 14, Thomas Boernert wrote:
Was muß man da dann machen ? Ich habe ext3 und trotzdem nur 2GB :-(.
Thomas, das hier ist eine OTRS Mailingliste und keine um allgemeine Linux-Probleme zu lösen. Kaufe dir eine SuSE 9.1, installiere sie und benutze als File-System ein ReiserFS. Danach wirst Du glücklich sein. Wenn man sich nicht in die Tiefen einer Distribution begeben will (warum und weshalb auch immer) sollte man ein Standardprodukt nehmen. Just my 2 cents. Aber ich könnte mir vorstellen, das in Deinem Fall der "-j" Schalter schon helfen könnte.
aber:
jetzt kommt ein fehler von der smrsh vom sendmail, wenn er das /opt/otrs/bin/PostMaster.pl ausführt: stat=Deferred: prog mailer (/usr/sbin/smrsh) exited with EX_TEMPFAIL
Wo will er da die Attachments speichern ? Die Doku ist da ziemlich dünn.
Ist das evt. ein neues Thema? Sorry, wenn ich da ein wenig kleinkariert bin, aber es ist für alle Teilnehmer dieser Mailingliste sehr praktisch, wenn folgende Informationen vorhanden wären: Version des OTRS Art und Version des Betriebssystems Fehlerbeschreibung Subjekt der E-Mail passend zum Fehler Im Vorfeld kann man auch kurz mal auf Google nachschauen, ob der Fehler evt. schon mal irgendwo aufgetaucht ist. Dann hat man sich selber viel Zeit gespart: http://www.google.com/search?q=suchbegriff+site:otrs.org Gruss Stefan Wintermeyer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
On Thu, Oct 14, Thomas Boernert wrote:
mit otrs hat das schon was zu tun. ich finde attachments haben in der datenbank nix zu suchen.
Dazu sage ich nur: RTFM! Per default ist die Datenbank nur deshalb angegeben, weil die meisten Kunden das so wollen. Du hast mit Deiner Argumentation recht und Du kannst es ganz einfach entsprechend konfigurieren: $OTRS_HOME/Kernel/Config/Defaults.pm ---cut--- # $Self->{TicketStorageModule} = 'Kernel::System::Ticket::ArticleStorageFS'; ---cut--- Obigen Eintrag aktivieren und den Datenbankeintrag (2-3 Zeilen drüber) deaktivieren. Gruss Stefan Wintermeyer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
Stefan Wintermeyer wrote:
On Thu, Oct 14, Thomas Boernert wrote:
mit otrs hat das schon was zu tun. ich finde attachments haben in der datenbank nix zu suchen.
Sehe ich auch so.
Dazu sage ich nur: RTFM!
Ach, echt? Die freundliche Version RTM reicht eigentlich auch, vielleicht noch mit nem Link (http://doc.otrs.org/1.3/en/html/performance-tuning.html#PERFORMANCE-TUNING-O...).
$OTRS_HOME/Kernel/Config/Defaults.pm ---cut--- # $Self->{TicketStorageModule} = 'Kernel::System::Ticket::ArticleStorageFS'; ---cut--- Obigen Eintrag aktivieren und den Datenbankeintrag (2-3 Zeilen drüber) deaktivieren.
Also, wenn Sie das f*** Manual so toll gelesen haben, dann dürfte Ihnen nicht entgangen sein, daß man in dieser Datei grad mal GAR NIX ändern soll, sondern in der Config.pm ein Verzeichnis obendran. Davon mal abgesehen werden mit dieser Einstellung ALLE Daten eines Article im Filesystem gespeichert. Ich hätte es schick gefunden, wenn der text/plain in der Datenbank verbleibt, und nur die Attachments ins Filesystem wandern. Gruß, Peter Koch
ich dachte eigentlich auch, daß nur die Attachments im FS stehen :-(. ich schließe mich dem an ! Gruß Thomas
mit otrs hat das schon was zu tun. ich finde attachments haben in der datenbank nix zu suchen.
Sehe ich auch so.
Dazu sage ich nur: RTFM!
Ach, echt? Die freundliche Version RTM reicht eigentlich auch, vielleicht noch mit nem Link (http://doc.otrs.org/1.3/en/html/performance-tuning.html#PERFORMANCE-TUNING-O...).
$OTRS_HOME/Kernel/Config/Defaults.pm ---cut--- # $Self->{TicketStorageModule} = 'Kernel::System::Ticket::ArticleStorageFS'; ---cut--- Obigen Eintrag aktivieren und den Datenbankeintrag (2-3 Zeilen drüber) deaktivieren.
Also, wenn Sie das f*** Manual so toll gelesen haben, dann dürfte Ihnen nicht entgangen sein, daß man in dieser Datei grad mal GAR NIX ändern soll, sondern in der Config.pm ein Verzeichnis obendran.
Davon mal abgesehen werden mit dieser Einstellung ALLE Daten eines Article im Filesystem gespeichert. Ich hätte es schick gefunden, wenn der text/plain in der Datenbank verbleibt, und nur die Attachments ins Filesystem wandern.
Gruß, Peter Koch _______________________________________________ OTRS Mailingliste: otrs-de - Webpage: http://otrs.org/ Archiv: http://lists.otrs.org/pipermail/otrs-de/ Listenabo verwalten: http://lists.otrs.org/cgi-bin/listinfo/otrs-de/ Support oder Consulting fuer Ihr OTRS System? => http://www.otrs.de/
On Fri, Oct 15, Peter Koch wrote:
Dazu sage ich nur: RTFM!
Ach, echt? Die freundliche Version RTM reicht eigentlich auch, vielleicht noch mit nem Link
RTFM ist für mich nicht unfreundlich. Wort für Wort ins Deutsche übersetzt, kann man sich vielleicht an dem "F-Word" stören, aber RTFM wird schon seit so vielen Jahren eingesetzt, das es für mich in den normalen Sprachgebrauch übergegangen ist. Man könnte ja auch noch andere Definitionen für das "F" benutzen: http://en.wikipedia.org/wiki/RTFM
Also, wenn Sie das f*** Manual so toll gelesen haben, dann dürfte Ihnen nicht entgangen sein, daß man in dieser Datei grad mal GAR NIX ändern soll, sondern in der Config.pm ein Verzeichnis obendran.
Das stimmt und das war ein dicker Schnitzer. Ich habe das aus einer anderen E-Mail per cut-and-paste rübergezogen. Böser Schnitzer!
Davon mal abgesehen werden mit dieser Einstellung ALLE Daten eines Article im Filesystem gespeichert. Ich hätte es schick gefunden, wenn der text/plain in der Datenbank verbleibt, und nur die Attachments ins Filesystem wandern.
Diese Option ist für hohe Performance bestimmt. Es gibt noch hunderte Zwischenschritte die alle möglich wären. Wer diese Zwischenschritte braucht, der kann sie jederzeit selber implementieren. UTSL. SCNR. ;-) Ich wünsche Euch allen noch ein schönes Wochenende! :-) Gruss Stefan Wintermeyer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
Davon mal abgesehen werden mit dieser Einstellung ALLE Daten eines Article im Filesystem gespeichert. Ich hätte es schick gefunden, wenn der text/plain in der Datenbank verbleibt, und nur die Attachments ins Filesystem wandern.
So wie ich es sehe, ist das Ganze wohl noch nicht so ganz durchdacht. Ein Workarround wäre: Von Roaring Penguin das MIMEDefang installieren, damit kann man über die Milter-Schnittstelle vom Sendmail Attachements (und auch nur diese) rausschneiden und dann im Bereich des Webservers ablegen. Beim Rausschneiden der Attachments macht er dann automatisch einen Link auf die Datei in die Mail rein. Ich glaube daran komme ich jetzt wohl nicht vorbei. Gruß Thomas
Thomas Börnert wrote:
Davon mal abgesehen werden mit dieser Einstellung ALLE Daten eines Article im Filesystem gespeichert. Ich hätte es schick gefunden, wenn der text/plain in der Datenbank verbleibt, und nur die Attachments ins Filesystem wandern.
So wie ich es sehe, ist das Ganze wohl noch nicht so ganz durchdacht. Ein Workarround wäre: Von Roaring Penguin das MIMEDefang installieren, damit kann man über die Milter-Schnittstelle vom Sendmail Attachements (und auch nur diese) rausschneiden und dann im Bereich des Webservers ablegen. Beim Rausschneiden der Attachments macht er dann automatisch einen Link auf die Datei in die Mail rein. Ich glaube daran komme ich jetzt wohl nicht vorbei.
Naja, das ist aber eigentlich das Rad zweimal erfunden, denn OTRS kann Attachments ja durchaus erkennen, zumindest hatte ich noch keinen Fall, wo das nicht so war. pk
das mit der Kompression war super, jetzt habe ich wenigstens mal wieder einen dump :-) *freu*, d.h. für postgresql pg_dump -Fc -h localhost -p 5432 -U postgres -f otrs.dump otrs Danke. Gruß Thomas
schreiben. Habt Ihr mal den "-j" Schalter für die Kompression ausprobiert? Alternativ auf einer anderen Partition ein Filesystem
On Thu, Oct 14, Thomas Boernert wrote:
das mit der Kompression war super,
Das freut mich.
mal wieder einen dump :-) *freu*, d.h. für postgresql
pg_dump -Fc -h localhost -p 5432 -U postgres -f otrs.dump otrs
Alternativ könntest Du auch das Backup Script von OTRS benutzen. Dann kannst Du auch sicher sein, das Du das Backup mit dem Restore Script problemlos wieder einlesen kannst. RTFM. Gruss Stefan Wintermeyer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
participants (8)
-
_ pkliste -
N.R. -
Peter Koch
-
Stefan Schmidt -
Stefan Wintermeyer -
Thomas Boernert -
Thomas Börnert
-
Volker.Lipper＠de.mecglobal.com