Re: Update Statistics, Error -647

Yeah, killing update stats sometimes kills it there and then and other times takes hours to stop. The larger the update stats / bigger the table or (number of indexes * rows etc.), the longer it takes to stop ! Never bothered working out if it's the low or high/medium that is in some kind of special update stats critical session as opposed to a normal thread / session. It normally stops in under an hour or so for me and I'm guessing your DB is large, but on 1 occasion, I killed the instance when it looked like neverending (we have a table that takes 8 hours to build stats on even with high pdq / memory) and then fixed stats up again. Let us/c.d.i know what tech supports answer is regarding 'special - update stats internal critical sections'. Superboer wrote: > contact TS > > > Is it standard behavior that update statistics session cannot be killed? > > no, it sounds like this session is gone walkabout. > > Superboer. > > > Habichtsberg, Reinhard schreef: > > > IDS 9.40 FC4W2 > > Solaris 9 > > > > Two questions about update statistics: > > 1. onstat -g sid reports: > > 761708 UPDATE STATIST aze CR Not Wait -647 0 > > 9.03 Off > > Current SQL statement : > > update statistics medium> > > > finderr 647: Error evaluating math library function function-name > > The data type of the argument is correct, but the value passed to > > the > > function is not appropriate for the math function. Check that you > > are > > passing a legitimate value to the function. > > > > The session is running and causes some workload. > > > > I have no idea of the reason and implications of that error. Any > > suggestions? > > > > 2. I cannot kill sessions which are running update statistics with onmode -z > > sid. Also killing the calling unix process has no effect. > > Is it standard behavior that update statistics session cannot be killed? > > > > TIA, > > Reinhard.

PeterP wrote: > Yeah, killing update stats sometimes kills it there and then and other > times takes hours to stop. The larger the update stats / bigger the > table or (number of indexes * rows etc.), the longer it takes to stop ! Yes, I had the same experience testing dostats. The fix in dostats was to trap SIGINT and SIGQUIT (CTRL-C or kill -INT or kill -QUIT) and in the signal handler do a call to the sqlbreak(); function in each connection and then explicitely DISCONNECT ALL. That has improved the server's recovery from killed stats. Note that doing a kill -9 (or kill -KILL) to dostats will still leave you waiting for the last UPDATE STATISTICS command to complete and rollback, but if ^C out, dostats does its best to shorten the wait. If you are doing the UPDATE STATISTICS from a dbaccess session manually and interrupt it with ^C, the best you can do is to exit from dbaccess gracefully so that it does an explicit rollback and disconnect. Art S. Kagel > Never bothered working out if it's the low or high/medium that is in > some kind of special update stats critical session as opposed to a > normal thread / session. It normally stops in under an hour or so for > me and I'm guessing your DB is large, but on 1 occasion, I killed the > instance when it looked like neverending (we have a table that takes 8 > hours to build stats on even with high pdq / memory) and then fixed > stats up again. > > Let us/c.d.i know what tech supports answer is regarding 'special - > update stats internal critical sections'. > > Superboer wrote: > >>contact TS >> >> >>>Is it standard behavior that update statistics session cannot be killed? >> >>no, it sounds like this session is gone walkabout. >> >>Superboer. >> >> >>Habichtsberg, Reinhard schreef: >> >> >>>IDS 9.40 FC4W2 >>>Solaris 9 >>> >>>Two questions about update statistics: >>>1. onstat -g sid reports: >>> 761708 UPDATE STATIST aze CR Not Wait -647 0 >>>9.03 Off >>> Current SQL statement : >>> update statistics medium>>> >>> finderr 647: Error evaluating math library function function-name >>> The data type of the argument is correct, but the value passed to >>>the >>> function is not appropriate for the math function. Check that you >>>are >>> passing a legitimate value to the function. >>> >>> The session is running and causes some workload. >>> >>> I have no idea of the reason and implications of that error. Any >>>suggestions? >>> >>>2. I cannot kill sessions which are running update statistics with onmode -z >>>sid. Also killing the calling unix process has no effect. >>>Is it standard behavior that update statistics session cannot be killed? >>> >>>TIA, >>>Reinhard. > >