Most full-system migrations involve destination systems with sufficient space for the operation. In rare exceptions, or when a disaster-recovery system is not the same configuration as the production system, the destination system may be smaller than the source system. In such cases, special steps are required for a successful restore. Teradata recommends that you contact Teradata Support to ensure a successful migration.
In many cases of migrating to a smaller system, the Max Perm allocations on the destination system will have to be reduced by a system administrator after a successful restore. DSA will allocate to each user/database the same Max Perm that was allocated on the source system before the backup. This means the total of the Max Perm allocations from the larger system may cause the Max Perm allocated to DBC on the smaller system to become negative. In that case, immediately following a successful restore to a smaller system, a system administrator must reduce the Max Perm allocations of each user/database to more closely match the actual Current Perm used by each user/database. Until the DBC Max Perm allocation is positive, the system will be virtually unusable.
If the source system has more physical data (Current Perm) than can fit on the target system, you must exclude some databases from the restore operation until the amount of data being restored is less than the physical disk space available on the target system.
It is more common that a restored user/database exceeds its allocated Max Perm. This is the case when the physical disk space on the target system is actually sufficient to hold all of the existing data from the source system, but the amount of allocated space (Max Perm) on the source system is larger than the physical disk space on the target system. This situation causes the Max Perm for DBC on the target system to become negative. When that happens, any SQL statement that requires any additional space fails, and reports an out of space error.