Re: Archiving data into another database

 Having had good results with partitioning at my last job, that would be my preference. Unfortunately, partitioning isn't an option when using Standard Edition One as we are. The company isn't yet in a position financially to pay the licensing fees for an editiion that supports partitioning. This is why I'm looking for other options. I still am leaning towards an archive table in the same database.

Sandy

On 1/31/07, Yechiel Adar <adar666_at_inter.net.il> wrote:
>
> 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> 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> 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