Randy,
Sorry, not an Oracle option.
The code was dynamically generated based on primary_key columns, other
columns and column types.
If the row already existed in ARCHIVE (based on primary key) then update
else insert.
The only advantage from the dynamically generated code was that it updated
itself when there were schema changes.
If you intend to go this way there may be other advice I can bring to mind.
eric
"Randy" <rvandehe_at_enzy.com> wrote in message
news:af46bb2c.0301300730.f2ab55e_at_posting.google.com...
> Eric,
>
> That is very interesting and sounds exactly what we are looking for.
> How was the code for the insert/updates generated from the data
> dictionary. Is this an Oracle option or did you write code to
> dynamically generate the insert/update statements?
>
> -Randy
>
>
> "Eric Parker" <Eric_Parker_spamless_at_btopenworld.com> wrote in message
news:<b18dnm$m28$1_at_helle.btinternet.com>...
> > Randy
> > Sorry about the late response.
> > I've just completed an archive system similar (I think) to what you
> > describe.
> > Ours was part of a Data Warehouse/Reporting database.
> > We couldn't get replication to achieve what was required without
impacting
> > on PROD.
> > We ended up copying PROD into ARCHIVE overnight using
> > parallel 'CREATE TABLE COPY_ABC AS SELECT * FROM ABC_at_PROD' statements.
> > We copied about 4 GBytes in 250 tables in 15 minutes. This was then
> > UPDATED/INSERTED
> > in ARCHIVE. The UPDATE/INSERT code took a further 3-4 hours to complete.
> > The code required Primary Keys on all tables and as 'buckeye234' pointed
out
> > it
> > would not tolerate recycling Primary Keys. The code that performed this
was
> > generated from the data dictionary.
> > eric
> >
Received on Fri Jan 31 2003 - 13:16:44 CST
