GT.M Database Migration

There are a number of changes to the database file header, and these are reflected in the output of the dse dump -fileheader command, as described below:

The layout of the database file header has also changed, but this is not of any consequence to users since the only way to interact with the database file header is via the dse change -fileheader and mupip set commands.

Every V5 format database and index block requires a 64-bit BTN. Furthermore, since a database can have both V4 and V5 format blocks within it, there is a need to distinguish between V4 format blocks and V5 format blocks.

The V4 block header is 8 bytes on UNIX, 7 bytes on OpenVMS, and is laid out as follows:

In V5, the block header is increased to 16 bytes, and is laid out as follows:

If the value in the first two bytes is 0 through 6, GT.M V5 knows that the block is a V5 block and the field is a block version number; if it is 7 or greater, GT.M V5 knows that it is a V4 block and the field is the number of bytes currently in use in the block. This feature - a true hack - permits a GT.M database to contain both V4 format blocks as well as V5 format blocks, and facilitates the incremental upgrading of V4 databases to V5 with minimal unavailability of applications.

One result of the fact that GT.M V5 has a 16-byte block header, whereas GT.M V4 has a 7 or 8 byte block header is that it is possible to have a record in a V4 database that will not fit in a V5 database with the same block size. The largest record that can fit in a V4 GT.M database on x86 GNU/Linux with a 4KB block size is 4088 bytes, whereas the largest record that can fit in a V5 GT.M database on the same platform is 4080 bytes. If there are any records whose size exceeds blocksize-16, then a new V5 database will need to be created with a larger block size. ^[2]

A GT.M application that is configured for logical dual site operation can be upgraded from V4 to V5 while maintaining continuity of application availability. Please follow the procedures in the Database Replication chapter of the GT.M Administration and Operations Guide. Note that V4 journal files and mupip backup -bytestream files are not compatible with V5.

The traditional approach to upgrading a database file is to extract it on the lower GT.M version with a mupip extract and to load it on the higher GT.M version with mupip load. Both BINARY format (mupip extract -format=binary) as well as the default ZWR format will work; however, the former is likely to be faster.

Since the V4 database files are not modified with this approach, they can simply be archived, and a separate backup is not needed. The mupip extract files can also serve as an alternative backup.

The benefits of a traditional approach are its simplicity and the fact that a database created with GT.M V5.0-000 can grow to a maximum size of 134,217,728 (128M) blocks, whereas a database created with a GT.M V4 release and upgraded to V5 retains a maximum size of 67,108,864 (64M) blocks.

Since a database extract and reload can take hours for large database files, GT.M V5.0-000 provides a method to upgrade database files that, at least in the typical case, requires that the application be brought down for only seconds to minutes. The basic approach to the in-place upgrade is the ability of GT.M V5.0-000 to read database blocks in V4 or V5 format. Whenever a block is updated, it will be written in V5 format. Thus, over time, the blocks are converted from V4 format to V5 format. Conceptually, this is a three-step process:

Test and Certify

The critical requirement for being able to upgrade a database from V4 format to V5 format, whether in place or traditional, is that there must be no blocks whose records occupy more than blocksize-16 bytes. This is because database blocks in the global buffer cache are always in V5 format - when GT.M V5 reads a V4 format block into the global buffer cache, it converts it to V5 format. When writing out blocks, they can be written out in V5 format or converted to V4 format. If a database has no blocks with records occupying more than blocksize-16 bytes, upgrading to V5 is a snap. If it does have such blocks, they will need to be dealt with.

There are two types of blocks whose records occupy more than blocksize-16 bytes - those with one record and those with more than one record. The latter can be made suitable for upgrading to V5 format blocks simply by splitting the block, but the former cannot: if a database contains even one block with one record which is larger than blocksize-16 bytes, that database cannot be upgraded in place from V4 to V5. Such a database file will require a new database to be created in V5 with a larger block size, following which the data must be extracted in V4 and loaded in V5.

The dbcertify program is used to scan a V4 database and identify blocks with more than blocksize-16 bytes occupied. The testing and certification process has several steps:

