RE: oncockpit showing incorrect onconfig values

> Over the weekend I made some changes to my onconfig, BUFFERS > from 75000 to > 80000, CLEANERS and LRUS from 25 to 67. I then bounced the engine. > Onstat -R reports the correct figures as you would expect from above. > However, if I monitor the instance using oncockpit (shared memory --> > buffers) the old values are reported in the buffer related parameters > section of the output. However if I scroll down the window > there are 67 LRU > queues listed! I'm now concerned that there may be some > corruption in the > instance. There are no errors on the log from the restart, just the > messages about the changes to the parameters. > > Is this a problem with the engine or just a bug in oncockpit? I have no idea :-) but I'll hazard a guess anyway. I would think that oncockpit may get it's values from the environment variable ONCONFIG. I would also imagine that when it displays the actual LRU queues that it would get them from the output of an onstat command( or at least the same sql as the onstat would use ). To really get the correct values you should use onstat -c instead of oncockpit. The use of onstat will almost always be safer than oncockpit and in truth there is seldom any reason to use oncockpit at all. The ONLY advantage that oncockpit has is that it can change some parameters on the fly. I forget which ones but would guess that it is the tape parameters. Jo ___________________________________________________________________________ This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Sema Group. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error please notify the Sema Group Helpdesk by telephone on +44 (0) 121 627 5600. ___________________________________________________________________________

see below -- Tony Flaherty Snr. A/P, Informix DBA, HpUx Admin, Gimmi a broom! MFS Ltd. COOPER, Joseph wrote in message <8q5dgs$ai4$1@news.xmission.com>... > >> Over the weekend I made some changes to my onconfig, BUFFERS >> from 75000 to >> 80000, CLEANERS and LRUS from 25 to 67. I then bounced the engine. >> Onstat -R reports the correct figures as you would expect from above. >> However, if I monitor the instance using oncockpit (shared memory --> >> buffers) the old values are reported in the buffer related parameters >> section of the output. However if I scroll down the window >> there are 67 LRU >> queues listed! I'm now concerned that there may be some >> corruption in the >> instance. There are no errors on the log from the restart, just the >> messages about the changes to the parameters. >> >> Is this a problem with the engine or just a bug in oncockpit? > >I have no idea :-) but I'll hazard a guess anyway. >I would think that oncockpit may get it's values from the environment >variable ONCONFIG. ? $ONCONFIG points to the onconfig I altered and the values in here are obviously the new ones. >I would also imagine that when it displays the actual LRU queues that it >would get them from the output of an >onstat command( or at least the same sql as the onstat would use ). > >To really get the correct values you should use onstat -c instead of >oncockpit. Although I monitor the instance using onstat commands I like the graphical output of oncockpit for getting a "feel" for the instance status, especially monitoring dbspaces etc. >The use of onstat will almost always be safer than oncockpit and in truth >there is seldom any reason to use oncockpit at all. see above. > >The ONLY advantage that oncockpit has is that it can change some parameters >on the fly. I forget which ones but would guess that it is the tape >parameters. AFAIK You cannot change any paramaters from oncockpit, are you thinking of ONMONITOR? > > >Jo > > > >___________________________________________________________________________ >This email is confidential and intended solely for the use of the >individual to whom it is addressed. Any views or opinions presented are >solely those of the author and do not necessarily represent those of >Sema Group. >If you are not the intended recipient, be advised that you have received this >email in error and that any use, dissemination, forwarding, printing, or >copying of this email is strictly prohibited. > >If you have received this email in error please notify the Sema Group >Helpdesk by telephone on +44 (0) 121 627 5600. >___________________________________________________________________________

