Release 10.1A: OpenEdge Data Management:
Database Administration

> ## PROUTIL IDXMOVE qualifier

> Moves an index from one application data area to another while the database remains online.

> #### Syntax

> proutil `db-name` -C idxmove [ `owner-name`.]`table-name`.`index-name` `area-name`

> #### Parameters

> ``db-name``

> Specifies the name of the database containing the table.

> ``owner-name``

> Specifies the owner of the table containing the data you want to dump. You must specify an owner name unless the table’s name is unique within the database, or the table is owned by PUB. By default, Progress 4GL tables are owned by PUB.

> ``table-name``

> Specifies the source table containing the index to be moved.

> ``index-name``

> Specifies the name of an index to move.

> ``area-name``

> Specifies the area name of the target application data area into which the index is to be moved. Area names that contain spaces must be quoted. For example, “Area Name.”

> The PROUTIL IDXMOVE utility operates in two phases:

> - Phase 1: The new index is being constructed in the new area. The old index remains in the old area, and all users can continue to use the index for read operations.

> - Phase 2: The old index is being killed, and all the blocks of the old index are being removed to the free block chain. For a large index, this phase might take a significant amount of time. During this phase all operations on the index are blocked until the new index is available; users accessing the index might experience a freeze in their applications.

> #### Notes

> - While you can move indexes online, no writes to the table or its indexes are allowed during the move. The IDXMOVE utility acquires a SHARE lock on the table, which blocks all attempts to modify records in the table. Run the utility during a period when the system is relatively idle or when users are doing work that does not access the table.

> - No other administrative operation on the moved index will be allowed during the move of the index. It will be blocked. For example, you cannot run an index move utility and at the same time run the index fix or the index compacting utilities on the same index.

> - Because the index move utility needs to acquire a share lock on the table, there is a possibility that it will have to wait before it can acquire the lock and start operating.

> - You might be able to improve performance by moving indexes that are heavily used to an application data area on a faster disk.

> - The _UserStatus virtual system table displays the utility’s progress. For more information, see Chapter 14, " Maintaining Database Structure."

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095