1. Increase the Reserved Bytes parameter in the database file header by 8 (UNIX/Linux) or 9 (OpenVMS). Note that the Reserved Bytes field is typically zero, so the new values will typically be 8 (UNIX) or 9 (OpenVMS). However, your database files may not be typical, so always check the value of this field with dse dump -fileheader and increment the value accordingly. This will ensure that no new records are created with a record size greater than blocksize-16, even though existing records will remain unaltered. You can run a mupip reorg on the database after setting Reserved Bytes to the new value; this will reduce the number of blocks that dbcertify will need to deal with in the next step.

2. Verify that the Maximum Record Size parameter is less than or equal to blocksize-16, which it must be in V5. If it is not, you must determine whether your application requires it to be greater than blocksize-16, in which case a database upgrade is not possible: you will need to create a new database in V5 with a larger block size, into which you can load data extracted from the V4 database. If the application permits the Maximum Record Size parameter to be reduced to be less than or equal to blocksize-16, then reduce it accordingly. Once the Maximum Record Size parameter is less than or equal to blocksize-16, dbcertify can be used.

3. The dbcertify program has two phases, a scan phase and a certify phase. Fidelity strongly recommends a backup before the certify phase, refer to the Tip in the Journal Files and Backups section for a suggestion on how to obtain a fast backup.

   1. The scan phase runs concurrently with normal operation of GT.M V4. It makes no modifications to the database, but instead produces a report of blocks that are too large to be used by GT.M V5.

   2. The certify phase requires stand-alone access to the database. An M program is provided with GT.M V5.0-000, V5CBSU, which can run concurrently with normal operation of GT.M V4 applications, and which can take the output of the dbcertify scan phase and help reduce the amount of work the certify phase must perform. This reduces the amount of time that dbcertify requires stand-alone access to the database.

Once the certify phase of dbcertify completes, mupip upgrade can be used to upgrade the database file header.

dbcertify assumes that there is no structural damage to the database. Therefore, Fidelity strongly recommends that a mupip integ (without the -fast switch) be performed on the database or a backup copy of the database as soon as possible prior to running dbcertify, and not to start dbcertify if there are any unusual events or unusual messages in the operator log after the mupip integ operation (or the backup operation that created the backup on which mupip integ was run).

	The dbcertify certify and mupip upgrade steps are not journaled and are not interruptible. In the event of a hardware or software malfunction in the dbcertify or mupip upgrade, the V4 database will need to be restored from a backup.

	Although dbcertify and V5CBSU are written to have minimal impact on running applications, the fact that they perform IO means that the impact will not be zero. Whether or not the impact is noticeable depends on the extent to which IO is limiting throughput on your system.

Upgrade Database File Header

Once the certify phase of dbcertify has completed, the database file header can be upgraded from V4 to V5 with mupip upgrade, an operation that should take a fraction of a second on even the largest databases, since it only affects the file header. Once the database file header has been upgraded, the database can be used by GT.M V5 processes.

A GT.M V5 database has a switch in the file header that specifies whether blocks that are updated are written to the database in V4 format or V5 format. Mupip upgrade will set the switch to cause GT.M V5 processes to write updated blocks in V5 format. To cause GT.M V5 processes to write updated blocks in V4 format, an option which preserves the ability to revert to GT.M V4 on short notice, use a subsequent mupip set -version=v4 command.

	Using GT.M V4 blocks in GT.M V5 will incur a small performance penalty, which may or may not be noticeable depending on what is limiting the throughput of your system.

	Mupip upgrade will reduce the Reserved Bytes field in the database file header by 8 bytes (UNIX) or 9 bytes (OpenVMS).

To upgrade a database file used with the MM access method (supported on OpenVMS only), it must either have its access mode changed to Buffered Global (BG) to use the upgrade method that minimizes access time, or the traditional upgrade method should be used.

	Changing the access method from MM to BG requires stand-alone access and is accomplished by the mupip set command.

It is feasible to revert from GT.M V5 to V4. The database must first be downgraded to V4 format before it can be accessed by a GT.M V4 release. This is accomplished with the steps below, assuming that the CTN of the database is less than 4,294,967,295 (0xFFFFFFFF). If the CTN exceeds this number, a mupip integ -tn_reset must first be performed, or the database must be extracted using V5 mupip extract (with the default ZWR format) and loaded with V4 mupip load into a database created with V4 mupip create.

