Performance Tuning for Content Manager

376 Performance Tuning for Content Manager

physical disk (where they start when they first arrive) to Tivoli Storage Manager.

When a document is migrated from hard disk to TSM, the RMOBJECTS table is

updated so that the document’s obj_actiondate is changed and its obj_volumeid is

changed to the volumeid for the proper TSM Management class.

A slow migrator can be resolved by using new TSM API client software and

tuning the Resource Manager tables. Also, Content Manager Version 8.3

improved the performance of the migrator.

12.6.1 Tivoli Storage Manager

In one scenario, the Content Manager system was running on the Windows

platform, and the migrator was moving data from hard disk to TSM. However, only

30,000 documents were migrated every day, and this was less than the business

requirement for migrating documents to TSM. We found that the Content Manager

system was using TSM API 5.1.5 on the Resource Manager server. Based on our

experience, TSM API 5.3 provided better performance, so we upgraded TSM API

Client to V5.3. Now, the migrator can fulfill the business requirement and migrate

about 300,000 documents per day to the TSM server.

In another scenario, there was a performance issue when backing up data from

hard disk to TSM. We asked the TSM administrator to see whether the TSM

server could be tuned. Configuration changes significantly improved performance.

In yet another scenario, Content Manager data was stored on TSM-managed

optical platters. During peak usage hours, storage and retrieval of objects was

taking too long. A simple way to improve performance of both store and retrieve

operations was needed. The easiest way to resolve this issue was to add

sufficient disk space to Tivoli Storage Manager, and use Tivoli Storage Manager

commands to move the data from the optical platters to disk. No changes in

Content Manager were necessary when doing this.

12.6.2 Tune the Resource Manager database

In one scenario, there were millions of rows in the RMOBJECTS table, the

migrator used almost 100% of CPU, and the overall system performance was

very bad. DB2 UDB snapshot showed that the system took about 700 seconds to

run each following SQL in one case. (“Snapshot monitoring” on page 296

describes how to get a DB2 snapshot).

The three SQL SELECT statements below are all legitimate candidate selection

queries generated by the Resource Manager migrator for each volume during the

Chapter 12. Troubleshooting performance problems 377

migration. The first one is to select candidates for migration, the second is to

select candidates for the regular delete, and the third is for the threshold delete:

SELECT OBJ_ITEMID,OBJ_VERSION,OBJ_LIBRARYID,OBJ_COLLECTIONID,

OBJ_STGCLASSID,OBJ_MGTCLASSID

FROM RMADMIN.RMOBJECTS

WHERE OBJ_VOLUMEID = 1 AND

OBJ_ACTIONDATE <= CURRENT DATE AND

(OBJ_STATUS = 'A' OR OBJ_STATUS='B') AND

OBJ_ITEMID>' ' AND

OBJ_LIBRARYID=1

ORDER BY OBJ_ITEMID, OBJ_STGCLASSID;

SELECT OBJ_ITEMID,OBJ_VERSION,OBJ_LIBRARYID,OBJ_COLLECTIONID,OBJ_STATUS

FROM RMADMIN.RMOBJECTS

WHERE OBJ_VOLUMEID = 1 AND (OBJ_STATUS= 'D' OR OBJ_STATUS='G')

ORDER BY OBJ_ITEMID;

SELECT OBJ_ITEMID,OBJ_VERSION,OBJ_LIBRARYID,OBJ_COLLECTIONID,

OBJ_STGCLASSID,OBJ_MGTCLASSID

FROM RMADMIN.RMOBJECTS

WHERE OBJ_VOLUMEID = 1 AND

OBJ_ACTIONDATE <> '12/31/9999' AND

OBJ_STATUS = 'D' OR OBJ_STATUS='G')

ORDER BY OBJ_ITEMID DESC;

We performed a DB2 explain on these SQL statements. Based on the explain

data, we created some additional indexes and ran runstats. Then the DB2 UDB

optimizer picked a good access plan that completed the rmobjects SELECT

statements in 0.5-0.6 seconds.

Here are the indexes we created and the runstats we ran:

CREATE INDEX RMADMIN.IDX_MIGRATOR ON RMADMIN.RMOBJECTS

( OBJ_VOLUMEID ASC, OBJ_STATUS ASC, OBJ_ACTIONDATE ASC, OBJ_LIBRARYID

ASC )

PCTFREE 10 MINPCTUSED 10

COLLECT DETAILED STATISTICS ;

CREATE INDEX "RMADMIN "."IDX_MIGRATOR2" ON "RMADMIN "."RMOBJECTS"

("OBJ_VOLUMEID" ASC,

"OBJ_STATUS" ASC)

COLLECT DETAILED STATISTICS;

RUNSTATS ON TABLE RMADMIN.RMOBJECTS ON ALL COLUMNS WITH DISTRIBUTION ON

ALL