Re: Archiving data into another database

I would have checked an option to partition the table according to dates and leave all the data in the original table.

Getting data from an archive database complicate the application.

Adar Yechiel
Rechovot, Israel

Luc Demanche wrote:
> Totally agree with you. The performance is not the issue.
> The management want to have the data clean, but want to access it if
> needed.
>
> There is one or two guys that will have to go on the historical data
> if needed.
>
> Thank you very much for your time.
>
> Luc
>
>
> On 1/31/07, *Carel-Jan Engel* <cjpengel.dbalert_at_xs4all.nl
> <mailto:cjpengel.dbalert_at_xs4all.nl>> wrote:
>
> My main objection against solutions with separated sets of
> historical and
> actual data is that users often (read: ultimately always...) want
> to see
> information combined/derived/aggegrated from both actual and
> historical
> data. This yields maintenance of more complex queries, with
> unions, and a
> lot of extra development, testing, release and version management
> of data
> and code.
>
> I'd prefer to keep the whole thing in the same set of tables,
> eventually
> partitioned.
>
> 40 GB of data is not that big, after all.
>
> You say it will probably help the performance. This implies
> performance is
> suboptimal now. Is the amount of data the root cause of your
> performance
> problems? Is performance the reason why you want to start all the
> hassle
> with splitting/separating your data? Did you investigate what is
> causing
> your bad performance?
>
> Don't get me wrong: If you have 15GB worth of data that serves no
> requirement (incl. legal enforcements to keep historicla data for
> 7 or 10
> years, or whatever): Just make a backup of the database (or two), and
> throw away the obsolete stuff. If you still need the data:
> describe the
> real problems, investigate for possible solutions and pick the
> best. Try
> not to jump into solutions to soon.
>
> Regards, Carel-Jan
>
> ===
> If you think education is expensive, try ignorance. (Derek Bok)
> ===
>
>
>
> > Thank you all for your answers.
> > The situation is, we have a in-house application, we having a lot of
> > historical data (invoices, info on old products, old documents).
> > It's not a big database (around 40Gigs), but I'm sure that we
> can "purge"
> > at
> > least 15 Gigs of data.... of data that it's not been used anyway.
> >
> > It will probably help the performance in the same time ...
> >
> > We were thinking of creating another database, with the same
> structure and
> > transfer data from one to the other.
> > My concern was on the modification that will be done on the
> structure ....
> > so we decided that we will apply the same scripts to both
> databases, so
> > the
> > structures will be the same all the time.
> >
> > Do you have some comments ?
> >
> > Thanks
> > Luc
> >
> >
> > On 1/31/07, Carel-Jan Engel <cjpengel.dbalert_at_xs4all.nl
> <mailto:cjpengel.dbalert_at_xs4all.nl>> wrote:
> >>
> >> Archiving is a solution. What is the probplem you're trying to
> solve?
> >>
> >>
> >> Best regards,
> >>
> >> Carel-Jan Engel
> >>
> >> ===
> >> If you think education is expensive, try ignorance. (Derek Bok)
> >> === On Tue, 2007-01-30 at 10:59 -0500, Luc Demanche wrote:
> >>
> >> Hi,
> >>
> >>
> >>
> >> We are thinking to have a process that will archive data from our
> >> production database to another database, or somewhere else .....
> >>
> >> For example, data of an old customer, info of an old product,
> etc ....
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Luc Demanche
> > Oracle DBA
> > (514) 867-9977
> >
>
>
>
>
>
> --
> Luc Demanche
> Oracle DBA
> (514) 867-9977

--
http://www.freelists.org/webpage/oracle-l