[rt-users] Archiving and Retrieval of data in RT

[Les Mikesell]

On Mon, 2004-03-01 at 07:35, Ruslan U. Zakirov wrote:

> Think I said _move_ not copy.
> 
> Main perfomance problem is DB size even indexes don't help a lot.
> 

I don't think it is so much the size as the number of items
it must attempt to join to construct the views.

> Now, RT don't allow any deletes via API, but API is only thing which 
> give you backward compatibility while release updates(upgrades). So if 
> you are going to use direct DB manipulations to move data from main 
> server archive you're at wrong direction, DB could be changed in future 
> almost unpredictable.
> 
> Another problem with lazy scripts is relationships between DB tables and 
> RT Instances. For eg: ticket which should be moved has link to another 
> one which stay in main RT instance. What to do with Link?

This is a big problem for me.  I'm still using RT2 because of the
speed issues in RT3 (which may be already fixed - I haven't tried
again for a while).  However at about 20,000 tickets and nearly
as many users because these come in from public email, mysql
is starting to need temp files for the joins in searches and
frequently locks up.  Does anyone have tuning hints for my.cnf?

I think the only thing I can do is start over with a new RT3
perhaps on a different machine and only import a small number
of tickets.  However, I think the real problem is the size
of the user table and I'd like to drop all the auto-created
users that don't have tickets after the move. 

---
  Les Mikesell
   les at futuresource.com