slow performance for one group of tables
Posted in 2007
Topics: Performance & Tuning, Migration, Import/Export & Data Conversion
I have a database where six records were corrupt. One of the fields
that was corrupt was a date field so it would not allow an export to
complete. In transaction mode I updated the date field to an
acceptable value and unloaded the table. The unload revealed that
those 6 records had a ton of fields with bad data so I corrected the
unload file for those six records. Then (again in transaction mode) I
"set constraints all deferred", dropped the table, rebuilt the table,
and reloaded the table with the corrected unload file. Now we're
having performance issues just for queries related to this table. All
other tables not related to this one run just fine.
onstat -p shows bufwrits %cached at 94.81.
update statistics low has been run for this table.distributions have been dropped for this table.
update statistics high has been run for this table.
Still no improvement. Any ideas?
Informix 9.3
laurad@dis-corp.com wrote:
> I have a database where six records were corrupt. One of the fields
> that was corrupt was a date field so it would not allow an export to
> complete. In transaction mode I updated the date field to an
> acceptable value and unloaded the table. The unload revealed that
> those 6 records had a ton of fields with bad data so I corrected the
> unload file for those six records. Then (again in transaction mode) I
> "set constraints all deferred", dropped the table, rebuilt the table,
> and reloaded the table with the corrected unload file. Now we're
> having performance issues just for queries related to this table. All
> other tables not related to this one run just fine.
>
> onstat -p shows bufwrits %cached at 94.81.>
> update statistics low has been run for this table.> distributions have been dropped for this table.
> update statistics high has been run for this table.>
> Still no improvement. Any ideas?
>
> Informix 9.3
The problem could be lots of things. Update stats is always a good place to
start, but you seem to have that covered. I take it from the rather cryptic
onstat output snatch that you suspect a more general performance problem.
Sone things:
- It may be that the table is badly fragmented. Did you set the EXTENT
SIZE/NEXT SIZE to hold all or at least large percentages of the data in a
single or small number of extents? Check that.
- Is it possible that the reload caused the table to move to a different
chunk(s) or to cross chunk boundaries? Perhaps the new chunk is on an
inside track/cylinder?
- Also, if the indexes were built before the load or afterwards with a low
FILL FACTOR the indexes may be less efficient than they could be.
- How is the server itself performing for other requests? What are the BR,
BTR, and RAU values?
Art S. Kagel