As you all know, Dameng database supports concurrent access and modification of data by multiple users. In actual work, there may be cases where multiple transactions access and modify the same data at the same time. When a transaction is occupying a resource lock, another transaction is requesting a lock on this resource that conflicts with the first lock. Type, blocking occurs. At this point, the blocked transaction will remain suspended until the transaction holding the lock gives up the locked resource. This article will show you how to use the corresponding dynamic performance view to view the blocking and how to solve the blocking.
Experimental environment of this article: Demonstration environment: DM Database Server x64 V7.1.6.46-Build(2018.02.08-89107)ENT
1. Create a test table and insert data
Build a table:
2. Generate TID lock on T1
Perform the update operation and do not submit, the specific operations are as follows:
3. Open a new session
3.1 Perform a select operation in a new session
It can be seen that due to the multi-version mechanism of MVCC, writing will not block reading, so the select operation can proceed normally. But the previous transaction was not committed, so the result of the check is still the value of the old version, which is the value before the update.
3.2 Perform DML operations in a new session
At this point, because the delete operation needs to add the same type of lock as the previous update operation, blocking occurs and the current transaction is suspended.
4. Check for blocking
When blocking occurs, we can check the state of the lock in the current database through the v$lock view
In the result, we can see that transaction 2399 is blocked, and the transaction blocking him is 2393.
Similarly, we can also find who is blocking whom through the V$TRXWAIT view,
Get the same result, the transaction with ID 2399 is waiting for the transaction with ID 2393, and the waiting time is 1071599 milliseconds.
Next, look for the sessions corresponding to the two transactions through the V$SESSIONS view
You can get the session ID corresponding to the two transactions and the currently executing SQL statement, and you can know which SQL statements are blocking.
5. Blocking solutions
According to requirements, there are two solutions.
5.1 Commit or roll back the blocking transaction.
Based on the above, we can see that the transaction session ID that caused the blocking is 2410147992. At this point, we only need to commit or roll back the transaction under this session, the lock will naturally be released and the blockage resolved.
5.2 Close the blocking session
Similarly, we can also use the system procedure SP_CLOSE_SESSION (SESS_ID) to close the corresponding session, the specific usage is as follows.
At this point, the lock is released and the delete operation can proceed smoothly.