Improves database performance by defragmenting and reorganizing database files. MUPIP REORG runs concurrently with other database activity, including updates. Competing activity generally increases the time required to perform a REORG, as well as that of the competing operations.
The format of the REORG command is:
REO[RG] [ -D[OWNGRADE] -E[XCLUDE]=global-name-list -FI[LL_FACTOR]=integer -I[NDEX_FILL_FACTOR]=integer -REG[ION] -R[ESUME] -SAFEJNL -S[ELECT]=global-name-list -STA[RTBLK]=hexa -STO[PBLK]=hexa -UP[GRADE]] -US[ER_DEFINED_REORG]=reorg_list ]
![]() | |
While REORG optimizes the GDS structure of database files, it does not handle native file system file fragmentation. In most cases, fragmentation at the native file system level is more likely than fragmentation at the GDS structure level. Therefore, FIS recommends users create files with appropriate allocations and extensions, on disks with large amounts of contiguous free space. Use native utilities and MUPIP utilities (depending on operational procedures) to eliminate file fragmentation when database files have been extended more than a dozen times. |
Using REORG concurrently with normal database access affects the performance of normal operation. To reduce this impact, lower the priority of the process performing the REORG.
MUPIP REORG does not change the logical contents of the database, and can run on either the originating instance or replicating instance of an LMS application. In such cases, resuming REORGs in process should be part of the batch restart. See "GT.M Database Replication" chapter for more information about running REORG on a dual site application.
If you run MUPIP STOP for an ongoing MUPIP REORG process, it may leave the database blocks in an inconsistent state. In this situation, GT.M converts the ongoing KILLs flag to abandoned KILLs flag. If a subsequent MUPIP REORG encounters these abandoned KILLs flags, it gives a message and then starts its REORG actions.
<CTRL-C> terminates REORG. A REORG terminated abnormally by operator action or error is incomplete but does not adversely affect the database structure, unless terminated with a kill -9.
Assume two scenarios of putting values of ^x(1) to ^x(10000). In the first scenarios, fill values in a sequential manner. In the second scenario, enter values for odd subscripts and then enter values for the even subscripts.
Scenario 1:
At the GT.M prompt, execute the following command sequence:
GTM>for i=1:1:10000 set ^x(i)=$justify(i,200)
Then, execute the following MUPIP INTEG command.
$ mupip integ -region "*"
This command produces an output like the following:
Integ of region DEFAULT No errors detected by integ. Type Blocks Records % Used Adjacent Directory 2 2 2.490 NA Index 29 2528 95.999 1 Data 2500 10000 82.811 2499 Free 69 NA NA NA Total 2600 12530 NA 2500
Note the high density (percent used) for index and data blocks from the report.
Scenario 2:
At the GT.M prompt, execute the following command sequence:
GTM>for i=1:2:10000 s ^x(i)=$justify(i,200) GTM>for i=2:2:10000 set ^x(i)=$justify(i,200)
Then, execute the following command:
$ mupip integ -region "*"
This command produces an output like the following:
Integ of region DEFAULT No errors detected by integ. Type Blocks Records % Used Adjacent Directory 2 2 2.490 NA Index 153 3902 29.211 57 Data 3750 10000 55.856 1250 Free 95 NA NA NA Total 4000 13904 NA 1307
Note that there are more and less dense index and data blocks used than in scenario 1. MUPIP REORG addresses such issues and makes the database (depending on the FILL_FACTOR) more compact.
The optional qualifiers for MUPIP REORG are: