Re: Slow system after rebuilding tables

I know that this is very obvious, but any way here it goes. Have you run update statistics after loading the data? Tino 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