Moving STMMLOG to another location

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).
>

bwmiller16@gmail.com wrote:>
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

Ian wrote:>>>>

On Mar 28, 2:12 am, Knut Stolze <sto...@de.ibm.comwrote:
>>>>>>
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.
>

Liam Finnie wrote:>>
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,

On Mar 28, 4:33 pm, Ian <ianb...@mobileaudio.comwrote:
>
>
>>>>>>
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.