The following sections describe the files used by TIBCO Object Service Broker. For better performance, each TIBCO Object Service Broker file should be located on a different device. This is very important for high-use files such as the MetaStor, the redolog, and the contingency log.
TIBCO Object Service Broker for Open Systems Installing and Operating for more information on the definition, placement, and sizing of these files.
The Pagestore is a collection of files used by TIBCO Object Service Broker for storing data in tables. In simple terms, this is the database. The Pagestore stores data using the TDS (Table Data Store) method. TDS tables are stored in a B+ tree structure.
The Pagestore is divided into partitions known as segments. Each segment consists of a number of files containing data, as shown in the following illustration.
The base segment (segment 0) contains the MetaStor, the central repository for all metadata: definitions, characteristics, access paths, and storage locations of all data and programs in TIBCO Object Service Broker. Segment 0 is the most heavily used segment. It contains three files by default (PAGE1, PAGE2, and PAGE3). These files can be expanded as required.
The Pagestore can consist of up to 256 segments. Each segment can consist of up to 128 files. A file can hold 500,000 x 4 KB pages. Given these parameters, the potential capacity of the Pagestore is approximately 256 GB per segment. When you initially set up your Pagestore, leave room for expansion in each page file. For example, if you require a 6 GB segment 1, define six page files with 250,000 4 KB pages rather than three page files with 500,000 x 4 KB pages.
Each segment of the Pagestore contains a number of page files. If possible, each file should be stored in a different directory within a different SCSI controller than the one containing the redolog and journals. This allows TIBCO Object Service Broker to minimize I/O contention in the segment. When a new 4-KB page is allocated to a segment, TIBCO Object Service Broker uses the files contained in the segment in sequence. It places each new page on the next file in turn so that the pages are evenly distributed across the files.
The redolog contains records of all update operations recently performed, or about to be performed, against the database. TIBCO Object Service Broker uses the redolog to reconstruct the committed updates made between checkpoints and maintain database integrity.
In-doubt transactions are those that involve an external database server or a peer TIBCO Object Service Broker and that could not be completed. They are kept in the contingency log until the update is confirmed by the other systems, then written to the redolog.
In the event of a power failure or external system failure, TIBCO Object Service Broker uses the contingency log to ensure consistency of updates across external database, peer, and local TIBCO Object Service Broker systems.
When the system performs a checkpoint, all modified data pages in the resident page manager buffers are copied to the cache portion of the journal, therefore assuring their recoverability in the event of a failure. The resident page manager is the internal Data Object Broker component that manages local memory containing images of all Pagestore pages currently in use.
The system switches between journals when one reaches capacity and the contents of the full journal are saved. The procedure to save the full journal is called a
spin. Refer to
Chapter 5, Understanding Journal Processing for more information. The journals can be placed on the same SCSI controller as the redolog, but they must be in a different directory.
TIBCO Object Service Broker uses the dbdef file during initialization. The dbdef file centralizes most control information. For more information on the TIBCO Object Service Broker Pagestore, refer to
Pagestore.