dbcertify is distributed with GT.M V5.0-000. Since it is intended to run against V4 databases, concurrently with GT.M V4 processes, it is not installed by the normal GT.M installation script. Instead:

Syntax is:

dbcertify scan [-outfile=fn] [-report_only] <db-region-name> dbcertify certify <scan-phase-outfile>

The DBCERTIFY utility certifies a V4 database as being ready for upgrade to V5. This is a 2-phase process, consisting of a scan phase and a certify phase.

dbcertify scan [-o[utfile]=filename] [-r[eport_only]] region_name

The scan phase identifies the blocks that need to be split as well as records and blocks with single records that are too long to be split. The scan phase can run concurrently with normal application operation of GT.M V4. The region must map to a V4 format database file (V5.0-FT01/V5.0-FT02 databases are V4 format databases).

Normally, dbcertify scan will produce an output file that will be used by dbcertify certify, and optionally by the program V5CBSU. The use of the optional -report_only qualifier will suppress the production of the output file. dbcertify scan can be run as often as needed.

Scan phase results:

	The V5CBSU utility can optionally be run after the scan phase and before the certify phases in order to reduce the standalone run time of the certify phase.

dbcertify certify must be run in standalone mode.

Certify phase results:

This command requires that $gtm_dist on UNIX or GTM$DIST on OpenVMS be set to the directory of the current GT.M V4 installation.

The dbcertify program along with the V5CBSU utility should be run on the V4 system.

For OpenVMS, gtmdcbuild.com created during install will build v5cbsu.exe if it wasn't done during the install and gtmdcdefine.com also created during the install will define the symbols DBCERTIFY and V5CBSU. The executable for V5CBSU must be built before the existing databases can be prepared for upgrade so as to be used with the new GT.M version.

V5CBSU is a normal M routine for processing the output of dbcertify, and can be run with any V4 GT.M version. It is packaged and distributed with DBCERTIFY.

V5CBSU optionally runs between the SCAN and CERTIFY phases of DBCERTIFY and reduces the work dbcertify -certify must perform in standalone mode. It runs with the GT.M V4 applications and splits level 0 global variable tree blocks as identified in the report from the scan phase of DBCERTIF.

V5CBSU splits as many blocks as it is able to and shows statistics on how successful it was when it completes. It rewrites the scan phase output file to exclude the blocks that successfully processed.

V5CBSU's input is the output file from dbcertify -scan.

The database associated with the file must still exist and be accessible to the utility.

Syntax on UNIX:

$gtm_dist/mumps -run ^v5cbsu scan-phase-output-file-name-path

Syntax on OpenVMS:

Note that V5CBSU.m is packaged as part of the DBCERTIFY but in order to use it in OpenVMS you need an executable image. When the DBCERTIFY kit (that is, GTDCnnnnn.A) is installed, it creates two command procedure files, GTMDCBUILD.COM and GTMDCDEFINE.COM. During a standard install, V5CBSU.EXE will be created using GTMDCBUILD.COM. Setup the DCL command: V5CBSU :== "$..[..]V5CBSU.EXE" where ..[..] represents the absolute path containing the executable. GTMDCDEFINE.COM creates DCL symbols for V5CBSU and DBCERTIFY.

	For GT.M V5.3-003 through V5.4-000A, V5CBSU.m uses the utility routines %DH and %EXP whose M routines are _DH.m and _EXP.m Use MUMPS (V4 GT.M) to compile V5CBSU.m, _DH.m and _EXP.m, then use LINK V5CBSU.OBJ,_DH.OBJ,_EXP.obj to create a V5CBSU.EXE executable.

V5CBSU scan-phase-output-file-name

	If MUPIP REORG has been run with Reserved Bytes set to at least 8 for UNIX or 9 for OpenVMS, before a dbcertify -scan, the V5CBSU utility has little or nothing to do.

V5CBSU operates as follows:

The dse dump command displays the database blocks, records, or file headers.

-B[LOCK]=block_number

Displays the block transaction number as a 64-bit value and outputs the version number of the block format in the block header.

