Installing the Tuxedo System

File and Database Management and Disk Space Allocation

The following sections describe BEA Tuxedo file and database management and provide guidelines for allocating disk space for a BEA Tuxedo application:

Introduction

For the most part, the following discussions apply to both Windows and UNIX systems except for the guidelines to repartition hard disk devices. On a Windows system, input/output (I/O) is buffered by default, but BEA Tuxedo sets a certain system-level flag to change the default. Thus, all I/O for BEA Tuxedo processes is unbuffered, meaning that you do not need to make any special disk-space arrangements on a Windows system.

How the BEA Tuxedo System Manages Files

The BEA Tuxedo system provides a facility called the Disk Management Interface (DMI), which manages logical files within a single disk device or set of devices. The DMI performs tasks such as storing binary configuration tables and the transaction log. You can use it to create, initialize, or destroy entries in the BEA Tuxedo filesystem. To access the DMI, use the tmadmin(1)administrative commands described in the BEA Tuxedo Command Reference.

There are two ways that the logical files managed by the DMI can be stored physically:

Stored on an operating-system (OS) filesystem
Stored on disk space, set aside for the BEA Tuxedo system, that is outside the control of all OS filesystems

BEA Tuxedo files reside on device special files in the designated space and are managed directly by the DMI disk management software. The DMI supports the notion of a BEA Tuxedo filesystem distinct from any OS filesystem.

Space outside the OS filesystem is usually referred to as raw disk space. Not only is I/O faster when done by system calls reading directly from and writing directly to device special files on raw disks, but a physical write() occurs right away. When using an OS filesystem, BEA Tuxedo cannot predict or control the precise moment at which a write() is done. When using raw disk space, however, BEA Tuxedo has accurate control of the write operation, which is particularly important for entries in the BEA Tuxedo transaction log. Also, when multiple users are accessing the system, being able to control the write operation is important for assuring database consistency.

Arranging for Raw Disk Space

If you decide to use raw disk space for your BEA Tuxedo application, and you are using a UNIX system, you may find that the hard disk devices on your system are fully allocated to filesystems such as / (root) and /usr. If that is the case, you must repartition your hard disk device in order to set aside some partitions for use as non-OS filesystems. For repartitioning instructions, refer to the system administration documentation for your platform.

How the BEA Tuxedo Filesystem Is Organized

A BEA Tuxedo filesystem has a Volume Table of Contents (VTOC), which lists the files residing on the devices named in the Universal Device List (UDL). The UDL contains information about the location of the physical storage space for BEA Tuxedo system tables.

In a BEA Tuxedo application, all system files might be stored together on the same raw disk slice or OS filesystem. While it is possible to use regular OS filesystem files for the configuration tables, we strongly recommend that you store the transaction log, TLOG, on a raw disk device. Because the TLOG seldom needs to be larger than 100 blocks (51200 bytes assuming 512-byte blocks), and because disk partitions are always substantially larger than 100 blocks, it may make sense to use the same device for both the configuration files and the TLOG.

The following sample listing shows a sample VTOC and UDL diagram for a bankapp (sample application) configuration on a single machine.

Listing C-1 VTOC and UDL Diagram

Output based on setting FSCONFIG=$TUXCONFIG, and invoking tmadmin:

No bulletin board exists. Entering boot mode.

> livtoc
Volume Table of Contents on /usr2/bank/tuxconfig:
0: VTOC: Device 0 Offset 0 Pages 7
1: UDL: Device 0 Offset 7 Pages 28
2: _RESOURCE_SECT:    Device 0 Offset  35 Pages 6
3: _MACHINES_SECT:    Device 0 Offset  41 Pages 40
4: _GROUPS_SECT:      Device 0 Offset 141 Pages 100
5: _SERVERS_SECT:     Device 0 Offset 241 Pages 150
6: _SERVICES_SECT:    Device 0 Offset 391 Pages 60
7: _ROUTING_SECT:     Device 0 Offset 451 Pages 100
8: _NETWORK_SECT:     Device 0 Offset 551 Pages 20
9: _MIBPERMS_SECT:    Device 0 Offset 571 Pages 2
10: _NETGROUPS_SECT:  Device 0 Offset 573 Pages 2
11: _INTERFACES_SECT: Device 0 Offset 575 Pages 10 

# If the TLOG is stored on the same device, there will be an
# entry something like:

12: TLOG:             Device 0 Offset 585 Pages 100

The BEA Tuxedo application administrator must make sure raw disk slices are available as needed on each node participating in an application. The following table lists the size of each element in the BEA Tuxedo filesystem.

Table C-1 Size of BEA Tuxedo System Tables

Entity	512-Byte Pages (Blocks)
`VTOC`	7
`TUXCONFIG`	550
`TLOG`	100 (default)
`UDL`	28
`TOTAL`	685

The amount of space required for the TUXCONFIG file must be larger if there are more entries in the configuration file, UBBCONFIG, than in the bankapp sample application. The administrator is encouraged to allocate additional space for dynamic reconfiguration and growth of the application. The default block size assumed by the crdl subcommand of tmadmin is 1000 blocks (512000 bytes assuming 512-byte blocks), which should be adequate for the initial installation.

Space for Queue Spaces

If your BEA Tuxedo application uses /Q for store-and-forward queue management, your queue space can be listed in the same UDL as the one used to store the TUXCONFIG file and the TLOG, and managed by the BEA Tuxedo VTOC.

Space for Application Servers

As you are calculating your space requirements for the BEA Tuxedo system, you should also consider the requirements of the servers that perform the work of the application. These requirements are specified by the application; they are unrelated to the requirements for the BEA Tuxedo system itself (unless otherwise specified).