Re: Slow system after rebuilding tables

If you haven't alreadry then try to run UPDATE STATISTICS on the newly loaded data. The optimizer needs this information after the massive load the table had gone through. Regards, Amgad Al-Sisi Paul Finkel wrote: > > My system (instance of ONLINE) and the machine (NCR 3435) are running very > slowly. > History: > > on 4/23/98 we dumped the data from two of our major tables ("case" and > "person") > modified the text files to accomodate the change to the tables > rebuilt the tables with the modified schemas and reloaded data. > Then we rebuilt indexes. > > The "case" table is in its own dbspace, the "person" table is in the dbspace > set aside for the rest of the database. The root dbspace is seperate from > the other two dbspaces. The only thing that I know of that is different from > before (other than two new fields) is that when I built the "case" table in > its own dbspce, I created the first extent with a size just a little smaller > than the size of the dbsapce at the suggestion of Informix tech support. > That seems to make sense to me: one big extent. > > Another note: the "case" dbspace and the "production" dbspace (the rest of > the database) are on seperate slices, but on the same disk device, however > they were that way before the migration of the data took place. > > Now, in addition to the users complaining about the speed of simsply > queries, if I run > the UNIX command "ps -ef|grep oninit" I see that the oninits associated with > this instance that are "cpu" threads have very long run times. > > If I run the UNIX command "sar -d 1 10" to look at the devices, I see that > the device that the two dbspaces is on has very high average usage > (90 -100%). Obviously that indicates a slow down. > > Why would the changes to those two tables that I made be slowing things > down? The new fields didn't increase the size of the data substantially. > Here is another piece of information: users are reporting that reports > (which almost always involve the "case" table) are being returned quickly. > That makes sense consdiering that the "case" data is contiguous. Why is the > device taking such a hit? (I am planning to move data around at some future > date, but it won't be easy due to limited resources) > > Please respond by e-mail and post. > > Thank you > Paul Finkel > AT&T > 732-457-5170