Example: DSE> dump -block=2 V4 format output: Block 2 Size 13 Level 0 TN 1 Rec:1 Blk 2 Off 8 Size B Cmpc 0 Ptr 4 Key ^a 8 : | B 0 0 0 61 0 0 4 0 0 0 | | . . . . a . . . . . . | V5 format output: Block 2 Size 1B Level 0 TN 1 V5 Rec:1 Blk 2 Off 10 Size B Cmpc 0 Ptr 4 Key ^a 10 : | B 0 0 0 61 0 0 4 0 0 0 | | . . . . a . . . . . . |

-F[ILEHEADER]

Outputs new fields that are associated with V5, as noted below. Existing transaction number fields that were formerly 32 bits and which are 64 bits in V5, are now displayed as 64-bit fields. Note that the sequence numbers used in replication have always been 64-bit fields whose length is unchanged in V5.

	V5.0-000 adds fields to the file header in conjunction with the use of helper processes on the secondary. This adds the qualifier -updproc to the dump -fileheader command to dump those additional fields. Refer to the GT.M Update Helper Processes Technical Bulletin for details.

Example: DSE> dump -fileheader V4 format output: File /gtm/v44004/mumps.dat Region DEFAULT Date/Time 06 MAY 2005 14:33:42 [$H = 60026,52422] Access method BG Global Buffers 1024 Reserved Bytes 0 Block size (in bytes) 1024 Maximum record size 256 Starting VBN 49 Maximum key size 64 Total blocks 0x00000065 Null subscripts FALSE Free blocks 0x00000062 Last Record Backup 0x00000001 Extension Count 100 Last Database Bckup 0x00000001 Number of local maps 1 Last Bytestream Bckup 0x00000001 Lock space 0x00000028 In critical section 0x00000000 Timers pending 0 Cache freeze id 0x00000000 Flush timer 00:00:01:00 Freeze match 0x00000000 Flush trigger 960 Current transaction 0x00000001 No. of writes/flush 7 Create in progress FALSE Modified cache blocks 0 Reference count 1 Wait Disk 0 Journal State DISABLED Mutex Hard Spin Count 128 Mutex Sleep Spin Count 128 Mutex Spin Sleep Time 2048 KILLs in progress 0 Replication State OFF Region Seqno 0x0000000000000001 Resync Seqno 0x0000000000000001 Resync transaction 0x00000001

V5 format output: File /gtm/v50000/mumps.dat Region DEFAULT Date/Time 06 MAY 2005 14:33:47 [$H = 60026,52427] Access method BG Global Buffers 1024 Reserved Bytes 0 Block size (in bytes) 1024 Maximum record size 256 Starting VBN 129 Maximum key size 64 Total blocks 0x00000065 Null subscripts NEVER Free blocks 0x00000062 Standard Null Collation FALSE Free space 0x00006000 Last Record Backup 0x0000000000000001 Extension Count 100 Last Database Backup 0x0000000000000001 Number of local maps 1 Last Bytestream Backup 0x0000000000000001 Lock space 0x00000028 In critical section 0x00000000 Timers pending 0 Cache freeze id 0x00000000 Flush timer 00:00:01:00 Freeze match 0x00000000 Flush trigger 960 Current transaction 0x0000000000000001 No. of writes/flush 7 Maximum TN 0xFFFFFFFFDFFFFFFF Certified for Upgrade to V5 Maximum TN Warn 0xFFFFFFFF5FFFFFFF Desired DB Format V5 Master Bitmap Size 64 Blocks to Upgrade 0x00000000 Create in progress FALSE Modified cache blocks 0 Reference count 1 Wait Disk 0 Journal State DISABLED Mutex Hard Spin Count 128 Mutex Sleep Spin Count 128 Mutex Spin Sleep Time 2048 KILLs in progress 0 Replication State OFF Region Seqno 0x0000000000000001 Resync Seqno 0x0000000000000001 Resync trans 0x0000000000000001

-BL[OCK]=block_number -TN[=transaction_number]

The block command with the TN qualifier changes the transaction number for the given block. This takes in a 64-bit (16 hex digit) value, when not running in compatibility mode. In compatibility mode, the value is limited to 32-bit (8 hex digit) value. When a change command does not include a -TN=, DSE sets the transaction number to the current transaction number. Please note that manipulation of the block transaction number will affect whether mupip backup -bytestream backs up the block. The -TN qualifier is incompatible with all qualifiers except -block, -bsiz, and -level.

