Tivoli Storage Manager V6.1 Technical Guide

46 Tivoli Storage Manager V6.1 Technical Guide

and serialization to data in the database while utilizing capabilities that DB2 provides in

this area. Primarily, Tivoli Storage Manager implemented its DB2 calls specifying “WITH

UR,” which indicates “with uncommitted read.” The rational for this rule is that locking

semantics and deadlock detection are already in place.

Uncommitted Read (UR) allows an application to access uncommitted changes of other

transactions. The application also does not lock other applications out of the row that it is

reading, unless the other application attempts to drop or alter the table.

 The pre-Tivoli Storage Manager V6.1 table schema is predicated upon the application

level code owning and maintaining the relationships between rows in various tables as

shown in Figure 5-2 on page 49. The new server exploits various capabilities that DB2

offers for the following purposes:

– Eliminating duplication across tables:

There were many cases where data was replicated across many tables. This was done

because the proprietary database did not provide for multiple indices on the same

table, thus allowing for search optimizations.

– Changing the key specifications for some tables:

Tivoli Storage Manager’s key and primary key selections historically have been limited

by the fact that the only index/key available had to be unique and was governed by the

B+ tree structure of the underlying tables. The new server takes advantage of various

unique keys and primary keys to better suit optimization for DB2 and also to best meet

performance objectives.

 There are additional capabilities within DB2 that are now used to validate or ensure

integrity of the fields in the database and the tables themselves. A few of the DB2

capabilities used for this are views, triggers, stored procedures, and constraints. This

explanation is drastically simplified and does not even try to explain these capabilities.

For a complete understanding of these DB2 features, refer to the DB2 Information Center

at:

http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp

5.2.2 General DB2 configuration items

In this section we provide information about general DB2 configuration features.

Memory management

The primary memory usage item for the server has historically been the server buffer pool

specified by the BUFPOOLSIZE option. The buffer pool is the in-memory cache for the

database pages used for pre-Tivoli Storage Manager V6.1 database management

operations. With the transition to DB2, the buffer pool space shifts to the DB2 buffer pool

where it is used for DB2's own database management operations on the Tivoli Storage

Manager server’s behalf. There is also additional memory that DB2 will utilize for its own

operating and management. You can consider the DBMEMPERCENT option being the

replacement for the BUFPOOLSIZE option. However, it represents much more than the

historic buffer pool because it represents the amount of RAM that DB2 can use for everything,

such as the buffer pools (plural now) and the sort heap.

On UNIX systems, when you start the Tivoli Storage Manager server, the server attempts to

change the ulimit values to unlimited. In general, this helps to ensure optimal performance

and to assist in debugging. If you are a non-root user, when you start the server, attempts to

change the ulimits might fail. To ensure proper server operation if you are running as a

non-root user, make sure that you set the ulimits as high as possible, preferably to unlimited,

before starting the server.