PUT cursor very very very slow ... but it works with no error ! WHY ?
Posted in 2000
Topics: Storage & Space Management, Logging & Checkpoints, Versions, Editions & End-of-Life
SCO OpenServer 3.2V5.0.5
IDS 7.30 UC2
HP 2 CPU - 512 MB - 2 mirrored HD of 9 GB each
IDS: chunks in raw devices - 1 database of about 2 GB (370 tables)
-----------------
App: pay-roll
When computing for a few salaries, an CURSOR FOR INSERT takes more than
5 minutes to insert a single row in an approximately empty table !!! It
finally succeeds but it's far too long for such an insert.
There are many other Inserts, Deletes and Updates in other tables and
they're done in less than a 1/10 second.
oncheck -cI doesn't report anything but takes more than a minute to
check ... 1000 rows !
oncheck -pT report 37 extents for a global size of 14000 pages (Isuppose it shows that the table is sometimes filled with thousands of
rows which are deleted later)
I drop and recreate indexes before recomputing the same job: it works
fine for a few hours only
Last chance: I dropped indexes again, renamed the table to an unused
name and recreated the table to load my 1000 rows back. By this way I
try to isolate the physical space allocated by the old table.
Now, every SELECT and oncheck is ok and takes no time to perform on the
new table (as I could expect it of course) but when real jobs will have
to be performed, this table will be filled and flushed many times (it
wil take some weeks). What if the same problem arise ?
I also think that Unix can't report any trouble in case of HD damage
because of the raw device choice but can Informix report something ?
I found nothing in online.log except from Checkpoint every five minutes
and I noticed that they need from 4 to 6 or 7 seconds each when my
program is blocking on my long INSERT statements and it's unusual
because they are usually completed in 0 or 1 second.
Any idea ?
>Subject: PUT cursor very very very slow ... but it works with no error ! WHY
>?
>From: Laurent COLLIGNON lcollignon@imsii.fr
>Date: 13.04.00 10:19 W. Europe Daylight Time
>Message-id: <38F58303.70A0C5EA@imsii.fr>
>
>SCO OpenServer 3.2V5.0.5
>IDS 7.30 UC2
>
>HP 2 CPU - 512 MB - 2 mirrored HD of 9 GB each
>IDS: chunks in raw devices - 1 database of about 2 GB (370 tables)
>-----------------
>
>App: pay-roll
>
>When computing for a few salaries, an CURSOR FOR INSERT takes more than
>5 minutes to insert a single row in an approximately empty table !!! It
>finally succeeds but it's far too long for such an insert.
>There are many other Inserts, Deletes and Updates in other tables and
>they're done in less than a 1/10 second.
>
>oncheck -cI doesn't report anything but takes more than a minute to
>check ... 1000 rows !
>oncheck -pT report 37 extents for a global size of 14000 pages (I>suppose it shows that the table is sometimes filled with thousands of
>rows which are deleted later)
>I drop and recreate indexes before recomputing the same job: it works
>fine for a few hours only
>
>Last chance: I dropped indexes again, renamed the table to an unused
>name and recreated the table to load my 1000 rows back. By this way I
>try to isolate the physical space allocated by the old table.
>
>Now, every SELECT and oncheck is ok and takes no time to perform on the
>new table (as I could expect it of course) but when real jobs will have
>to be performed, this table will be filled and flushed many times (it
>wil take some weeks). What if the same problem arise ?
>
>I also think that Unix can't report any trouble in case of HD damage
>because of the raw device choice but can Informix report something ?
>I found nothing in online.log except from Checkpoint every five minutes
>and I noticed that they need from 4 to 6 or 7 seconds each when my
>program is blocking on my long INSERT statements and it's unusual
>because they are usually completed in 0 or 1 second.
>
>Any idea ?
>
>
>
>
>
>
try detaching the indexes from that table.
Nona