By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,760 Members | 955 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,760 IT Pros & Developers. It's quick & easy.

Howto: Emergency SHUTOFF all monitoring & stats collections?!

P: n/a
Well folks, I didn't heed the warnings (that excessive monitoring,
statistics, etc. can cause a performance hit) and I have been playing
around with all kinds of monitors, snapshots, especially with the gui.
BUT! Performance has dropped 70%! The monitors show that the the most
system overhead is caused by these selects themselves.
Question 1: Is there a big red switch that turns OFF *all* of this type of
activity!
Question 2: If so, can I flip em all on again (just for temp test)?

I definitely need monitoring, but I guess I need to do it one at a time
and measure the impact of that monitor itself, before doing another.

Please advise. Thanks.
nat
Aug 23 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Raj
update the dbm cfg to turn off the monitoring...
ex:
update dbm cfg using DFT_MON_BUFPOOL off ...etc
use monitor switches for temp. monitoring, it will end once you
terminate your session.
ex:
update monitor switches using BUFFERPOOL on LOCK on SORT on STATEMENT
on TABLE on UOW on global;

natG wrote:
Well folks, I didn't heed the warnings (that excessive monitoring,
statistics, etc. can cause a performance hit) and I have been playing
around with all kinds of monitors, snapshots, especially with the gui.
BUT! Performance has dropped 70%! The monitors show that the the most
system overhead is caused by these selects themselves.
Question 1: Is there a big red switch that turns OFF *all* of this type of
activity!
Question 2: If so, can I flip em all on again (just for temp test)?

I definitely need monitoring, but I guess I need to do it one at a time
and measure the impact of that monitor itself, before doing another.

Please advise. Thanks.
nat
Aug 23 '06 #2

P: n/a
Besides monitoring is there other stuff? I am sure I told it to do other
fancy stuff, just don't remember what at this [nerve racking] moment.
Thanks.
On Wed, 23 Aug 2006 13:37:06 -0700, Raj wrote:
update the dbm cfg to turn off the monitoring...
ex:
update dbm cfg using DFT_MON_BUFPOOL off ...etc
use monitor switches for temp. monitoring, it will end once you
terminate your session.
ex:
update monitor switches using BUFFERPOOL on LOCK on SORT on STATEMENT
on TABLE on UOW on global;

natG wrote:
>Well folks, I didn't heed the warnings (that excessive monitoring,
statistics, etc. can cause a performance hit) and I have been playing
around with all kinds of monitors, snapshots, especially with the gui.
BUT! Performance has dropped 70%! The monitors show that the the most
system overhead is caused by these selects themselves.
Question 1: Is there a big red switch that turns OFF *all* of this type of
activity!
Question 2: If so, can I flip em all on again (just for temp test)?

I definitely need monitoring, but I guess I need to do it one at a time
and measure the impact of that monitor itself, before doing another.

Please advise. Thanks.
nat
Aug 23 '06 #3

P: n/a
Fwiw, it seems like it was the STATEMENT monitor. Man, that accumulates
data!
-nat

On Wed, 23 Aug 2006 13:37:06 -0700, Raj wrote:
update the dbm cfg to turn off the monitoring...
ex:
update dbm cfg using DFT_MON_BUFPOOL off ...etc
use monitor switches for temp. monitoring, it will end once you
terminate your session.
ex:
update monitor switches using BUFFERPOOL on LOCK on SORT on STATEMENT
on TABLE on UOW on global;

natG wrote:
>Well folks, I didn't heed the warnings (that excessive monitoring,
statistics, etc. can cause a performance hit) and I have been playing
around with all kinds of monitors, snapshots, especially with the gui.
BUT! Performance has dropped 70%! The monitors show that the the most
system overhead is caused by these selects themselves.
Question 1: Is there a big red switch that turns OFF *all* of this type of
activity!
Question 2: If so, can I flip em all on again (just for temp test)?

I definitely need monitoring, but I guess I need to do it one at a time
and measure the impact of that monitor itself, before doing another.

Please advise. Thanks.
nat
Aug 23 '06 #4

P: n/a
natG wrote:
Fwiw, it seems like it was the STATEMENT monitor. Man, that accumulates
data!
-nat

On Wed, 23 Aug 2006 13:37:06 -0700, Raj wrote:
>update the dbm cfg to turn off the monitoring...
ex:
update dbm cfg using DFT_MON_BUFPOOL off ...etc
use monitor switches for temp. monitoring, it will end once you
terminate your session.
ex:
update monitor switches using BUFFERPOOL on LOCK on SORT on STATEMENT
on TABLE on UOW on global;

natG wrote:
>>Well folks, I didn't heed the warnings (that excessive monitoring,
statistics, etc. can cause a performance hit) and I have been playing
around with all kinds of monitors, snapshots, especially with the gui.
BUT! Performance has dropped 70%! The monitors show that the the most
system overhead is caused by these selects themselves.
Question 1: Is there a big red switch that turns OFF *all* of this type of
activity!
Question 2: If so, can I flip em all on again (just for temp test)?

I definitely need monitoring, but I guess I need to do it one at a time
and measure the impact of that monitor itself, before doing another.

Please advise. Thanks.
nat
*lol*Yes it does.

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Aug 23 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.