SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
04-20-2008, 03:21 PM
| ||||
| ||||
 slow performance for one group of tables 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      |
|
04-20-2008, 03:21 PM
| ||||
| ||||
| Re: slow performance for one group of tables 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 |
Linear Mode
