Specifies the proportion of available locks a transaction can use for rowhash locks before the transaction is automatically aborted. This setting protects Vantage against misbehaving database transactions.
To run, every query must acquire a lock on the objects upon which it will act. There are different types of locks: rowhash, rowrange, table, and database. A special table is used to keep track of the locks that have been applied. This lock table is maintained in memory for each AMP.
If a transaction performs a large number of single-row updates without closing the transaction, the lock table can fill up with rowhash locks on one or more AMPs. This prevents other transactions from running, and no further work can be accomplished until the problematic transaction is aborted to make space in the lock tables. This generally requires a database restart, unless the system returns an error, in which case the locks held by the query will be freed.
The Lock Manager Fault Isolation feature of Teradata monitors the number of locks each transaction uses. If the proportion of rowhash locks used reaches the threshold defined by MaxRowHashBlocksPercent, the transaction is automatically aborted. Other transactions are not affected, and the system need not be restarted.
50%, which means that a transaction will be stopped if its rowhash locks require more than 50% of the maximum space allowed in the lock table on any AMP.
To allow transactions to acquire more locks, set MaxRowHashBlocksPercent to a greater value.
Changes Take Effect
After the DBS Control record has been written.