Teradata Database Message 2536 - 2536 - Analytics Database - Teradata Vantage

Message

Data lost while recovering from a read error.

Explanation

A disk read error occurred in a table which: 1) has no fallback copy, or 2) is an abended fastload table, or 3) is an abended restore table, or 4) is an invalid index table, or 5) is a permanent journal table, or 6) has been recovery aborted. 7) has been rebuild aborted. 8) has been reconfig aborted. 9) has fallback copy with amp down in the cluster. 10) is one of the following mload work subtables: - private permanent journal. - local checkpoint - foreign checkpoint - bit map - data 11) was corrupted in other amp in the cluster such as missing table header or table is being rebuilt. 12) is mload dump work subtable. Some data was lost, and the Teradata DBS cannot or will not rebuild it.

Generated By

U2URBK/RbkRcvy.

For Whom

Operator. DBA. End User.

Notes

Table header will be updated to indicate rebuild in process if rebuild failed.

Remedy

If the table has no fallback copy, you may recover the table from an archive. If the table is in fastload state, you may delete all the associated fastload tables and resubmit the fastload job. If the table is in restore state, you may recover the table from an archive. If the table is an invalid index table, you may drop the index and recreate the index. If the table has been recovery aborted, you may drop it or recover the data from an archive. If the table has been rebuild aborted, you should try to rebuild the whole table via Rebuild utility. If the table has been reconfig aborted, you may drop it or recover the data from an archive. If the table is a permanent journal table, Contact your Support Representative. If there is an amp down in the cluster, we should try to bring the down amp back to configuration and attempt to rebuild the table again. If rebuild fails after down amp rejoins the configuration, it usually means the table has been rebuilt aborted in more then one amp in the cluster. In order to recover the data, you may need to do restore and rollforward. If the table is one of those mload work subtables which can not be recovered due to no fallback. In order to recover the target table prior mload take place, restore (and rollforward) may require. If the rebuild table was corrupted in other amp in the rebuild cluster, in order to recover the target table prior mload take place, restore and rollforward may require. If the table is mload dump work subtable, subtable will be deleted, however table header will NOT be marked as rebuild in process.