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

Moving STMMLOG to another location

P: n/a
Folks -

DB2 V9.2 on SUSE 9

Is there a way other than moving the entire /sqllib/db2dump/ (Default
database path (DFTDBPATH) = /home/db2inst1 to move just STMMLOG out
of there to another location away from where it is?

I'd like to either 1). Move STMMLOG without moving db2diag 2).
Prohibit the making of the stmm.1.log file(s).

Thanks,

-B

Mar 27 '07 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Ian
bw********@gmail.com wrote:
Folks -

DB2 V9.2 on SUSE 9

Is there a way other than moving the entire /sqllib/db2dump/ (Default
database path (DFTDBPATH) = /home/db2inst1 to move just STMMLOG out
of there to another location away from where it is?

I'd like to either 1). Move STMMLOG without moving db2diag 2).
Prohibit the making of the stmm.1.log file(s).
Not sure why you'd want to move the stmm log only (as opposed to all of
the db2dump information), but, you could do it with a soft link:

cd /home/db2inst1/sqllib/db2dump
mv stmm /new/location
ln -s /new/location/stmm
Mar 28 '07 #2

P: n/a
Ian wrote:
bw********@gmail.com wrote:
>Folks -

DB2 V9.2 on SUSE 9

Is there a way other than moving the entire /sqllib/db2dump/ (Default
database path (DFTDBPATH) = /home/db2inst1 to move just STMMLOG out
of there to another location away from where it is?

I'd like to either 1). Move STMMLOG without moving db2diag 2).
Prohibit the making of the stmm.1.log file(s).

Not sure why you'd want to move the stmm log only (as opposed to all of
the db2dump information), but, you could do it with a soft link:

cd /home/db2inst1/sqllib/db2dump
mv stmm /new/location
ln -s /new/location/stmm
I wouldn't do that with links. Just set the DIAGPATH configuration
parameter of the DBM config.

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany
Mar 28 '07 #3

P: n/a
On Mar 28, 2:12 am, Knut Stolze <sto...@de.ibm.comwrote:
Ian wrote:
bwmille...@gmail.com wrote:
Folks -
DB2 V9.2 on SUSE 9
Is there a way other than moving the entire /sqllib/db2dump/ (Default
database path (DFTDBPATH) = /home/db2inst1 to move just STMMLOG out
of there to another location away from where it is?
I'd like to either 1). Move STMMLOG without moving db2diag 2).
Prohibit the making of the stmm.1.log file(s).
Not sure why you'd want to move the stmm log only (as opposed to all of
OK, Thanks.

Well, from just after 2:00pm through nearly 8:00pm
I had 277,709 lines of output in 10mb...then a second
log was created taking-up 9mb and 277,709 lines.

stmm.1.log

2007-03-27-14.10.59.653462-360
2007-03-27-21.52.10.713117-360

302,148 lines...10,486,375 bytes

stmm.2.log

2007-03-27-21.52.10.714093-360
2007-03-28-07.58.23.948920-360
277,709 lines...9,657,490 bytes

At this point I'm just going to modify my daily
cron job that maintains the db2diag.log file to
have it blow-away the stmm.n.log files.

Mar 28 '07 #4

P: n/a
On Mar 28, 10:02 am, bwmille...@gmail.com wrote:
On Mar 28, 2:12 am, Knut Stolze <sto...@de.ibm.comwrote:
Ian wrote:
bwmille...@gmail.com wrote:
>Folks -
>DB2 V9.2 on SUSE 9
>Is there a way other than moving the entire /sqllib/db2dump/ (Default
>database path (DFTDBPATH) = /home/db2inst1 to move just STMMLOG out
>of there to another location away from where it is?
>I'd like to either 1). Move STMMLOG without moving db2diag 2).
>Prohibit the making of the stmm.1.log file(s).
Not sure why you'd want to move the stmm log only (as opposed to all of

OK, Thanks.

Well, from just after 2:00pm through nearly 8:00pm
I had 277,709 lines of output in 10mb...then a second
log was created taking-up 9mb and 277,709 lines.

stmm.1.log

2007-03-27-14.10.59.653462-360
2007-03-27-21.52.10.713117-360

302,148 lines...10,486,375 bytes

stmm.2.log

2007-03-27-21.52.10.714093-360
2007-03-28-07.58.23.948920-360
277,709 lines...9,657,490 bytes

At this point I'm just going to modify my daily
cron job that maintains the db2diag.log file to
have it blow-away the stmm.n.log files.
Just FYI - these STMM log files are circular - you should see at most
5 of these files, after which time STMM will start re-using the old
log files (unlike the db2diag.log, which is always appended to). So,
the STMM log files should consume at most 50MB of total disk space.

Cheers,
Liam.

Mar 28 '07 #5

P: n/a
Ian
Liam Finnie wrote:
Just FYI - these STMM log files are circular - you should see at most
5 of these files, after which time STMM will start re-using the old
log files (unlike the db2diag.log, which is always appended to). So,
the STMM log files should consume at most 50MB of total disk space.

Cheers,
Liam.
Liam,

Just out of curiosity: Why are the STMM log files separated out of the
db2diag.log? The stmm logs are in the same format, and can be queried
with the db2diag tool, so... ?

Thanks,
Mar 28 '07 #6

P: n/a
On Mar 28, 4:33 pm, Ian <ianb...@mobileaudio.comwrote:
Liam Finnie wrote:
Just FYI - these STMM log files are circular - you should see at most
5 of these files, after which time STMM will start re-using the old
log files (unlike the db2diag.log, which is always appended to). So,
the STMM log files should consume at most 50MB of total disk space.
Cheers,
Liam.

Liam,

Just out of curiosity: Why are the STMM log files separated out of the
db2diag.log? The stmm logs are in the same format, and can be queried
with the db2diag tool, so... ?

Thanks,
Hi Ian,

If I remember correctly, the main reason is that we didn't want STMM
to flood the db2diag.log with information that is not typically that
important. Whenever STMM does make a tuning decision (increase the
size of a bufferpool, decrease the package cache size, etc), that
change will be reflected in the db2diag.log. What shows up in the
STMM log is more along the lines of internal metrics that led STMM to
conclude it should increase or decrease any particular memory
consumer.

So, the only time you should need to look in the STMM log (or likely,
that customer support would want to see the STMM log) is if we suspect
STMM is not making the right decisions for some reason. And, in those
cases, we're only usually concerned with recent tuning metrics (which
is why old STMM logs are re-used). So, logging all those metrics to
the db2diag.log would consume a lot of disk space, and it might cause
so much noise that other, more urgent, db2diag.log entries are missed.

Cheers,
Liam.

Mar 29 '07 #7

P: n/a
On Mar 29, 7:07 am, "Liam Finnie" <lfin...@ca.ibm.comwrote:
On Mar 28, 4:33 pm, Ian <ianb...@mobileaudio.comwrote:
Liam Finnie wrote:
Just FYI - these STMM log files are circular - you should see at most
5 of these files, after which time STMM will start re-using the old
log files (unlike the db2diag.log, which is always appended to). So,
the STMM log files should consume at most 50MB of total disk space.
Cheers,
Liam.
Liam,
Just out of curiosity: Why are the STMM log files separated out of the
db2diag.log? The stmm logs are in the same format, and can be queried
with the db2diag tool, so... ?
Thanks,

Hi Ian,

If I remember correctly, the main reason is that we didn't want STMM
to flood the db2diag.log with information that is not typically that
important. Whenever STMM does make a tuning decision (increase the
size of a bufferpool, decrease the package cache size, etc), that
change will be reflected in the db2diag.log. What shows up in the
STMM log is more along the lines of internal metrics that led STMM to
conclude it should increase or decrease any particular memory
consumer.

So, the only time you should need to look in the STMM log (or likely,
that customer support would want to see the STMM log) is if we suspect
STMM is not making the right decisions for some reason. And, in those
cases, we're only usually concerned with recent tuning metrics (which
is why old STMM logs are re-used). So, logging all those metrics to
the db2diag.log would consume a lot of disk space, and it might cause
so much noise that other, more urgent, db2diag.log entries are missed.

Cheers,
Liam.
Liam -

I appreciate your thoughtful answer to this question...and FYI from my
experience the STMM manager is working really well....we enjoy
watching it make memory changes on the fly as the needs change.

I say Congrats to IBM and you folks for a nice implementation.

-B

Mar 29 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.