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 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.
- -w, known as wait mode, keeps the script running without further interaction until AMPs are back online. Used alone or in conjunction with -t.
- -t changes the interval between display of rebuild progress messages from the default value of 4 seconds. Append this option with the number of seconds you want to elapse between status messages. For example, type -wt 20 to display status every 20 seconds.
- Ctrl-c pauses the rebuild with the intention of rerunning it later. Entering #tdc-rebuild restarts the script.
- -c cancels the rebuild process completely if it has started.