> If I enable journaling on the
> archive table would that make it safer?
Yes.
> Would there be a performance [penalty]
I don't believe so. If I remember correctly, the OS will cache the
inserts until a COMMIT is issued.
> and disk space penalty?
Yes. Journalling does require some disk space.
> What I would really like would be for the delete to run for a while,
> and then be able to interrupt the delete, with the corresponding
> inserts completing. Then I could restart the delete another time.
You could do this by making the delete a programmed housekeeping /
archive process, rather than relying on a trigger.
Are you likely to be doing bulk (multi-million row) deletes? That
suggests that your delete / housekeeping / archive process is perhaps
not very well designed. (Of course, it might not be avoidable in your
case, but to me this is a bad sign.)
JohnO - 10 May 2008 23:51 GMT
> > If I enable journaling on the
> > archive table would that make it safer?
[quoted text clipped - 20 lines]
> not very well designed. (Of course, it might not be avoidable in your
> case, but to me this is a bad sign.)
Hi, and thanks for the comments.
The deletes are only going to be purge/archive operations, rather than
business transactions. The first one is going to delete the millions
as it will be several years worth. Subsequent ones will be annual so
will still be pretty big, but not quite so bad.
Serge Rielau - 11 May 2008 03:36 GMT
> The deletes are only going to be purge/archive operations, rather than
> business transactions. The first one is going to delete the millions
> as it will be several years worth. Subsequent ones will be annual so
> will still be pretty big, but not quite so bad.
If that's the case why don't you use batch process. Triggers are meant
to to be active database objects. I wouldn't use them for maintenance tasks.
Cheers
Serge

Signature
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab
JohnO - 11 May 2008 21:34 GMT
> > The deletes are only going to be purge/archive operations, rather than
> > business transactions. The first one is going to delete the millions
[quoted text clipped - 3 lines]
> If that's the case why don't you use batch process. Triggers are meant
> to to be active database objects. I wouldn't use them for maintenance tasks.
H Serge,
Speed, mostly. This is a JDEdwards OneWorld site, so any batch work
will be written in the OneWorld toolset, and will likely end up bing
millions of individual inserts and deletes. The process would take
many days for some of the files.
It's so much faster to do a bulk delete, and I was hoping the trigger
would optimise out well enough.
The statement based trigger seems to be the most efficient, but with
the problems I pointed otu at the start.
Cheers,
JohnO
walker.l2 - 12 May 2008 10:20 GMT
> Speed, mostly. This is a JDEdwards OneWorld site, so any batch work
> will be written in the OneWorld toolset, and will likely end up bing
> millions of individual inserts and deletes. The process would take
> many days for some of the files.
When all you have is a hammer, every problem lokos like a nail. :-)
This is an ideal job for a couple of simple SQL statements (that can
be run from a simple CL program if required).
Something like:
CREATE TABLE archive as SELECT * FROM mainfile WHERE date < sometime
WITH DATA
and
DELETE FROM mainfile WHERE date < sometime
should do the trick (N.B. I haven't checked the syntax of these, but
you get the idea), with an index over the 'date' field for performance
reasons.
In future a simple CPYF *ADD command with a date selection could move
records from mainfile to archive, and the SQL delete perform the tidy-
up.
JohnO - 13 May 2008 02:33 GMT
> > Speed, mostly. This is a JDEdwards OneWorld site, so any batch work
> > will be written in the OneWorld toolset, and will likely end up bing
[quoted text clipped - 16 lines]
> records from mainfile to archive, and the SQL delete perform the tidy-
> up.
Interesting about the CPYF *ADD - will that perform faster than an
INSERT INTO ... SELECT ... FROM type SQL operation?
walker.l2 - 14 May 2008 09:47 GMT
I've no idea which method would be faster, but CPYF might be less
'scary' if your shop is not used to SQL.