Archives of the TeradataForum

Message Posted: Mon, 27 Nov 2006 @ 15:58:45 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Here is the text of the message. Please read this entire text and follow the instructions for obtaining help from the Global Support Center:

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

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 at the end of the message text 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: steptext 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.

	<Prev	Next>		<<First	<Prev	Next>	Last>>