DB2 FOR LUW / DB2FORLUW / B10 - DB2

Db2support tool might require a long time to complete on AIX
system which have a large number of volume groups and logical
volumes. Slow section will be the one after:
"Basic operating system and hardware information"

is displayed on the screen. db2support.log file, included in the
final archive, will indicate a long time spent within "Disk"
section, e.g:

...
2019-01-01-20.26.29.690710 [db2os.C:820] -> Disk
2019-01-01-21.34.54.108958 [db2os.C:820] -> Disk
...
(over 1h here in the example)

During the data collection the following command will be
executing on the system (this can be checked e.g. in "ps"):

sh -c for vg in `lsvg -o`; do for fs in `lsvgfs $vg`; do printf
"%-22s" $fs; for disk in `lsvg -p $vg | tail +3 | awk '{print
$1}'`; do lspv -l $disk | grep -q " ${fs}$" && printf "%-8s"
$disk; done; echo; done; done

This section will be executed regardless of "-s/-system_detail"
switch being used or not

****************************************************************
* USERS AFFECTED:                                              *
* ALL                                                          *
****************************************************************
* PROBLEM DESCRIPTION:                                         *
* See Error Description                                        *
****************************************************************
* RECOMMENDATION:                                              *
* Upgrade to Db2 11.1 Mod 4 Fixpack 5 or higher                *
****************************************************************

There is no switch to disable lsvg collection by db2support on
AIX. The only way to skip the step is to force command failure
by e.g. creating temporarily a "dummy" lsvg executable in PATH
to force a failure of the command. E.g.:

$ touch ./lsvg
$ chmod +x lsvg
$ export PATH=$(pwd):$PATH
$ db2support 
$ rm ./lsvg

This will *not* affect other diagnostics collected by
db2support.

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

25.07.2019
16.01.2020
16.01.2020