First, the performance of deadlock
1. The error message is: The transaction (process ID) is deadlocked on the lock resource with another process and has been selected as the deadlock victim. Please rerun the transaction.
2. The error message is: The transaction (process ID) is deadlocked on the lock|communication buffer resource with another process and has been selected as the deadlock victim. Please rerun the transaction.
Second, the cause of deadlock
1. Due to the multi-user, multi-task concurrency and transaction integrity requirements, when multiple transactions access multiple resources at the same time, if both parties have locked some resources but also need the resources locked by the other party, they cannot If the required resources are fully obtained within a limited time, it will be in an infinite waiting state, resulting in a deadlock of its resource requirements.
2. The implementation method of the locking mechanism of the database itself is different, and each database system will also have its own special deadlock situation. For example, in Sybase SQL Server 11, the minimum lock is a 2K
page locking method, not a row-level lock. If a table has a small number of records and a short record length (that is, the record density is high, such as the system configuration table or system parameter table in the application system belongs to this type of table), the frequency of being accessed is high, and it is easy to display on this page. A deadlock occurs.
Performance 1:
A user A accesses table A (locks table A), and then accesses table B. Another user B accesses table B (locks table B) and
then attempts to access table A. At this time, because user B has locked table B, user A must wait for user B to release table B
before continuing. Similarly, user B must wait for user A to release table A before continuing to operate, thus causing a deadlock.
Solution:
This kind of deadlock is caused by the bug of the program, and the implementation logic of the program to the database layer needs to be adjusted. Carefully analyze the logic of the program:
(1) Try to avoid locking two resources at the same time.
(2) When two resources must be locked at the same time, it is necessary to ensure that the resources should be locked in the same order at any time.
Behavior 2:
User A reads a record, then modifies the record, and user B also modifies the record. Here, the nature of the lock in user A's transaction is changed from a shared lock to an exclusive lock (for update), while the exclusive lock in user B must wait for A to release the shared lock because A has a shared lock, and A because of B's exclusive lock The exclusive lock that cannot be raised cannot
release the shared lock, so a deadlock occurs. This kind of deadlock is relatively subtle, but it actually happens quite often in larger projects.
Solution:
Let user A's transaction (ie, read-before-write type of operation) use update lock when selecting.
The syntax is as follows: select * from table1 with(updlock) where ….
3. Common deadlock situations and solutions
1. Different stored procedures, triggers, and dynamic SQL statement segments access multiple tables at the same time in different orders.
When the system is implemented, it should be stipulated that in all stored procedures, triggers, and dynamic SQL statement segments, operations on multiple tables always use the same order. For example, there are two stored procedures procedure1 and procedure2, both of which need to access three tables table1, table2
and table3. If procedure1 is accessed in the order of table1, table2 and table3, then procedure2 should also access these three tables in the above order.
2. A table with frequent records is added during swap, but a non-clustered index is used on that table.
For tables that frequently add records during the exchange, use a clustered index (clustered) to reduce the number of users adding records to the last page of the table, resulting in hot spots at the end of the table, resulting in deadlocks. This type of table is mostly a running water table of current accounts, which is characterized by the need to append a large number of records to the end of the table during the exchange period, and no or less delete operations are performed on the added records.
3. There are few records in the table, and a single record is short, and the frequency of being accessed is high.
For tables with few records in a single table and frequent select or update during the exchange period, the method of setting the maximum row per page can be used to reduce the density of data stored in the table, simulate row-level locks, and reduce deadlocks on the table. A lock condition occurs. Most of these tables are tables with complex information and few records.
Such as: system configuration table or system parameter table. Add the following statement when defining the table: with max_rows_per_page=1
4. The frequency of accessing the entire table is high (such as querying the code comparison table, etc.).
In stored procedures, triggers, and dynamic SQL statement segments, if select operations on some entire tables are frequent, it may cause deadlock on
the table with other users who access the table. For non-critical statements such as checking whether the account exists, but the checked field will not be updated during the check, you can use the at isolation read uncommitted clause in the select command to solve the problem. This method actually lowers the lock level of the select statement on the entire table and improves the concurrency of other users'
operations . The effect of this method is particularly significant when the system is running under high load.
For example: select*from titles at isolation read uncommitted
5. For the serial number generator field such as serial number, you can first execute update serial number field + 1, and then execute
the method of select to obtain serial number to operate.
Remark:
NOLOCK (no lock): When this option is selected, SQL Server does not add any locks when reading or modifying data. In this case, the user may read the data in the Uncommitted Transaction or Roll Back, the so-called "dirty data".
UPDLOCK (modification lock): When this option is selected, SQL Server uses a modification lock instead of a shared lock when reading data, and holds this lock until the end of the entire transaction or command. Using this option ensures that multiple processes can read data at the same time but only this process can modify the data.
http://blog.csdn.net/hexieshangwang/article/details/47189213