Skip to end of metadata
Go to start of metadata

 

Overview

Error messages that may occur when performing change transactions.

 

Version

This error message can occur in all versions of Altibase, but the error message differs depending on the version of the Altibase server.

  • ALTIBASE HDB 4.3.9 ~ 5.3.3
    ERR-11075 (  69749) The transaction exceeds the lock timeout specified by user. 

  • ALTIBASE HDB 5.5.1 or later
    ERR-11075 (  69749) The transaction has exceeded the lock timeout specified by the user. 


Symptom

The following are examples of some of the most common symptoms in which this error message occurs.

1. Occur when executing a DDL statement

 

Session-1

Session-2

DDL(truncate문) 수행 시 에러 발생

autocommit off;  
update test_emp_tbl set emp_no = 10;                             
 
while executing update...truncate table test_emp_tbl;                         
[ERR-11075 : The transaction has exceeded the lock timeout specified by the user.]

 

 

2. Occurs when a change transaction is performed on the memory table

Session-1

Session-2

iSQL> autocommit off;
Set autocommit off success.


iSQL> update tb_test1 set c10=sysdate where c1=1;
1 row updated.

 

 

iSQL> select count(*) from tb_test1;
COUNT                
-----------------------
1000000              
1 row selected.


iSQL> alter session set TRX_UPDATE_MAX_LOGSIZE=100000000;
Alter success.

iSQL> alter system set LOCK_ESCALATION_MEMORY_SIZE=100000000;
Alter success.


iSQL> update tb_test1 set c10=sysdate;
[ERR-11075 : The transaction has exceeded the lock timeout specified by the user.]

3. Occur when executing a SELECT statement using SELECT FOR UPDATE WAIT N (or NOWAIT)

Session-1Session-2
autocommit off; 
update test_emp_tbl set emp_no = 10; 		 
 select * from test_emp_tbl for update wait 1; 
[ERR-11075 : The transaction has exceeded the lock timeout specified by the user.]
 select * from test_emp_tbl for update nowait;
[ERR-11075 : The transaction has exceeded the lock timeout specified by the user.]  

4. Occur in altibase_rp.log in a replication environment

In a replication environment, an error may occur in $ALTIBASE_HOME/trc/altibase_rp.log.

 

Cause 

This error occurs when trying to acquire a lock on an object, but the object is already locked and the lock cannot be acquired.

 

1. Occur when executing a DDL statement

When executing DDL statements, if the target table is already locked by another transaction, DDL execution may fail because the LOCK for DDL execution cannot be acquired immediately.

This may behave differently depending on the DDL_LOCK_TIMEOUT setting of the Altibase server property.

    • DDL_LOCK_TIMEOUT = 0 (default)
      If the LOCK is not acquired, it is immediately failed.

    • DDL_LOCK_TIMEOUT = 1
      If it cannot acquire LOCK, it waits indefinitely
    • DDL_LOCK_TIMEOUT = seconds 
      If LOCK is not acquired during DDL execution, wait for the specified time and try again. 
      If the LOCK is not acquired even when trying again, it will fail.

2. Occur when a change transaction is performed on the memory table

When the size of the transaction log file exceeds the value of the LOCK_ESCALATION_MEMORY_SIZE property due to a change transaction performed on the memory table, it switches from record level IX_LOCK to table level X_LOCK. At this time, if IX_LOCK is locked on another record of the table in another session, the table level X_LOCK acquisition may fail and an error may occur.

3. Occur when SELECT FOR UPDATE WAIT N (or NOWAIT) is executed

A SELECT statement using SELECT FOR UPDATE WAIT N or SELECT FOR UPDATE NOWAIT locks the record and executes it.

However, if a lock is first locked in another session on the same table, an error may occur because the lock cannot be acquired.

4. Occurs in altibase_rp.log in a replication environment

When the transaction to be reflected is waiting for the transaction of the local server to be finished.

Active Server

Standby Server

alter replication rep1 start;

 

 

iSQL>  autocommit off;
Set autocommit off success.
iSQL> insert into tb_test1(c1,c10) values(1000001, sysdate);
1 row inserted.

iSQL> autocommit off;
Set autocommit off success.
iSQL> insert into tb_test1(c1,c10) values(1000001, sysdate);
1 row inserted.

 

The insert statement of the active server should be reflected in the standby server, but when the replication transaction cannot be reflected due to the local transaction of the standby server, an error message is recorded in altibase_rp.log.

This symptom is affected by the value of the REPLICATION_LOCK_TIMEOUT property.

If the server reflecting the redundancy log (standby server in the example above) does not acquire LOCK within the REPLICATION_LOCK_TIMEOUT (seconds) time, the above error occurs and the redundant transaction attempted to reflect fails.

 

Solution

  • Occur when executing DDL
    Generally, it is recommended to perform DDL in idle time. If the service is not stopped, X LOCK acquisition may fail instantaneously. If an error occurs, try performing DDL several times. If the same error still occurs, check whether the target table is busy or there is a long-run query (a query that takes a long time to execute or a query that has not been committed), and execute DDL again after taking action.
  • Occur when performing a change transaction in memory
    If the above error occurs due to LOCK_ESCALATION_MEMORY_SIZE, there is a high possibility of a large amount of change transactions.
    Make sure not to make a large number of change operations. It is recommended that the number of records to be changed is reduced by using conditional clauses and limit clauses and divided into multiple times to perform change transactions.
  • Occur when executing SELECT FOR UPDATE statement
    Repeat the SELECT FOR UPDATE statement until it succeeds.
    Find uncommitted transactions and commit or rollback.
    Increase the time of the WAIT option.

  • Occur in a replication environment
    When designing for replication, consideration should be given to avoiding simultaneous changes on both servers for the same record.
    When this error occurs, it may cause a problem with the data integrity of both servers, so the data must be checked.

     

Reference

 

 

 

 

 

  • No labels