Rebuilding AMPs after Failure
If a Teradata system with local storage loses a node, it also loses the portion of the database kept on the AMPs. When Teradata brings up a replacement node, the AMPs come up in FATAL state. Fallback is enabled by default on all tables so data is maintained in fallback rows on the other AMPs until the AMP is rebuilt on the replacement node. The AMP rebuild process restores the data for the lost AMPs and brings the AMPs back online.
The length of time to rebuild AMPs depends on how much data must be copied and how much other work the database is doing while the rebuild is in progress. Consider scheduling rebuilds at times that minimally impact users. You can start the rebuild and check progress at regular intervals, such as every hour.
The database must be operational before starting the AMP rebuild process. The rebuild process brings up the database if it is down, but if whatever went wrong prevents the database from starting, that must be fixed before the rebuild can begin
The rebuild stops and restarts the database when the rebuild is initiated and when it is done. If the database restarts for other reasons while a rebuild it running, you must rerun the tdc-rebuild script after the database is back up to resume the rebuild. If the script is running in wait mode when a restart occurs, you must cancel and restart it.
If you were using EBS storage (m4 instance types) when a failure occurred, you must first run the tdc-rebuild-ebs script to replace the EBS volumes and then run the tdc-rebuild script to rebuild the AMPs. See Running a Script to Replace EBS Volumes.