Example: V4 format: DSE> change -block=3 -tn=FFFFFFFF V5 format: DSE> change -block=3 -tn=FFFFFFFFFFFFFFFF

-FI[LEHEADER]

The dse change -fileheader command enables modification of specific fields in the file header. The new qualifiers are: blks_to_upgrade, cert_db_ver, db_write_fmt, mbm_size, max_tn, and warn_max_tn allow modifications to the new file header fields, the master bitmap size, blocks to upgrade, the desired db format, certified for upgrade to, the maximum tn, and the maximum tn warn.

	Modify these fields only when so instructed by GT.M Support.

The following qualifiers allow 64-bit (16 hex digit) values when not running in compatibility mode. In compatibility mode, the values are limited to 32-bit.

-CU[RRENT_TN]=transaction_number

Changes the current transaction number for the current region. This qualifier has implications for mupip backup -bytestream. Raising the -current_tn effectively can correct block transaction number too large errors.

-B[YTESTREAM]=transaction_number

Changes the transaction number in the file header of the last -bytestream backup to the value specified. Use this qualifier only in conjunction with the -fileheader qualifier. For compatibility issues with prior versions, this can still be specified as -b_incremental.

-B_R[ECORD]=transaction_number

Changes the transaction number in the file header of the last -record backup to the value specified. Use this qualifier only in conjunction with the -fileheader qualifier.

-D[ATABASE]=transaction_number

Changes the transaction number in the file header of the last -database backup to the value specified. Use this qualifier only in conjunction with the -fileheader qualifier. For compatibility issues with prior versions, this can still be specified as -b_comprehensive.

Displays a number in both hexadecimal and decimal formats, use it to translate a hexadecimal number to decimal and vice versa. The -decimal and -hexadecimal qualifiers specify the input base for the number. The -number qualifier is a required value. Dse eval now supports 64-bit values for all these qualifiers.

V4 format: DSE> eval -h -n=FFEEFFDD Hex: FFEEFFDD Dec: 4293853149 DSE> eval -d -n=4293853149 Hex: FFEEFFDD Dec: 4293853149 V5 format: DSE> eval -h -n=FFFFEEEEDDDDFFFF Hex: FFFFEEEEDDDDFFFF Dec: 18446725308424781823 DSE> eval -d -n=18446725308424781823 Hex: FFFFEEEEDDDDFFFF Dec: 18446725308424781823

Mupip backup now supports 64-bit transaction number qualifiers.

-T[RANSACTION]=transaction-number

Specifies a starting transaction, which causes backup -bytestream to copy all blocks that have been changed by the specified transaction and all subsequent transactions. Transaction numbers are now 16 digit hexadecimal numbers.

	GT.M V5 mupip backup will not work with a V4 database If doing a bytestream backup over a TCP connection, the receiving and sending systems must both be running the same version of GT.M with the same database file header version.

Mupip restore integrates one or more backup -bytestream files into a corresponding database. The transaction number in the first bytestream backup file must be one more than the current transaction number of the database, and the first transaction number of each file in the sequence of files must be one more than that in its predecessor. Otherwise, mupip restore will terminate with an error and refuse to perform the restore. mupip restore now supports 64-bit transaction number qualifiers, when running with a database with a V5 header.

	Mupip restore cannot make use of a V4 format backup (bytestream or database).

Files created with V5.0-000 mupip create now support 128M GDS data and index blocks instead of the 64M in V4, resulting from the larger master bitmap.

	V4 databases upgraded to V5 retain a maximum database file-size limit of 64M blocks

Mupip integ keeps track of the number of blocks that do not have the current block version during a non-fast integ (default or full) and matches this value against the blocks to upgrade counter in the file-header. It issues an error if the values are unmatched and corrects the count in the file header if there are no other integrity errors.

The -FO[RMAT]=BINARY qualifier of mupip load is enhanced to read both V4 format and V5 format binary extracts.

