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@xxxxxxxxx <mailto:cjpengel.dbalert@xxxxxxxxx>> 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@xxxxxxxxx
    <mailto:cjpengel.dbalert@xxxxxxxxx>> 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

Other related posts: