Re: Archival databases

Hi,

In addition to mountain man's suggestion, you might also wish to consider horizontal table partitioning. Your situation sounds to me like the "classical example" of why table partitioning was created in the first place.

Cheers,
Doug

On Thu, 08 Feb 2007 10:25:10 GMT, mountain man wrote:
> <rachitm_at_gmail.com> wrote in message
> news:1170113506.431629.130590_at_k78g2000cwa.googlegroups.com...
> > Can anyone direct me to the latest database archival strategies that
> > are used in the market these days? I have a db which is
> > underperforming bcz of huge data, and I want to build up an archival
> > db to keep old data. I want the communication between these dbs to be
> > one way - transfer of data and communication only directed from
> > operational db to the archive db and not the other way.
> >
> > Now, the old data which is going to be in the archival db might have
> > some connections to data that I still want to kept in the operational
> > db. Also, I need to create reports from the archival database about
> > different things. When these reports are created the archival db will
> > need that info from the operational db. But as I said, the
> > communication cannot be from archival db to operational db, but only
> > the other way round.
> >
> > I hope I am communicating the issue properly. Please let me know what
> > you think about this?
> >
> > Any thoughts?
>
> Yes, look at slabs of data in terms of YEARS:
>
> 1) How many years worth of data do you really need in production?
> 2) How much data are you accumulating each year?
> 3) Auto-archive oneway into the archive database as annual housekeeping.
> 4) Point "archive reporting" routines at both archive and production by
> using a UNION statement.
>
> Should be a piece of cake.
> Good luck.
Received on Thu Feb 08 2007 - 20:41:48 CET