Db2 Net Search Extender index migration tool from 32-bit to 64-bit (Linux/Unix)

Net Search Extender indexes built under 32-bit Db2 instances are not compatible with 64-bit instances.

Trying to search on an index, or to update an index in a 64-bit Db2 instance built under a 32-bit instance always results in an error message preventing the operation from completion. The reason for this is a word size-specific format of a number of small files that are part of the index.

Previously, the only recommendation for upgrading from 32-bit to 64-bit instances, was to drop and re-create the NSE indexes that you built in your 32-bit instances. If you have indexes of small or moderate size, where the textual content of the table is accessible directly, you can follow this recommendation with low or moderate technical effort. However, as indexes grow the rebuilding of the NSE indexes takes considerable amount of time, even though tuned systems are able to process up to 12 GB/hr. To avoid the need to completely rebuild your indexes, you can use the Db2 Net Search Extender index migration tool to migrate the indexes offline.

To avoid the need to completely rebuild your indexes, you can use a tool to migrate the indexes offline. The current version of tool supports only AIX® and Solaris operating systems.

For Content Manager Systems, the content indexed by Net Search Extender is not local to the table on which the index is defined for all non-attribute indexes. Attributes are metadata stored on the library server and their content is local. For the CM systems, the text documents are not local to the Net Search Extender database table enabled to full text search. Instead the documents are kept in a separate document server and sent to Net Search Extender for indexing. The content is retrieved and filtered from a remote location (in CM lingo: the Resource Manager) with considerable latency penalties. This slows down the indexing itself, and thus makes the rebuilding of NSE indexes prohibitively expensive.

If you are currently operating on 32-bit instances of Db2 and are still running Db2 in the Version 8 release, on AIX and Solaris platforms you have to update the Db2 instances from 32-bit to 64-bit before you migrate from the Version 8 release to releases Version 9.1, Version 9.5 or Version 9.7. For all these releases, 32-bit instances no longer exist on these two platforms.

Index migration (as described in the following section) has to be performed before a 32-bit to 64-bit migration of the Db2 instance and databases.

Index Migration Procedure

  1. Download the Index migration tool from the FTP site.
  2. Extract the compressed file to any directory on your system.
  3. Index migration tool can be executed by running the shell script ctemigridx.sh. Execute the shell script (./ctemigridx.sh) as described in the following section.

For Db2 Version 8 32-bit AIX environments:

  1. Log in as the instance owner
  2. Extract the archive NSE_32_64_Idx_Migr_Tool_AIX_SOL.tar.gz.
  3. Navigate into the NSE_32_64_Idx_Migr_Tool_AIX_SOL directory.
  4. Check if the Db2 database manager is up and running and NSE is stopped.
  5. Run /usr/sbin/slibclean to clear the AIX library cache. This is necessary, to avoid conflicts between installed NSE libraries and libraries of the same name in the NSE_32_64_Idx_Migr_Tool_AIX_SOL directory. Depending on your system configuration, you might need root user authority to be able to run slibclean.
  6. Run the shell script ctemigridx.sh. The script can be executed in one of the two available modes.

    The first mode takes a database name as argument, and automatically determines all existing indexes in that database and offers to migrate them all at once, or selectively

    Mode 1: This mode establishes a database connection and queries all data that is needed from the NSE database tables. After that it shows a list of indexes that are ready to get migrated. You can choose one index or all listed indexes. Adding the -check parameter to the command causes it to perform all the necessary steps without the migration.

    Example: ./ctemigridx.sh -dbname sample

    Mode 2 can be used to migrate a particular index, if you know the index name already, and want to target the migration of this index. This mode is useful if you have a large number of indexes, and want to avoid going through a long menu of indexes. It also comes handy if you are running repeated tests with an individual index. This mode takes index information and migrates it silently without user interaction.

    Mode 2: ./ctemigridx.sh -i index-name -p index-directory [-showmap]

    Example: ./ctemigridx.sh -i IX123456 -p /home/user/sqllib/db2ext/indexes

    The index directory has to be specified in the same way as it is used at index creation time. The index directory always has a NODE0000 subdirectory which then contains the index itself. If you add the -showmap flag, the log file shows a dump of the migrated index attribute (sections and attributes) for additional verification purposes.

    . /ctemigridx.sh -i IX123456 -p /home/user/sqllib/db2ext/indexes -showmap

  7. After this, index migration is complete; the user can proceed to perform the instance migration to 64-bit as described in the Db2 documentation.

For Db2 Version 8 32-bit Solaris environments:

All steps are identical to the ones that need to be done for AIX, only the slibclean step is not needed. slibclean does not exist on Solaris.

ctemigridx.sh syntax

Read syntax diagramSkip visual syntax diagram./ctemigridx.sh -h-H-?-dbnamedatabase-name-check-iindex-name-pindex-directory-showmap
-h, -H, -?
Shows command help and exits.
-dbname database-name
The name of the database.
-check
Performs all the necessary steps without migration (simulation).
-i index-name
Name of the index to be migrated, it is always in the form IXnnnnnn.
-p index-directory
The directory where the index is located. It has to be specified in the same way as it is used at index creation time. It is ~/sqllib/db2ext/indexes in most cases.
-showmap
Causes the log file to show a dump of the migrated index attributes (sections and attributes) for additional verification purposes.
Note:
  1. The current migration tool does not support the migration of indexes restored in an already migrated Version 9 instance.
  2. The Db2 instance must be started and NSE must be stopped before running the index migration tool.
  3. You must have write permission on the current directory before running the tool.
  4. The tool backs up index files that will be changed only, it does NOT back up the entire indexes. It is advisable to back up the entire index directory before proceeding with execution of the tool.
  5. You must execute the tool as Db2 instance owner but not as root.
  6. If the db2_local_ps command does not give results, then the Db2 database manager is not started and the tool will not work.
  7. Currently the migration tool supports single-node systems only.