GT.M Database Migration

Return to top

Quick Start

Follow these steps if you simply want to upgrade your database as expeditiously as possible. In this context, field test releases of V5 (e.g., V5.0-FT01) are considered V4 releases. For details, go to Background. There are two approaches, Traditional and In-place Upgrade.

Return to top

Traditional

The advantage of the traditional database migration technique is that database files created with GT.M V5 have a maximum file size limit of 134,217,728 (128M) blocks, which means that the maximum database file size using the popular 4KB block size is 512GB, and the largest possible database file size is a little less than 8TB. With GT.M V4 database files converted to V5, the maximum number of blocks is 64M, which means that with a 4KB block size, the maximum database file size is 256GB, and the largest possible database file size is a little less than 4TB.

1. Using DSE, increase the Reserved Bytes parameter in each database file header by 8 (UNIX) or 9 (OpenVMS).
2. Run dbcertify scan on each V4 database file to determine whether there are any records that are too large to fit in a V5 database with the same block size. If there are, a Traditional Upgrade will be required for this database file.
3. Bring down all V4 GT.M processes and execute mupip rundown -file on each database file to ensure that there are no processes accessing the database files. Change the file permissions to read-only.
4. For every database region that has GT.M replication turned on, note down the Region Seqno (DSE DUMP -FILE for each database region displays this value). If upgrading to a version prior to GT.M V5.1-000, also note down the Resync Seqno (displayed alongside the Region Seqno) for each database region.
5. Use V4 mupip extract -format=binary to extract data in each database file. Archive V4 database files (and journal files, if you normally archive journal files).
6. Make copies of all global directory files. Use V5 GDE to open and exit each global directory to update it to V5 format. (This step is not needed when upgrading from V5 field test releases.)
7. For those database files identified in step 1 as containing records too large to fit in a V5 database file with the same block size, use V5 GDE to increase the block size, and since the initial allocation and extension sizes are in blocks, ascertain whether these should be reduced.
8. Use V5 mupip create to create new database files.
9. Use V5 mupip load to load the data extracted from V4 databases into the new V5 database files.
10. Use V5 mupip set -replication=on to enable GT.M replication on all appropriate database files. Set the Region Seqno for each replicated database region to the value noted down from the corresponding region in Step 3a (use the DSE CHANGE -FILE -REG_SEQNO= command for this purpose). On the other hand, if as a result of the upgrade, the database regions that have replication turned on are changing, there will no longer be a one-to-one correspondence between the pre-upgrade and post-upgrade replicated database regions. In this case, compute the maximum (across all replicated database regions) of the Region Seqno values noted down in Step 4. Set the Region Seqno of ALL the post-upgrade replicated database regions to the computed maximum value. If this replication instance will be brought up as a secondary after the upgrade, it is important to note that the receiver server should be started with the -updateresync qualifier. If upgrading to a version prior to GT.M V5.1-000, set the Resync Seqno for each replicated database region to the value noted down from the corresponding region in Step 4 (use the DSE CHANGE -FILE -RESYNC_SEQNO= command for this purpose). Just like the Region Seqno, if there is no one-to-one correspondence between the pre-upgrade and post-upgrade replicated database regions, compute the maximum of the noted Resync Seqno values and set the Resync Seqno of ALL replicated database regions to this value.
11. Recompile routines and rebuild shared libraries (can be done in parallel with the above).
12. Use GT.M V5 normally.

Return to top

In-place Upgrade

The advantage of an in-place upgrade is that in a single site implementation of GT.M, the time that applications are unavailable is minimized (tens of seconds to minutes in the typical case).

1. The following steps can be taken while GT.M V4 applications are normally active.

   1. Using DSE, increase the Reserved Bytes parameter in each database file header by 8 (UNIX) or 9 (OpenVMS).
   2. Run dbcertify scan on each V4 database file to determine whether there are any records that are too large to fit in a V5 database with the same block size.
   3. Run V5CBSU as a V4 process (this is an M program that will compile and run on all V4 versions of GT.M). Optionally, run V4 mupip reorg before V5CBSU - this may reduce the time taken by V5CBSU in the event that the output of the preceding step is large.
   4. Take a backup of all the database files, in the event that a backup is not planned for when the application is down.

2. Bring down all V4 GT.M processes and execute mupip rundown -file on each database file to ensure that there are no processes accessing the database files.

3. Take a backup of all the database files. Alternatively, use mupip journal -recover -forward to apply journal files to backups of database files taken above. Note that this may involve multiple generations of journal files for each database file. Archive journal files, if the policy is to archive journal files.

4. Use dbcertify certify to certify all the database files as being ready to be upgraded to V5 format.

5. Use V5 mupip upgrade to upgrade the database file header from V4 format to V5 format.

6. Recompile routines and rebuild shared libraries (can be done in parallel with the above).

7. Make copies of all global directory files. Use V5 GDE to open and exit each global directory to update it to V5 format. (This step is not needed when upgrading from V5 field test releases.)

8. Run dse maps -restore_all on the upgraded database. This will rebuild all the maps and reflect the blocks used in the database file.

9. Resume normal GT.M applications with V5.

10. While GT.M V5 applications are in normal use, run V5 mupip reorg -upgrade to convert any V4 format blocks that may be read but may not be updated (e.g., history records) to V5 format.