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
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-usersHave 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-usersHave 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-usersHave 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.
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
save the real document attachments to
…/Attachment///mydoc.doc
remove all transactions & attachments related to the ticket
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