Teradata Database Message 7487 - 7487 - Analytics Database - Teradata Vantage

Message

AMP step failure: Please do not resubmit the last request.

Explanation

The transaction was aborted due to an unexpected error while processing an AMP step. The failing step and the specific error event are described in the variable text extension displayed in the one or two lines immediately following the fixed error message text.

Generated By

AMP step handlers.

For Whom

End User. Site support representative.

Notes

The %VSTR variable string only will print at stream log, takes a variety of forms depending on the failing step, the tables accessed by the step, and whether the error occurred on a table access operation. The general syntax of the message is as follows: Amp <amp-id> error <error-id> <curr-table> \ in <step-id>: <step-text> where: <amp-id> := <amp-n> | <amp-n> on <node-n> <error-id> := <err-n> | <err-n>(<err-detail>) <curr-table> := <null> | on <table> |, at <table> <step-id> := stmt <stmt-n> step | step (<step-n>) | step (<step-n>.<substep-n>) <step-text> := <step-name> | <step-verb> <step-table> | <step-name> using <table> | Receive Hashed rows from <step-name> | Receive Duplicated rows from <step-name> <amp-n> = "%d" : failing Amp vproc <node-n> = "%d-%d" : node where <amp-n> is located <err-n> = "%d" : failing error code <err-detail> = "%s" : short failure detail text <stmt-n> = "%d" : failiing statement number <step-n> = "%d" : failing step number in request EXPLAIN <substep-n> = "%d" : failing parallel substep in EXPLAIN The transaction abort will be accompanied by a snapshot dump of the failing Amp task whenever the snapshot dump capability is available on the system and enabled for general usage. If the user disables snapshot dumps for specific failure cases, however, or if the amp logic disables snapshots temporarily because too many have been done recently, then the amp will handle the failure with a full system restart rather than a transaction abort. When used as the event code key in the software event log or the related streams log display, the ERRAMPFAILABORT code is always coupled with another error code for the amp failure that caused the associated snapshot dump and abort event. An event will also be logged under that associated error code, with additional information in some cases logged as separate events using ERRAMPFAILINFO or ERRAMPFAILTEXT.

Remedy

END USER: First, obey the admonition in the error message and do not resubmit the query containing the failing request until the underlying problem in the AMP software has been analyzed. Although retries of the failing request might contribute to this problem analysis, any such diagnostic tests should be performed only by authorized support personnel. One possible outcome of the analysis is to conclude that the failure occurs rarely, with no harmful side-effects, and that it is therefore safe to retry the query or job manually when it occasionally fails with the same reported symptoms. Note that this sort of workaround should always be done manually, however, and only for the specific problem case for which it has been authorized. The following caveat should therefore be applied: WARNING: Never use error-handling logic in a production application that treats the 7487 error code as retryable. SITE SUPPORT STAFF: If a snapshot dump was taken, make sure it is saved to the crashdumps database for offloading. Have all traceback and associated information from the error log ready and then contact the Global Support Center. As noted above, the Global Support Center might determine that the failing query or job can be manually retried for a specific 7487 failure case as a workaround until a fix for the underlying problem is available. These workaround details should be carefully noted so that manual retries can be strictly limited to the authorized failure cases.