The -version qualifier sets the desired database block format version in the file header for any new blocks being written. Mupip upgrade and reorg -upgrade set this field to V5 while reorg -downgrade sets it to V4. In order to set the version to V4, the current tn of the database must be within the range of a 32-bit maximum.

On V5 MUPIP> set -version=V4 -file mumps.dat Database file mumps.dat now has desired DB format V4 MUPIP> set -version=V5 -file mumps.dat Database file mumps.dat now has desired DB format V5

Mupip journal -show=header displays the begin and end transaction numbers as 64-bit values.

On V4: MUPIP> journal -show=header -forward mumps.mjl Begin Transaction 308 [0x00000134] End Transaction 308 [0x00000134] On V5: MUPIP> journal -show=header -forward mumps.mjl Begin Transaction 1 [0x0000000000000001] End Transaction 1001 [0x00000000000003E9]

Transaction numbers within a journal file extract are now 64-bit integers with a range from 0 to 18,446,744,073,709,551,615

This maximum "number" exceeds the precision that GT.M carries for a numeric value (18 digits). Use of this value in an arithmetic expression will result in loss of precision so it should only ever be treated as a string value in any M program designed to process mupip journal extracts. As a practical matter, it is unlikely that a database file will have a transaction number that exceeds 18 digits.

Mupip upgrade/downgrade upgrades or downgrades the file-header. File-header fields like current transaction, maximum tn and others that contain transaction numbers will have their size increased from 4 bytes to 8 bytes on upgrade, and correspondingly reduced on downgrade.

UPGRADE

The upgrade command resets the various trace counters and changes the database format to V5. This change does not upgrade the individual database blocks but sets the database format flag to V5. It also initializes a counter of the current blocks that are still in V4 format. This counter is decremented each time an existing V4 format block is converted to V5 format. When the counter is 0, the entire database has been converted.

MUPIP> upgrade mumps.dat You must have a backup before you proceed!! An abnormal termination will damage the database during the operation !! Are you ready to continue the operation [y/n] ? y %GTM-I-TEXT, Mupip upgrade started %GTM-I-MUINFOUINT4, Old file header size : 24576 [0x00006000] %GTM-I-MUINFOUINT8, Old file length : 2180608 [0x0000000000214600] %GTM-I-MUINFOUINT4, Old file start_vbn : 49 [0x00000031] %GTM-I-MUINFOUINT4, Old file gds blk_size : 1024 [0x00000400] %GTM-I-MUINFOUINT4, Old file total_blks : 2105 [0x00000839] %GTM-S-MUPGRDSUCC, Database file mumps.dat successfully upgraded to GT.M V5 Linux x86

DOWNGRADE

The downgrade changes the file header to V4 format. It sets the transaction number below the maximum 32-bit TN value and removes the database certification.

A database that was created with V5.0-000 or which has standard null collation set cannot be downgraded to V4. A mupip extract in ZWR format on V5 followed by a mupip load on V4 is required to effect the downgrade.

MUPIP> downgrade mumps.dat You must have a backup before you proceed!! An abnormal termination will damage the database during the operation !! Are you ready to continue the operation [y/n] ? y %GTM-I-TEXT, Mupip downgrade started %GTM-I-MUINFOUINT4, Old file header size : 8192 [0x00002000] %GTM-I-MUINFOUINT8, Old file length : 2180608 [0x0000000000214600] %GTM-I-MUINFOUINT4, Old file start_vbn : 49 [0x00000031] %GTM-I-MUINFOUINT4, Old file gds blk_size : 1024 [0x00000400] %GTM-I-MUINFOUINT4, Old file total_blks : 2105 [0x00000839] %GTM-S-MUPGRDSUCC, Database file mumps.dat successfully downgraded to GT.M V4

REORG -upgrade

Mupip reorg -upgrade upgrades the GDS blocks that are still in V4 format, after completion of mupip upgrade. This variant of the mupip reorg command runs through the entire database (or until blocks-to-convert = 0) checking the block format of each block. If the block format is V4, it is updated to V5 format and rewritten.

A block is considered to be too long to be upgraded from V4 format to V5 format if the records occupy more than blocksize-16 bytes. The presence of even one such block will prevent a database from being upgraded.

