RE: SQL optimize for only writes

Simple INSERTs do NOT use a table scan. Database monitor is misleading you.

To enhance it, use blocked inserts.
Also, if you're doing 400K inserts, you might think about doing some of it
in parallel (i.e. submit 4 jobs/threads that perform 100K inserts each).
Stop journaling or use commitment control.
Change any keyed LFs or SQL indexes or PF keys access path maintenance to
delayed or rebuild, then switch it back to *IMMED once done.
Disable any unnecessary triggers until massive INSERT finishes.
Get faster hardware :)

All that said, I think you're best off taking a step back and having another
look at your scenario. You might be able to run an INSERT with a sub-SELECT
that inserts all of the records at once, rather than one-at-a-time as you're
doing it now.

Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com

-----Original Message-----
Subject: SQL optimize for only writes

I have a process that just inserts rows ( INSERT INTO <lib.file>
(field1, field2, etc) VALUES(value1, value2, etc)

things were great.... until I got like 400k records in the file,
then when I wanted to do a lot of writes at near the same time,
performance died.

I see something in the SQL monitor about doing a "table scan" before
each INSERT.
How do I NOT do this? (if I can)

I have no key on this physical.
Should I create this file differently?
Does someone have the "perfect example" of a process that only writes to
a BIG FILE?


Thanks

Gerald