Teradata SQL Error and Failure Codes from Error 9126 To 9133

9126 Stack Overflow in AMP: Please do not resubmit the last request.
Explanation: This error is used to indicate when processing query encounter stack overflow in AMP.
Generated By: AMP Software.
For Whom: End User.
Remedy: Contact your Support Representative.

9127 Index violations detected; errors logged in %TVMID where ETC_dbql_qid = %FSTR.
Explanation: This error is returned when a MERGE-INTO or INSERT-SELECT statement that specified LOGGING
ERRORS logs index violations during index maintenance, and the request is aborted after all index violations are logged.
To retrieve the error rows logged for this request, query the error table with the following search condition displayed at the
end of the error message:
where ETC_dbql_qid = <Query Id>
Generated By: AMP Steps.
For Whom: End user.
Remedy: Analyse the logged errors and, if necessary, correct the source rows that caused the errors and re-load the corrected
rows.

9128 The transaction exceeded the maximum number of rowhash locks allowed.
Explanation: This error is returned when a transaction has exceeded the number of rowhash locks allowed. The threshold
on the number of rowhash locks allowed is defined in DBSControl via the General field ’MaxRowHashBlocksPercent’.
This is done so that one transaction does not fill up the lock table with rowhash locks. The number of control blocks/locks
that can fit into an AMP lock table is defined by STDMAXLOCKBLOCKS which is currently ~51860.
Generated By: LOK subsystem.
For Whom: End user.
Remedy: Reduce the number of rowhash locks that the transaction is acquiring. An alternative is increase the General
field ’MaxRowHashBlocksPercent’ value in DBSControl.

9129 Attempt to access a down Table or Index
Explanation: A statement has attempted to access a table or index that has been set down. It is not currently accessible
for SQL statements.
Generated By: AMP (STP, S2S, SUT).
For Whom: End User.
Remedy: Reset the down table or index status before resubmitting the SQL statement. Some of the ways to reset the
down status are: – ALTER TABLE SQL statement – Fast path DELETE ALL/ DROP table SQL statement – Rebuild the Table
– Restore the table from backup – Drop and recreate the index

9130 Cannot operate on table/index with down regions
Explanation: A statement has attempted to access a table or index with down regions in it.
Generated By: AMP (STP, S2S, SUT).
For Whom: End User.
Remedy: Remove the down regions in the table/index before esubmitting the SQL statement. Some of the ways to
rmove 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

9131 Check was skipped due to detection of error %d.
Explanation: This message indicates that the CheckTable utility could not check the table due to table/index is marked
down or its subtable contains down region.
Generated By: CheckTable
For Whom: End user or Field Engineer or the concerned site support representative.
Notes: While checking a table, if the CheckTable utility encounter down table/index or sutable contains down region,
then the table check is skipped. The problem that caused this error is indicated in <error code>. Aftr this error, CheckTable
proceeds to check the remaining table(s), if any.
Remedy: Correct the error table by using the following 1. If the error event is 9129, 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 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.

9132 EVL object for %TVMID is too large for cache. Space needed is %VSTR bytes.
Explanation: The AMP replication cache segment is too small to contain an object of the indicated size. Consequently,
the insert, update, or delete action on the indicated table cannot be replicated, and the transaction fails. The size of the
cache segment is 512KB by default, and it may be changed using the DBSCONTROL utility to be smaller or larger.
Generated By: AMP EVL cache manager.
For Whom: System administrator.
Remedy: Set the replication cache segment size (DBSCONROL general parameter 48) to a larger value. See the Teradata
Utilities Reference manual for more detailed guidance.

9133 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.

Above are list of Teradata Errors or Failure Codes from Error 9126 To 9133 received while performing certain operation against Teradata Database or related products.

What are Teradata Database Errors?

In general, each Teradata error message contains the following information:
• The message number.
• The message text. This text is usually returned with the message number. Some messages employ word substitution, where the word substituted represents the system-replacement of a term more specific to the occurrence.
• An explanation of how the error may have occurred.
• Generated-by text that indicates the software module which initiated the message. This field serves a diagnostic purpose for support and development personnel.
• A remedy which suggests how to resolve the condition.

Hope this was helpful.

Thanks,
SQLServerF1 Team
Information about Teradata SQL Error and Failure Codes and Error Messages on Windows, Linux Operating Systems.

 

Leave a Reply

Your email address will not be published. Required fields are marked *