ARC1234 Configuration change when re-hashing data
Explanation:
A RESTORE/COPY operation has determined that the on-line AMP configuration has changed AND that the target machine uses a different hashing algorithm than the source machine (e.g.International Hash versus Old Hashing algorithm). This reaction is analogous to what would happen if you had the HALT run-time option enabled and the RESTORE FALLBACK option disabled. The reason the utility does this is because in most scenarios the configuration change MAY have resulted in data loss if some tables restored earlier in the data- base have not yet been sorted. The only exception that the utility allows to this rule is when all of the following are true: all tables in the database are fallback, the archive was dumped from all AMPs, the user did NOT choose the NO BUILD option on the RESTORE/COPY statement. For this one exception the utility will automatic- ally re-wind the archive and restart the restore from the start of the current table.
For Whom:
End User.
Notes:
This is a FATAL error.
Remedy:
Determine the cause of the configuration change. If the problem is anything other than a failure requiring the re-formatting of a disk drive, you can probably RESTART the job from the point of failure after the configuration has come back to the point it was before. If, however, you determine that an AMP needs to be replaced and you have lost data, you need to re-restore the table/database from the beginning. Note that this means that if you get the error on the restore of a specific-AMP or cluster archive you need to re-restore the very first archive (whether it was an all-AMPs or dictionary archive).