The db2diag tool may repeatedly output a segment of an input
db2diag.log file when one of the -t or -H time period specifiers
are used. This will cause the size of the output file to grow
until there is no longer any space available on the underlying
filesystem.
eg. db2diag -H 2d > db2diag.2d.txt (output db2diag.log
messages from the previous 2 days)
In this case, the output file db2diag.2d.txt may grow until
filesystem space is exhausted.
The db2diag tool can be interrupted at any time to discontinue
the build-up of the output file. Try invoking the command again
with a modification of the input time period, or use a piped
version such as :
db2diag [ files ] | db2diag -H 2d > db2diag.2d.txt
The db2diag tool is also invoked with a time specifier by the
db2support diagnostic collection tool. Normally, a temporary
output file is generated which is zipped in the db2support zip
collection and subsequently deleted. However, in the case of
looping output, the db2support tool will wait indefinitely,
allowing the db2diag tool to fill up the target filesystem.
Interrupting the db2support tool will cancel the db2diag tool
invocation, after which db2support will zip up the large output
file and delete it per normal. However, killing the db2support
tool - as is done when interrupting the IIAS apdiag collection
tool or allowing it to timeout - will result in the db2diag tool
continuing to execute, which again will eventually fill up the
filesystem.
To resolve the situation where db2diag is left running filling
up the filesystem after apdiag/db2support have been terminated,
kill the offending db2diag process, then remove the large output
file that was generated. The large temporary output file is
located directly in the DIAGPATH, and is named as one of the
following
db2diag.rotating.log_truncated
db2diag.log_truncated
For example, on an IIAS system:
1. identify any large temporary output files (this can also be
done while db2support/apdiag tool is still running):
ls -l
/opt/ibm/appliance/storage/head/home/db2inst1/sqllib/db2dump/*/d
b2diag* | sort -k 5 -rn | head -1
rw-r--r-- db2inst1 db2grp 1987349876 May 15 21:01
/opt/ibm/appliance/storage/head/home/db2inst1/sqllib/db2dump/NOD
E0017/db2diagRotate.log.opt_out
2. identify the host for member 17, locate the db2diag process
ID (ps -elf | grep db2diag), and kill the db2diag process (kill
)
3. remove the large output file
Note that if the large output file is deleted prior to killing
the db2diag process, the output continues to be generated using
up filesystem space until the db2diag process is killed. This is
the case even though the "ls" command no longer displays the
file.
Several options exist :
1. db2support/apdiag can be retried with a different time period
specification.
2. Archive the current db2diag.log files (db2_all "db2diag -A"),
rerun the db2support/apdiag collection tool, then submit the
relevant archived versions to support (along with the
db2support/apdiag collection itself). Note that in the case or
rotating log file management (DIAGSIZE != 0), it will be
necessary to manually remove archived db2diag.log versions, as
they are not removed by the automatic diagnostics cleanup
management. |
