Archiving Best Practices / How To Guide for Oracle 10g - need urgently

Question

Hi,
I apologize if this is a silly question. But i need a step by step archiving guide for Oracle 10g and cannot find any reference document. I am in a rather remote part of S.E. Asia & can't seem to find DBA's with the requisite experience to do the job properly. I have had 1 database lock up this week at a big telecoms provider and another one at a major bank is about to go. I can easily add LUNS & re-structure mirrors etc at the Unix level [ i am a Unix engineer ]
but i know that is not the long run solution. I am sure the 2 databases i am concerned about have never been archived properly.
This is the sort of thing DBA's must do all the time. Can someone point me to the proper documentation so i can do a proper job and archive a few years data out of these databases. I do not want to do a hack job. At least i can clone the databases and practise on the clones first before i actually do production.
-thanks very much
-gregoire
[email protected]

Answer 1

I'm not so sure this is a general database question, as it would be specific to an application and implementation, and as the technology has changed, the database options to support it has too.
So for example, if you have bought the partitioning option, there may be some sensible procedure for partitioning off older data.
Things may depend on whether you are talking about an OLTP, a DW, a DSS, or mixed systems.
DBA's do it all the time because the requirements are different everywhere. Simply deleting a lot of data after copying the old data to another table (as some older systems do) may just wind up giving you performance problems scanning swiss-cheesed data.
Some places may not archive at all, if they've separated out OLTP from reporting. If all the OLTP stuff is accessed through indices, all the older stuff just sits there. The reporting DB may only have what is needed to be reported on, or be on a standby db where range scans are sufficient to ignore old data. There there's exadata, which has it's own strengths.
Best Practices have to be on similar enough systems, otherwise they are a self-contradiction.
Get yourself someone who understands your requirements and can evaluate the actual problem. No apology needed, it is not a silly question. But what is silly is assuming what the problem is with no evidence.