Teradata Database Message 9133 - 9133 - Analytics Database - Teradata Vantage

Message

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

Explanation

The transaction was aborted due to fatal error occurred in the internal step logic while processing an AMP step. The failing subtable id is described in the message. 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 <sub-id> variable string at the message is displaying the subtable id. The subtable id will indicates which subtable contains the down information. The <error-id> is the fault of the cause. The %VSTR variable string only will print at stream log, takes a variety of forms depending on the failing step, and 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: SubCode : indicates the action of the abort - ERRAMPDOWNTABIND (9129) The table is being marked down. - ERRAMPDOWNREGION (9130) A down region being marked at the table. - (0). Table header is not updated. CrashCode : indicates the original error code used to flag the error. Amp <amp-id> <curr-table> \ in <step-id>: <step-text> where: <amp-id> := <amp-n> | <amp-n> on <node-n> <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 <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 may 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, the amp may handle the failure with a full system restart rather than a transaction abort when snapshot dump is requested otherwise it is ok not have snapshot dump associated with this event. When used as the event code key in the software event log or the related streams log display, the ERRAMPDTDRABORT 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, check the subtable id to identify which subtable the down situation occurred. Second, check the error code in the VSTR for the cause of the error. The event reports the action could have the following - ERRAMPDOWNTABIND (9129) - ERRAMPDOWNREGION (9130) - ERRFILDBDOWN (5234) - ERRFILCIDOWN (5235) Correct the error table by using the following 1. If the error event is 9129 or 5234, remove the down regions in the table/index before resubmitting the SQL statement. Some of the ways to remove the down regions are: - Fast path DELETE ALL/DROP table SQL statement - Rebuild the Table - Restore the table from backup - Drop and recreate the index 2. If the error event is 9130 or 5235 then reset the down table or index status before resubmitting the SQL statement. Some the of the ways to reset the down status are: - ALTER TABLE SQL statement - Fast path DELETE ALL/DROP table SQL statement - Restore the table from backup - Drop and recreate the index Note that the above correction should always be done manually. 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.