Try onmode -R to rebuild the infos file (just to make sure). Doesn't oncockit need something like onprobe running? Restart onprobe! Tony Flaherty wrote in message <8q5fbs$pkc$1@hermes.mfs.misys.co.uk>... >see below > >-- >Tony Flaherty >Snr. A/P, Informix DBA, HpUx Admin, Gimmi a broom! >MFS Ltd. > >COOPER, Joseph wrote in message <8q5dgs$ai4$1@news.xmission.com>... >> >>> Over the weekend I made some changes to my onconfig, BUFFERS >>> from 75000 to >>> 80000, CLEANERS and LRUS from 25 to 67. I then bounced the engine. >>> Onstat -R reports the correct figures as you would expect from above. >>> However, if I monitor the instance using oncockpit (shared memory --> >>> buffers) the old values are reported in the buffer related parameters >>> section of the output. However if I scroll down the window >>> there are 67 LRU >>> queues listed! I'm now concerned that there may be some >>> corruption in the >>> instance. There are no errors on the log from the restart, just the >>> messages about the changes to the parameters. >>> >>> Is this a problem with the engine or just a bug in oncockpit? >> >>I have no idea :-) but I'll hazard a guess anyway. >>I would think that oncockpit may get it's values from the environment >>variable ONCONFIG. > >? $ONCONFIG points to the onconfig I altered and the values in here are >obviously the new ones. > >>I would also imagine that when it displays the actual LRU queues that it >>would get them from the output of an >>onstat command( or at least the same sql as the onstat would use ). >> >>To really get the correct values you should use onstat -c instead of >>oncockpit. > > >Although I monitor the instance using onstat commands I like the graphical >output of oncockpit for getting a "feel" for the instance status, especially >monitoring dbspaces etc. > >>The use of onstat will almost always be safer than oncockpit and in truth >>there is seldom any reason to use oncockpit at all. > >see above. > >> >>The ONLY advantage that oncockpit has is that it can change some parameters >>on the fly. I forget which ones but would guess that it is the tape >>parameters. > > >AFAIK You cannot change any paramaters from oncockpit, are you thinking of >ONMONITOR? > > >> >> >>Jo >> >> >> >>__________________________________________________________________________ _ >>This email is confidential and intended solely for the use of the >>individual to whom it is addressed. Any views or opinions presented are >>solely those of the author and do not necessarily represent those of >>Sema Group. >>If you are not the intended recipient, be advised that you have received >this >>email in error and that any use, dissemination, forwarding, printing, or >>copying of this email is strictly prohibited. >> >>If you have received this email in error please notify the Sema Group >>Helpdesk by telephone on +44 (0) 121 627 5600. >>__________________________________________________________________________ _ >

Doh! <Smacks forehead> Yep, restarting onprobe did the trick, Thanks! -- Tony Flaherty Snr. A/P, Informix DBA, HpUx Admin, Gimmi a broom! MFS Ltd. smooth1 wrote in message <39c6975b_1@news1.vip.uk.com>... >Try onmode -R to rebuild the infos file (just to make sure). > >Doesn't oncockit need something like onprobe running? > >Restart onprobe! > >Tony Flaherty wrote in message <8q5fbs$pkc$1@hermes.mfs.misys.co.uk>... >>see below >> >>-- >>Tony Flaherty >>Snr. A/P, Informix DBA, HpUx Admin, Gimmi a broom! >>MFS Ltd. >> >>COOPER, Joseph wrote in message <8q5dgs$ai4$1@news.xmission.com>... >>> >>>> Over the weekend I made some changes to my onconfig, BUFFERS >>>> from 75000 to >>>> 80000, CLEANERS and LRUS from 25 to 67. I then bounced the engine. >>>> Onstat -R reports the correct figures as you would expect from above. >>>> However, if I monitor the instance using oncockpit (shared memory --> >>>> buffers) the old values are reported in the buffer related parameters >>>> section of the output. However if I scroll down the window >>>> there are 67 LRU >>>> queues listed! I'm now concerned that there may be some >>>> corruption in the >>>> instance. There are no errors on the log from the restart, just the >>>> messages about the changes to the parameters. >>>> >>>> Is this a problem with the engine or just a bug in oncockpit? >>> >>>I have no idea :-) but I'll hazard a guess anyway. >>>I would think that oncockpit may get it's values from the environment >>>variable ONCONFIG. >> >>? $ONCONFIG points to the onconfig I altered and the values in here are >>obviously the new ones. >> >>>I would also imagine that when it displays the actual LRU queues that it >>>would get them from the output of an >>>onstat command( or at least the same sql as the onstat would use ). >>> >>>To really get the correct values you should use onstat -c instead of >>>oncockpit. >> >> >>Although I monitor the instance using onstat commands I like the graphical >>output of oncockpit for getting a "feel" for the instance status, >especially >>monitoring dbspaces etc. >> >>>The use of onstat will almost always be safer than oncockpit and in truth >>>there is seldom any reason to use oncockpit at all. >> >>see above. >> >>> >>>The ONLY advantage that oncockpit has is that it can change some >parameters >>>on the fly. I forget which ones but would guess that it is the tape >>>parameters. >> >> >>AFAIK You cannot change any paramaters from oncockpit, are you thinking of >>ONMONITOR? >> >> >>> >>> >>>Jo >>> >>> >>> >>>_________________________________________________________________________ _ >_ >>>This email is confidential and intended solely for the use of the >>>individual to whom it is addressed. Any views or opinions presented are >>>solely those of the author and do not necessarily represent those of >>>Sema Group. >>>If you are not the intended recipient, be advised that you have received >>this >>>email in error and that any use, dissemination, forwarding, printing, or >>>copying of this email is strictly prohibited. >>> >>>If you have received this email in error please notify the Sema Group >>>Helpdesk by telephone on +44 (0) 121 627 5600. >>>_________________________________________________________________________ _ >_ >> > >