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

[Ruslan U. Zakirov]

Les Mikesell wrote:
> 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.

Yes, you're right.

> 
> 
>>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.

Since 3.0.4 lelease perfomance was big point of improvements and still 
work is going. You could give a try to 3.0.9.

Yes, many user records decrease perfomance a lot, really problem for 
public RT servers, but still there is no one script that wipeout 'dummy 
users' who isn't requestor(ticket was deleted, spammers).
:(

		Good luck. Ruslan.
> 
> ---
>   Les Mikesell
>    les at futuresource.com