MOVE AMP Operation
In a MOVE AMP operation, Reconfiguration copies all rows from the Move-From AMP to the Move-To AMP.
You can move a range of AMPs to another range of AMPs; however, a one-to-one correspondence between the Move-From AMPs and the Move-To AMPs must exist.
The following sequence discusses the state of these AMPs before, during, and after the reconfiguration process.
- The Parallel Upgrade Tool (PUT) is used to start the reconfiguration process. During this step, PUT identifies new AMPs on the system. Some of these new AMPs may have been added, and some may be targets of the MOVE AMP process. PUT must be used at this time to identify which AMPs are the move-to AMPs and which are the move-from AMPs.
- The Configuration utility (config) is used to complete the DBS configuration of AMPs in regards to adding and moving AMPs, and defining the cluster configuration. The move-to AMPs and the move-from AMPs specified in the config commands must match the MOVE AMP definitions specified during the PUT process
- Prior to and during most of the reconfiguration process, the move-to AMPs are configured as new AMPs, just as if you added them. move-to AMPs have their own vproc numbers and associated storage. PUT sets up the relationship between an AMP and its storage.
- The file system tracks which storage belongs to which AMPs by inserting the AMP number in the cylinder indexes written with each cylinder. This allows the file system to verify that multiple AMPs do not write to the same cylinder of storage.
- When almost finished, Reconfiguration saves the Teradata Database configuration maps to indicate the new configuration.
- Reconfiguration notifies the file system to update the cylinder indexes to indicate the change in storage ownership.
- Reconfiguration sets a control flag to keep Teradata Database in a DOWN state and to initiate a restart.
- While Teradata Database is in a DOWN state, PUT exchanges the storage mapping between the move-from and move-to AMPs.
You can shorten the time that Teradata Database is down and unavailable by using the Configuration utility to create a new contiguous map that does not include any of the AMPs in the MOVE AMP operation. Prior to running MOVE AMP, use the ALTER TABLE MAP statement to redistribute user tables off of the move-from and move-to AMPs.
For more information about CREATE MAP and ALTER TABLE MAP, see SQL Data Definition Language - Syntax and Examples
For additional information on the MOVE AMP command, see Configuration Utility (config).
Fatal AMPs during a MOVE AMP Operation
When Reconfiguration completes a MOVE AMP operation, change the PUT configuration to associate the new storage and AMPs correctly. If the configuration is not changed, when Teradata Database restarts the move-to AMPs are marked FATAL.
DELETE AMP Operations
When Reconfig physically deletes AMPS from the configuration, the utility will not process any user tables that use maps that include deleted AMPS. You must use the ALTER TABLE MAP statement to change the maps these tables use while the database is up. The Reconfiguration utility will only move rows from Data Dictionary tables off of the deleted AMPs.
Effects on Journal Tables
Reconfiguration deletes all journal tables (active, saved, and restored subtables).
Effects on PA and NoPI Tables
There are special considerations for reconfiguring a system that includes PA or NoPI tables.
Reconfiguring a system that includes PA or NoPI tables can result in data skew for those tables if they are processed by the Reconfiguration utility. Because the number of hash buckets per AMP in PA and NoPI tables is often small (usually only one per AMP), when a reconfiguration involves changes in the number of AMPs, some AMPs may end up with substantially more rows than other AMPs. Consequently, it is best to minimize the number of PA and NoPI tables on the system before performing a reconfiguration, especially in cases where NoPI staging tables are large. For more information on PA and NoPI tables, see Database Design and SQL Data Definition Language.
Nonempty PA tables are marked as “Reconfig-Aborted” when:
- Changing hash bucket size for a system
- Changing the number of AMPs
Redistributing rows of a PA or NoPI table can result in table skew, when some AMPs receive more rows than other AMPs. In those cases, permanent space can become an issue for those AMPs. The following can be done for skew and reconfig-aborted PA tables:
- For a skewed NoPI table, create a new NoPI table, and use an INSERT...SELECT operation with HASH BY RANDOM clause to copy the rows from the original NoPI table to the new table.
- For a PA table marked as “Reconfig-Aborted”, create a new PA table and use an INSERT...SELECT operation to copy the rows from the original PA table to the new PA table.
For more information on PA and NoPI tables, see SQL Data Definition Language and Database Design.