Re: Statistics causing Shared Memory Problems

james, > night we load mainframe data and update existing tables and insert new information. you say each night you load the data. are you a 24x7 shop? so you can't run the update statistics at night after the load is done? or are there users then as well. obviously it doesn't matter if the system locks other processes out if there are few or no users to lock out. > over an hour, and forces online to grab new shared memory segments. Well, while it > is doing this, users get locked out of the system - the login's hang, and I ge i have seen similar things, running large queries on tables where no statistics have been generated took all the system resource, and kept all other users at bay. it didn't grab lots of memory though. > had been overloaded. Is this normal behavior??? The speed increases on the table this should not be normal behaviour, but i don't know the work around either. i would try running the update stats at a time, as i mentioned earlier, when there are few or no users, set the MAXPDQPRIORITY to 100, and set the pdqpriority of the update stats to 100. i haven't tried it, but i believe that an update stats can make some use of pdq, and if it grabs pdq resources it might be able to get the job done quicker. seems to me that it's worth a try. if you do this, please post your results, i'm curious to know if this helps. mickm