Archiving old tickets

Anyone know how to do this and still be able to search them. Or would that be
a mysql thing.

Thanks

Daniel Fairchild - Chief Security Engineer | danielf@supportteam.net

What is it that you actually hope to achieve by archiving thme?

Speed ? , Disk Space ? or purely just a “cleaner” result? (eg not as many
tickets return on the search page?)–On Wednesday, 29 January 2003 11:27 AM -0600 “Daniel F. Chief Security Engineer -” danielf@supportteam.net wrote:

Anyone know how to do this and still be able to search them. Or would
that be a mysql thing.

Thanks


Daniel Fairchild - Chief Security Engineer | danielf@supportteam.net


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

I was hoping to be able to reduce the size of my Attachments table, it’s 4gig
and growing in under 6 months.

I guess speed is my biggest issue now. The machine im running it on is a dual
PIII 1.3 Ghz and 2Gig of ram. On an IDE disk. Im considring more ram and SCSI
drives in a raid config. Although it seems some thing on the machine has a
memory leak as it eats up all the memory and will not release till a reboot.

I get about 200 new tickets a day.

TIAOn Wednesday 29 January 2003 17:29, Matthew Watson wrote:

What is it that you actually hope to achieve by archiving thme?

Speed ? , Disk Space ? or purely just a “cleaner” result? (eg not as many
tickets return on the search page?)

–On Wednesday, 29 January 2003 11:27 AM -0600 “Daniel F. Chief Security Engineer -” danielf@supportteam.net wrote:

Anyone know how to do this and still be able to search them. Or would
that be a mysql thing.

Thanks


Daniel Fairchild - Chief Security Engineer | danielf@supportteam.net


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Daniel Fairchild - Chief Security Engineer | danielf@supportteam.net
The distance between nothing and infinity is always the same no matter how
close you get to nothing.

“DFCSE” == Daniel F Chief Security Engineer <-" danielf@supportteam.net> writes:

DFCSE> I was hoping to be able to reduce the size of my Attachments
DFCSE> table, it’s 4gig and growing in under 6 months.

It is indexed, so it shouldn’t be slowing you down. However, if
you’re using a database that imposes size limits then perhaps you
should consider upgrading to something that doesn’t.

Hi,

At 11:27 AM 1/29/2003 -0600, you wrote:

Anyone know how to do this and still be able to search them. Or would that be
a mysql thing.

Im quite intrested in this too, we have tickets from around 1997, and when
anyone of the support team do a search for somthing MySQL starts to chug
away and eat the server load for about 5 minutes because of all the old
tickets.

If someone does have a way of archiving older tickets it would be nice, for
both space, and search speed.

Cheers,

Bruce

At 11:27 AM 1/29/2003 -0600, you wrote:

Anyone know how to do this and still be able to search them. Or would that be
a mysql thing.

Im quite intrested in this too, we have tickets from around 1997, and when
anyone of the support team do a search for somthing MySQL starts to chug
away and eat the server load for about 5 minutes because of all the old
tickets.

If someone does have a way of archiving older tickets it would be nice, for
both space, and search speed.

Make your searches have a default “after X date”… that would limit the
SQL query a lot… probably greatly increase speed, without having to
touch the DB.

“SC” == Seth Cohn writes:

If someone does have a way of archiving older tickets it would be nice, for
both space, and search speed.

SC> Make your searches have a default “after X date”… that would limit the
SC> SQL query a lot… probably greatly increase speed, without having to
SC> touch the DB.

Only if it were indexed by date, or does mysql have some other magic
in it?

“SC” == Seth Cohn writes:

If someone does have a way of archiving older tickets it would be nice,
for both space, and search speed.

SC> Make your searches have a default “after X date”… that would limit
the SC> SQL query a lot… probably greatly increase speed, without having
to SC> touch the DB.

As far as I can tell there is no indexing so the above does not work.
Especially if you have to search history/ Attachments for some keep word.

I need to be able to remove tickets that are old with out damaging the
database.

Thanks

Hi,

For those interested:

The following is how we are taking on archiving (in concept) - it is a
bit plain & simple, but it will suffice for our needs (please feel free
to comment):

If ticket was resolved e.g. more that 1 year ago it will be archived.

  1. make a copy of the full displayed page with wget and save it to
    .html:
    http://support.nha.co.za/Ticket/Display.html?ShowHeaders=32624&id=32624

  2. save the real document attachments to
    …/Attachment///mydoc.doc

  3. remove all transactions & attachments related to the ticket

  4. set Ticket.status to resolved.

This results in a repository of HTML pages of tickets with there links
to attachments still working, but with no workable back-end working.
What is great is that this can still be viewable from e.g.
RTarchive.example.com and I will probably add a search script later. It
will naturally be displayed as a numerical list of all the tickets
that’s been archived.
The original ticket is still searchable on its attributes like people &
dates, but of course no content.

One extra thing I have not thought of is to create a table with archived
tickets and the date it was archived, or maybe to add a date field to
rt2.Tickets, but I would not want to change the actual structure of the
rt-db to ensure future seamless scalability.

I am concerned that deleting the transactions and attachments from the
db might mess up some db-integrity, but so far it has work fine - I can
view the tickets fine, except that there are no Details - please advise
on this if you know the internals better.

Any thoughts from you guys??

Rehan van der Merwe
Neil Harvey & Associates

hello users,

I am fighting a losing war with apache-1.3.27+modper1 and rt-3.0-beta.
Perhaps someone has a good eye and a pointing finger:

beastie# httpd -l
Compiled-in modules:
http_core.c
mod_so.c
mod_perl.c
suexec: enabled; valid wrapper /usr/local/sbin/suexec

beastie# apachectl configtest
Subroutine handler redefined at /opt/rt3/bin/webmux.pl line 111.
[Thu Feb 13 15:34:28 2003] [error] Undefined subroutine &RT::LoadConfig called at /opt/rt3/bin/webmux.pl line 60.
Compilation failed in require at (eval 78) line 1.

Syntax error on line 104 of /usr/local/etc/apache/virtualhosts:
Undefined subroutine &RT::LoadConfig called at /opt/rt3/bin/webmux.pl line 60.
Compilation failed in require at (eval 78) line 1.

My virtualhost for rt3:

<VirtualHost *:443>
ServerName rt3.wananchi.com
DocumentRoot /opt/rt3/share/html
AddDefaultCharset UTF-8

PerlModule Apache::DBI
PerlRequire /opt/rt3/bin/webmux.pl

<Location />
    SetHandler perl-script
    PerlHandler RT::Mason
</Location>
    cheers
   - wash 

Odhiambo Washington, wash@wananchi.com . WANANCHI ONLINE LTD (Nairobi, KE) |
http://ns2.wananchi.com/~wash/ . 1ere Etage, Loita Hse, Loita St., |
GSM: (+254) 722 743 223 . # 10286, 00100 NAIROBI |
“Oh My God! They killed init! You Bastards!”
–from a /. post