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
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
5.2.2 General DB2 configuration items
In this section we provide information about general DB2 configuration features.
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.