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

[Ruslan U. Zakirov]

Cerion Armour-Brown wrote:
> On Monday 01 March 2004 14:08, Ruslan U. Zakirov wrote:
> 
>>Cerion Armour-Brown wrote:
>>
>>>On Monday 01 March 2004 12:53, Ritu Khetan wrote:
>>>
>>>>Hello All,
>>>>
>>>>  What is the best way to archive data from RT (using Postgres) say on
>>>>a yearly basis. However, this data should be available at any point of
>>>>time of read/search if required.
>>>>
>>>>Say, for e.g. -
>>>>If I have 5 years data in RT, which I do not require everyday, I would
>>>>like to archive it yearly so that it does not slow the performance of my
>>>>system. However, at the same time, if I have a request to look for some
>>>>information in the archived data, I should be able to look at it
>>>>immediately.
>>>
>>>Do the database archiving by hand/script... just setup an identical rt3
>>>database, dump the databases, do diffs and add new records to
>>>rt3_archive... or something to that effect.
>>>As for access, depends how 'immediate'... if you can handle having to
>>>change $DatabaseName in RT_SiteConfig.pm, and then reloading RT in the
>>>browser, that should work.
>>>If that's not immediate enough, you could set up a second RT instance
>>>with a different $DatabaseName, plus a virtual host so you can access
>>>this rt_archive instance 'immediately' - on a different web address.
>>>Cerion
>>
>>Your solution don't solve main problem: perfomance of main server
>>because all tickets still there.
>>
>>Ritu, there is no simple way to do what you want. Yes, you should use
>>another RT instance for archive, but also should write scripts that move
>>    old tickets to archive and don't break anything.
>>
>>		Best regards. Ruslan.
> 
> 
> I am pretty new to all this, but tell me how does taking the records from rt3 
> and inserting them into an rt3_archive database _not_ solve the performance 
> problem? What do you mean the tickets are still there? - they'd be in a 
> different database that would only be loaded if accessed... 
> I guess if you're worried about performance while both are being accessed at 
> the same time, that'd have to be solved by putting the 2 instances on 
> different machines... or are you talking of something else?
> Cerion

Think I said _move_ not copy.

Main perfomance problem is DB size even indexes don't help a lot.

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?

		Best regards. Ruslan.