Tivoli Storage Manager sometimes triggers frequent reorganization of a collection database

The Tivoli Storage Manager version that is used in Information Archive can sometimes trigger frequent reorganization of the collection database. This situation can degrade the performance of the database.


The frequent attempts to reorganize the database occur because the automatic reorganization does not succeed.

Diagnosing the problem

Log on to the administrative interface with a user ID that has the tsmAdministrator role.

  1. Expand the ‘Tivoli Storage Manager’ menu item, select Manage Servers and select the server to be checked.
  2. On the ‘Server Properties’ page select ‘Activity Log’ and press Update Table.

If the problem exists, the activity log contains frequently logs lines similar to the following example, for example every 10 minutes:

2011-05-06 00:57:21 ANR0293I Reorganization for table AF.Clusters started.
2011-05-06 00:57:26 ANR0294I Reorganization for table AF.Clusters ended.


Resolving the problem

If the problem occurs, you must switch off automatic reorganization temporarily and initiate a manual reorganization. The automatic reorganization is switched on again after the problem is resolved.

Notes about the procedure:

  • The steps require root access to the cluster nodes. If enhanced tamper protection is set, you must install the Emergency Support Access (ESA) patch on the appliance. To obtain the ESA patch, go to the following website:
  • For the purpose of this example, the user is initially logged on to cluster node server ianode1.
  • The collection in the following example is named “FILE02”. Substitute the correct collection name when you run the commands in the instructions.
  • All examples include the command prompt text and the expected results.

Complete the following steps to resolve the problem:
1. From the KVM console, log onto a cluster node server and change to the root user:

iaadmin@ianode1:~> su
2. Change to the /tsm directory for the collection and back up the dsmserv.opt file:

ianode1:~ # cd /tiam/FILE02/tsm/
ianode1:/tiam/FILE02/tsm # cp dsmserv.opt dsmserv.opt.orig
3. Append “ALLOWREORGTABLE NO” to the end of the dsmserv.opt file:

ianode1:/tiam/FILE02/tsm # echo "" >> dsmserv.opt
ianode1:/tiam/FILE02/tsm # echo "ALLOWREORGTABLE NO" >> dsmserv.opt
4. Log on to the Information Archive administrative interface:

    1. Ensure that there is no collection I/O activity and suspend the collection by clickingInformation Archive > System Overview > Collections, and the Suspend collection icon.
    2. Resume the collection. The new “ALLOWREORGTABLE” server setting is now active.

5. Change back to the cluster node and find the DB2 instance user for the collection.

You can complete this action on any of the cluster nodes:

ianode1:/tiam/FILE02/tsm # ls -d /tiam/*/tsm/u*

Sample output:


In the example, the DB2 instance user is “u1”.
6. Locate the cluster node where the Tivoli Storage Manager server is currently running:

ianode1:/tiam/FILE02/tsm # mb_display_location.py -r -t
7. Locate the line containing “tsm” and the collection name in the output.

In this example, the Tivoli Storage Manager server for collection “FILE02” is running on ianode2.

Sample output:

start of /opt/tivoli/tiam/bin/mb_display_location.py.
GPFS nodeset Node list
————- ——————————————————-
ianode1 ianode1 ianode2

GPFS nodeset Node list
————- ——————————————————-
ianode1 ianode1 ianode2

returned from /opt/tivoli/tiam/bin/mb_display_location.py:|ianode1||||ianode1|ctdb|||ianode2||||ianode2|ctdb|||ianode2|tsm|FILE02|
end of /opt/tivoli/tiam/bin/mb_display_location.py. (None)

8. If the Tivoli Storage Manager server is running on a different cluster node than where you are currently logged on as root, log on to the cluster node where the Tivoli Storage Manager server is running.

ianode1:/var/opt/tivoli/tiam/log # ssh ianode2
Last login: Fri Apr 29 10:39:26 2011 from ianode1
9. Change the properties of the DB2 database, by completing the following steps:

a. Change to the DB2 instance user and run the following command:

ianode2:~ # su - u1
b. Run the following command to “source” the DB2 profile:

u1@ianode2:~> .  ~/sqllib/db2profile
c. Connect to the Tivoli Storage Manager database:

u1@ianode2:~> db2 connect to TSMDB1
Expected result:

Database Connection Information

Database server        = DB2/LINUXX8664 9.5.5
SQL authorization ID   = U1
Local database alias   = TSMDB1

d. Manually reorganize the database, by running the following command:
u1@ianode2:~> db2 reorg table TSMDB1.AF_CLUSTERS

Expected result:

DB20000I  The REORG command completed successfully.
e. Run the DB2 “RUNSTATS” command:


Expected result:

DB20000I  The RUNSTATS command completed successfully.
f. Exit from the DB2 instance user, by running the following command:

u1@ianode2:~> exit

Expected results:

g. If you changed to a different cluster node server to run the DB2 commands, change back to the cluster node where you were originally logged on, by running the following command:

ianode2:~ # exit
Expected results:

Connection to ianode2 closed.
10. Restore the backup of the dsmserv.opt file:

ianode1:/var/opt/tivoli/tiam/log # cp dsmserv.opt.orig dsmserv.opt
11. Change back to the administrative interface, and complete the following steps:

    1. Suspend the collection.
    2. Resume the collection.

The original Tivoli Storage Manager server setting is now active. The automatic database reorganization is switched on again.

Related information

TSM database considerations




, ,

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: