Performance Tuning for Content Manager

174 Performance Tuning for Content Manager

In these examples, <tsname> is the table space name.

Spreading the table spaces across multiple containers can also be achieved by

converting the SMS table spaces to DMS. This procedure is discussed in 8.4,

“SMS to DMS table space conversion” on page 188.

Change log file location

Even if the rest of the database components are not going to be spread across

multiple disks, the database log files should be put on a different disk. The log

files should be on a physical disk that does not have high I/O. This allows for

efficient logging activity with a minimum of overhead such as waiting for I/O. To

change the log file location, use the following command:

db2 update db cfg for <database name> using NEWLOGPATH = <new log path>

In this example, <new log path> is an existing path on another disk.

Our recommendation

Installing the databases, table spaces, and log files on different disks improves

both performance and scalability by maximizing I/O concurrency. As soon as

possible, try to adjust these components according to your system availability

and capacity. Use as many disks as possible. Invest in multiple disks — it pays

performance dividends. Divide your disks using the following rules:

 Separate and spread table spaces across multiple physical disks.

 Separate log files from the databases and put them on separate disks.

Separating the instances makes it possible to tune the Content Manager

databases independently. This provides more flexible tuning by allowing, as an

example, the Resource Manager database instance to be stopped and started

without affecting the Library Server. This topic is discussed in 8.2.3, “Create

separate instances during installation” on page 176.

8.2.2 Customize CM databases deployment at install through DDL

In the previous section, we showed how to spread database components to

different physical disks using DB2 commands. An alternative way is to change

the database installation scripts (the DDL files) at installation time. Content

Manager gives you the flexibility to change the DDL files to customize your

Library Server or Resource Manager database designs at install time. An

example of the changes you can make include assigning multiple physical disks

to a table space container.

Chapter 8. Tuning DB2 for Content Manager 175

Default values

The default installation script installs all databases onto the same disk and file

system.

How to change

1. After Content Manager installation, drop the Library Server database

(icmnlsdb) or the Resource Manager database (rmdb), or both, that were

created during the installation process:

db2 drop db icmnlsdb

db2 drop db rmdb

2. Back up the DDL files that are located in the <icmroot>\config directory. The

primary file names are:

icmlsdb2def.ddl Library Server database, buffer pool, and table space

definitions

icmplsct.ddl Library Server table definitions

icmplsci.ddl Library Server index definitions

icmrmcrdb.ddl Resource manager server database, buffer pool, and

table space definitions

icmrmcrtab.ddl Resource manager server table and index definitions

cmbadm81.db2 Library Server federated administration table

definitions

icmpwfcr.ddl Library Server federated advanced workflow table

definitions

icmjcr.ddl Library Server JCR table definitions (reserved for

future use)

icmjcrup.ddl Library Server JCR table definitions (reserved for

future use)

3. Edit the DDL files and reorganize the physical design as you planned.

4. After all DDL files are changed, re-create the databases by running the

Create Library Server Database or Create Resource Manager Database

utilities (or both). These utilities use the updated DDL files to create the new

databases.

Our recommendation

This is an advanced DB2 task. You need to be very familiar with the DDL, table

space, and container concepts in a DB2 environment. This task should be

performed by an experienced DB2 database administrator (DBA) and Content

Manager system administrator.