After a database has been certified, such "too long" blocks can occur if the Reserved Bytes field is reduced with a dse change -fileheader command or if a mupip journal -recover or mupip journal -rollback command changes the state of the of the database to before the dbcertify certify operation.

This condition can be detected by mupip reorg -upgrade or during normal V5.0-000 operation when blocks are upgraded from V4 to V5 format. The only way to recover from this condition is to downgrade the database to V4 format and re-run both phases of dbcertify.

This condition can be avoided by not changing Reserved Bytes after any dbcertify step and before the mupip upgrade, and, in the event, a database has a mupip journal -recover or mupip journal -rollback performed on it, then to repeat the dbcertify steps before the mupip upgrade.

-nosafejnl

If before image journaling is active, mupip reorg -upgrade will generate before image records for these block changes even though there is no change to the data in the block. This is to ensure that backwards recovery can recover the database correctly, in the event of a system crash or power outage. In the event that a system has a battery-backed IO subsystem, or a SAN, it is unlikely that there will be incomplete writes to the journal files. As long as any pending write to the journal file is completed in the event of a system crash or power outage, the before image records are not required to recover the database. In the event your hardware guarantees that there will not be an incomplete IO write operation, you can reduce IO load on your system by suppressing the generation of these before images with the use of the -nosafejnl option. If your hardware does not provide such a guarantee, then Fidelity strongly recommends the use of the default behavior, which is to generate the before image records.

MUPIP> reorg -upgrade -reg DEFAULT Region DEFAULT : MUPIP REORG UPGRADE started Region DEFAULT : Desired DB Format remains at V5 after MUPIP REORG UPGRADE Region DEFAULT : Started processing from block number [0x00000000] Region DEFAULT : Stopped processing at block number [0x00000800] Region DEFAULT : Statistics : Blocks Read From Disk (Bitmap) : 0x00000005 Region DEFAULT : Statistics : Blocks Skipped (Free/Recycled) : 0x00000000 Region DEFAULT : Statistics : Blocks Read From Disk (Non-Bitmap) : 0x000007FC Region DEFAULT : Statistics : Blocks Skipped (new fmt in disk) : 0x00000017 Region DEFAULT : Statistics : Blocks Skipped (new fmt in cache) : 0x00000000 Region DEFAULT : Statistics : Blocks Converted (Bitmap) : 0x00000003 Region DEFAULT : Statistics : Blocks Converted (Non-Bitmap) : 0x000007E6 Region DEFAULT : Total Blocks = [0x00000839] : Free Blocks = [0x00000012] : Blocks to upgrade = [0x00000000] Region DEFAULT : MUPIP REORG UPGRADE finished

REORG -downgrade

A reorg -downgrade changes the database blocks to V4 format. The transaction number fields are reduced to 32 bits. In the event the CTN is too large to fit in 32 bits, a mupip integ -tn_reset will need to be performed prior to performing the mupip reorg -downgrade. The blks_to_upgrd counter increases to signify a downgrading database.

MUPIP> reorg -downgrade -reg DEFAULT Region DEFAULT : MUPIP REORG DOWNGRADE started Region DEFAULT : Desired DB Format set to V4 by MUPIP REORG DOWNGRADE Region DEFAULT : Started processing from block number [0x00000000] Region DEFAULT : Stopped processing at block number [0x00000839] Region DEFAULT : Statistics : Blocks Read From Disk (Bitmap) : 0x00000005 Region DEFAULT : Statistics : Blocks Skipped (Free/Recycled) : 0x00000012 Region DEFAULT : Statistics : Blocks Read From Disk (Non-Bitmap) : 0x00000822 Region DEFAULT : Statistics : Blocks Skipped (new fmt in disk) : 0x00000000 Region DEFAULT : Statistics : Blocks Skipped (new fmt in cache) : 0x00000000 Region DEFAULT : Statistics : Blocks Converted (Bitmap) : 0x00000005 Region DEFAULT : Statistics : Blocks Converted (Non-Bitmap) : 0x00000822 Region DEFAULT : Total Blocks = [0x00000839] : Free Blocks = [0x00000012] : Blocks to upgrade = [0x00000827] Region DEFAULT : MUPIP REORG DOWNGRADE finished