The following /SEGMENT qualifiers can be used with the ADD, CHANGE, or TEMPLATE commands.
/F[ILE_NAME]=file-spec Applies to BG MM
Specifies the file for a segment.
GT.M allows full file-specifications and logical names. Note that if the file specification is a search list, the first file in the list is used and all others are ignored. GT.M allows the use of logical names in the filename.
The maximum file name length is 255 characters.
By default, GDE uses a file-name of MUMPS and a .DAT file extension.
/AC[CESS_METHOD]=code Applies to: BG MM
Specifies the access method GT.M uses to store and retrieve data from the global database file.
The two methods are Buffered Global (BG) and Mapped Memory (MM).
GDE maintains a separate set of segment qualifier values for each ACCESS_METHOD. When GDE modifies the ACCESS_METHOD, it activates the appropriate set of TEMPLATEs and sets all unspecified qualifiers to the template defaults for the new ACCESS_METHOD.
By default, GDE uses an access method of BG.
|
Database Access Methods |
||
|
METHOD |
ADVANTAGES |
DISADVANTAGES |
|
BG |
Fast for any size region. |
- |
| - |
Can support Backward Re covery of journaling. |
- |
| - |
Can extend automatically. |
- |
|
MM |
Very fast for small regions, especially with /DEFER, or for read-only data. |
For large regions, no performance advantage, and long image rundown |
| - | - |
Cannot support Backward Recovery of journaling. |
| - | - |
Must be extended by MUPIP EXTEND when the database is not in use. |
/BL[OCK_SIZE]=size Applies to: BG MM
Specifies the size, in bytes, of each database block on disk. The BLOCK_SIZE must be a multiple of 512 (the RMS BLOCK_SIZE). If the BLOCK_SIZE is not a multiple of 512, GDE rounds off the BLOCK_SIZE to the next highest multiple of 512 and issues a warning message.
If the specified BLOCK_SIZE is less than the minimum, GDE uses the minimum BLOCK_SIZE. If the specified BLOCK_SIZE is greater than the maximum, GDE issues an error message.
A BLOCK_SIZE that is equal to the page size used by your UNIX implementation serves well for most applications, and is a good starting point.
You should determine the block sizes for your application through performance timing and benchmarking. In general, larger block sizes are more efficient from the perspective of the input/output subsystem. However, larger block sizes use more system resources (shared memory) and may increase collision and retry rates for transaction processing.
GDE does not allow you to change the block size to an arbitrary number. It always rounds the block size to the next higher multiple of 512, because the database block size must always be a multiple of 512.
The minimum BLOCK_SIZE is 512 bytes.
The maximum BLOCK_SIZE is 65,024 bytes.
By default, GDE uses a BLOCK_SIZE of 1024 bytes for BG and MM files.
By default, GDE uses a BLOCK_SIZE of 1024 bytes.
/AL[LOCATION]=blocks Applies to: BG MM
Specifies the number of blocks GT.M allocates to a disk file when MUPIP creates the file. For GDS files, the number of bytes allocated is the size of the database file header plus the ALLOCATION size times the BLOCK_SIZE.
When you change the ALLOCATION and do not also specify EXTENSION, the EXTENSION automatically changes to equal the ALLOCATION.
The minimum ALLOCATION is 10 blocks.
The maximum ALLOCATION is 16777216 blocks.
By default, GDE uses an ALLOCATION of 100 blocks.
The default ALLOCATION was chosen for initial development and experimentation with GT.M. Because file fragmentation impairs performance, make the initial allocation for production files and large projects large enough to hold the anticipated contents of the file for a length of time consistent with your RMS file reorganization schedule.
/E[XTENSION_COUNT]=blocks Applies to: BG MM
Specifies the number of extra GDS blocks of disk space by which the file should extend. The extend amount is interpreted as the number of usable GDS blocks to create with the extension. To calculate the number of host operating system blocks added with each extension, multiply the number of GDS blocks added by (GDS BLOCK_SIZE/host BLOCK_SIZE); add one local bitmap block for each 512 blocks added in each extension to the amount from step 1. If the extension is not a multiple of 512, remember to roundup when figuring the number of bitmap blocks.
BG files may extend automatically when the file is full. A zero extension size prevents a BG file from automatically extending. GDS files may be extended with MUPIP EXTEND, even when there are other processes accessing the database.
MM files must be extended with MUPIP EXTEND when there is no process accessing the database.
When a MUPIP EXTEND command does not include a /BLOCKS= qualifier, EXTEND uses the extension size in the database header.
The extension amount may be changed with the MUPIP SET command. To force explicit expansion for BG files with MUPIP EXTEND, set /EXTENSION_COUNT to zero.
The extension amount may be changed with the MUPIP SET command.
The minimum EXTENSION is zero blocks.
The maximum EXTENSION is 65,535 blocks.
By default, GDE uses an EXTENSION of 100 blocks.
Like allocation, the default extension amount was chosen for initial development and experimentation with GT.M projects. Use larger extensions for larger files. Because multiple file extensions adversely affect performance, set up extensions appropriate to the file allocation.
|
Note |
|---|---|
|
Database and journal files that have a large number of extensions may require unexpectedly large values of the BYTLM quota. Refer to the "Installing GT.M" chapter for more information. |
/G[LOBAL_BUFFER_COUNT]=size Applies to: BG
Specifies the number of global buffers for a file. Global buffers reside in shared memory and are part of the database caching mechanisms. Global buffers do not apply to MM databases.
Choose the settings for this qualifier carefully. Small numbers of global buffers tend to throttle database performance. However, if your system has limited memory and the database file traffic is not heavy enough to hold the cache in memory, increasing GLOBAL_BUFFER_COUNT may trigger OpenVMS paging.
If database global buffers are paged out, it may result in poor performance. Therefore, do not increase this factor to a large value without careful observation.
The proper number of GLOBAL_BUFFERs depends on the application and the amount of primary memory available on the system. Most production databases exhibit a direct relationship between the number of GLOBAL_BUFFERs and performance. However, the relationship is not linear, but asymptotic, so that increases past some point have progressively less benefit. This point of diminishing returns depends on the application. For most applications, Fidelity Information Services expects the optimum number of GLOBAL_BUFFERs to be between 1024 and 4096.
The maximum number of database blocks that can be modified by a transaction is half the number of global buffers. In practice, few applications are expected to have such large transactions that can degrade performance.
Generally, you should increase the number of GLOBAL_BUFFERs for production GDS databases. This is because GT.M uses the shared memory database cache associated with each GDS file for the majority of caching.
The minimum for BG is 64 blocks.
Values under 250 are not recommended, even for development.
The maximum for BG is normally 65,536 blocks, but may vary depending on your platform.
By default, GDE uses a GLOBAL_BUFFER_COUNT that is appropriate for the typical size of the platform. The most common value is 1024 blocks. Increases above the default for your platform may require modifications to your UNIX kernel configuration.
|
Note |
|---|---|
|
If global buffers are "paged out," improvements in system performance resulting from more global buffers will be more than offset by the dramatic slowdown that results from globals buffers that are "paged out." |
/NO]D[EFER] Applies to: MM
Instructs GT.M whether or not to store updates on the disk immediately.
DEFER has a significant performance benefit for database files that are heavily updated. However, DEFER should only be used for segments files, (such as those containing temporary storage for reports) that can be recreated if the system crashes.
By default, GDE makes MM database files /DEFER.
/L[OCK_SPACE]=pages Applies to: BG MM
Specifies the number of pages of space to use for the lock database stored with this segment. If GT.M runs out of space to store locks, LOCKS become somewhat less efficient. If the process accumulates locks and does not release them, it will deadlock at a point that is a function of the LOCK_SPACE. The default amount is adequate for most M applications.
The minimum LOCK_SPACE is 10 pages.
The maximum LOCK_SPACE is 1,000 pages.
By default, GDE uses a LOCK_SPACE of 40 pages.
/R[ESERVED_BYTES]=size Applies to: BG MM
Specifies the size to be reserved in each database block. RESERVED_BYTES is generally used to reserve room for compatibility with other implementations of M or to observe communications protocol restrictions. RESERVED_BYTES may also be used as a user-managed fill factor.
The minimum RESERVED_BYTES is zero bytes.
The maximum Reserved_Bytes is the block size minus the size of the block header (which is 7 or 8 depending on your platform) minus the maximum record size.
By default, GDE uses a RESERVED_BYTES size of zero bytes.