Re: [rt-users] RT Archiving Tickets

[Torsten Brumm]

There is an Extension from bps to Export attachements from db, but it is Not 
Open so far i Know.

Von meinem iPhone gesendet

Am 15.03.2011 um 12:52 schrieb ronald higgins ronald.higg...@gmail.com:

 Greets fellow users,
 
 We have an RT 3.8.7 Deployment running on Centos with a MySQL backend.
 
 The DB itself has grown quite large, currently around 300GB with 2.1
 million tickets, this due to customers sending through images which is
 part of the ticket.
 About a year ago we partitioned the RT Database and that sped up
 things quite nicely however we're looking at further ways to improve
 speed. Is there any sort of archiving mechanism we can use so that the
 DB can run lighter?
 
 Regards
 
 Ronald

Re: [rt-users] RT Archiving Tickets

[Brumm, Torsten / Kuehne + Nagel / Ham MI-ID]

Hi Ronald,
another option would be Shredding old Tickets, or use 
https://github.com/bestpractical/rt-extension-exportimport from Ruslan.

Torsten 


Kuehne + Nagel (AG  Co.) KG, Geschaeftsleitung: Hans-Georg Brinkmann (Vors.), 
Dirk Blesius, Reiner Heiken, Bruno Mang, Alfred Manke, Christian Marnetté, Mark 
Reinhardt, Jens Wollesen, Klaus Jaeger (stellv.), Sitz: Bremen, 
Registergericht: Bremen, HRA 21928, USt-IdNr.: DE 812773878, Persoenlich 
haftende Gesellschaft: Kuehne  Nagel A.G., Sitz: Contern/Luxemburg 
Geschaeftsfuehrender Verwaltungsrat: Klaus-Michael Kuehne



-Urspruengliche Nachricht-
Von: rt-users-boun...@lists.bestpractical.com 
[mailto:rt-users-boun...@lists.bestpractical.com] Im Auftrag von ronald higgins
Gesendet: Dienstag, 15. Maerz 2011 12:52
An: rt-users@lists.bestpractical.com
Betreff: [rt-users] RT Archiving Tickets

Greets fellow users,

We have an RT 3.8.7 Deployment running on Centos with a MySQL backend.

The DB itself has grown quite large, currently around 300GB with 2.1 million 
tickets, this due to customers sending through images which is part of the 
ticket.
About a year ago we partitioned the RT Database and that sped up things quite 
nicely however we're looking at further ways to improve speed. Is there any 
sort of archiving mechanism we can use so that the DB can run lighter?

Regards

Ronald