In the database application system of online transaction processing (OLTP), the concurrency of multi-user and multi-task is one of the most important technical indicators of the system. In order to improve concurrency, most RDBMSs currently use locking technology. However, due to the complexity of the real environment, the use of locking technology inevitably produces deadlock problems. Therefore, how to use locking technology reasonably and effectively and minimize deadlock is the key to developing online transaction processing system.
Causes of Deadlock
In the online transaction processing system, there are two main reasons for the deadlock. On the one hand, 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 of the resources but also need the resources locked by the other party, they cannot. When the required resources are fully obtained in a limited time, it will be in an infinite waiting state, resulting in a deadlock of its resource requirements.
On the other hand, the implementation methods of the locking mechanism of the database itself are 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.
Several situations that are prone to deadlocks are as follows:
1> Different stored procedures, triggers, and dynamic SQL statement segments access multiple tables at the same time in different orders;
2> During the exchange period, a table with frequent records is added, but on this table A non-clustered index is used;
3> There are few records in the table, and a single record is short, and the frequency of access is high;
4> The frequency of access to the entire table is high (such as the query of the code comparison table, etc. ).
The corresponding handling methods for the above deadlock situations are as follows:
1> When implementing the system, 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 proc1 and proc2, both of which need to access three tables zltab, z2tab and z3tab. If proc1 is accessed in the order of zltab, z2tab and z3tab, then proc2 should also access these three tables in the above order.
2> For tables with frequent records added during the exchange period, 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> For tables with not too many records in a single table and frequent select or updata 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 the number of rows in the table. A deadlock situation 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
In stored procedures, triggers, and dynamic SQL statement segments, if select operations are performed frequently on some entire tables, the table may be associated with other users accessing the table. User generates deadlock. For non-critical statements such as checking whether the account exists, but the checked fields will not be updated during the checking, you can use the at isolation read uncommitted clause in the select command to solve the problem. This method actually reduces the lock level of the select statement on the entire table and improves the concurrency of other users' operations on the table. The effect of this method is particularly significant when the system is running under high load.
Such as:
select * from titles at isolation read uncommitted
For serial number generator fields such as serial numbers, you can first execute the updata serial number field + 1, and then execute the method of select to obtain the serial number to operate.
http://www.blogjava.net/imdosop/archive/2008/11/06/239085.html
Analysis and Solution of Database Lock Table
The reasons and solutions for memory overflow are described above. Next, we will introduce the reasons and solutions for database lock tables and blocking.
Like the operating system, the database is a shared resource used by multiple users. When multiple users access data concurrently, there will be multiple transactions accessing the same data at the same time in the database. Without control over concurrent operations, incorrect data may be read and stored, breaking database consistency. Locking is a very important technology for implementing database concurrency control. Lock-related exceptions are often encountered in practical applications. When two transactions require a set of conflicting locks and cannot continue the transaction, a deadlock will occur, which seriously affects the normal execution of the application.
There are two basic types of locks in the database: exclusive locks (Exclusive Locks, namely X locks) and shared locks (Share Locks, namely S locks). When an exclusive lock is added to a data object, other transactions cannot read or modify it. Data objects with shared locks can be read by other transactions, but cannot be modified. The database uses these two basic lock types to control the concurrency of database transactions.
The first case of deadlock
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; then Since user A has locked table B, user A must wait for user B to release table B before it can continue. Similarly, user B can continue to wait for user A to release table A, which leads to a deadlock.
Solution:
This kind of deadlock is relatively common and is caused by a bug in the program. There is no other way except to adjust the logic of the program. Carefully analyze the logic of the program. When operating on multiple tables in the database, try to process them in the same order, and try to avoid locking two resources at the same time. For example, when operating two tables, A and B are always processed in the order of A and then B. , when two resources must be locked at the same time, ensure that the resources should be locked in the same order at all times.
Second case of deadlock
User A queries a record and then modifies the record; at this time, user B modifies the record. At this time, the nature of the lock in user A's transaction is increased from the shared lock of the query to the exclusive lock, and the exclusive lock in user B is due to A has a shared lock, so it must wait for A to release the shared lock, and the exclusive lock that A cannot raise due to the exclusive lock of B cannot release the shared lock, so a deadlock occurs. This kind of deadlock is relatively subtle, but often occurs in larger projects. For example, in a certain project, after the button on the page is clicked, the button is not immediately invalid, so that the user will quickly click the same button multiple times, so that the same piece of code performs multiple operations on the same record in the database, and this kind of death is easy to occur. lock situation.
Solution:
1. For controls such as buttons, it will be invalid immediately after clicking, and users will not be allowed to click repeatedly to avoid operations on the same record at the same time.
2. Use optimistic locking for control. Optimistic locking is mostly implemented based on the data version (Version) recording mechanism. That is to add a version identifier to the data. In the version solution based on the database table, it is generally realized by adding a "version" field to the database table. When reading data, read out this version number together, and add one to this version number when updating later. At this time, the version data of the submitted data is compared with the current version information of the corresponding records in the database table. If the version number of the submitted data is greater than the current version number of the database table, it will be updated; otherwise, it is considered to be expired data. The optimistic locking mechanism avoids the database locking overhead in long transactions (user A and user B do not lock database data during the operation), and greatly improves the overall performance of the system under large concurrency. Hibernate has an optimistic locking implementation built into its data access engine. It should be noted that since the optimistic locking mechanism is implemented in our system, user update operations from external systems are not controlled by our system, so dirty data may be updated to the database.
3. Use pessimistic locking for control. In most cases, pessimistic locking relies on the locking mechanism of the database, such as Oracle's Select ... for update statement, to ensure maximum exclusivity of operations. But with it comes a lot of overhead in database performance, especially for long transactions, which is often unbearable. For example, in a financial system, when an operator reads the user's data and makes modifications on the basis of the read user data (such as changing the user's account balance), if the pessimistic locking mechanism is adopted, it means the entire operation process. (the whole process from the operator reading the data, starting the modification until submitting the modification result, and even including the time when the operator goes to brew coffee halfway), the database records are always in a locked state. Concurrency, such a situation will lead to catastrophic consequences. Therefore, it must be carefully considered when using pessimistic locking for control.
The third case of deadlock
If an update statement that does not meet the conditions is executed in a transaction, a full table scan is performed, and row-level locks are raised to table-level locks. After multiple such transactions are executed, it is easy to cause deadlock. lock and block. In a similar situation, when the amount of data in the table is very large and the index is too small or inappropriate, full table scans often occur, and eventually the application system will become slower and slower, and eventually blocking or deadlock will occur.
Solution:
Do not use too complicated queries related to multiple tables in the SQL statement; use the "execution plan" to analyze the SQL statement, and establish the corresponding index for optimization for the SQL statement with full table scan.
5. Summary
Generally speaking, the occurrence of memory overflow and lock table is caused by poorly written code, so improving the quality of the code is the most fundamental solution. Some people think that the function is implemented first, and when there is a bug, it is corrected in the testing phase. This idea is wrong. Just as the quality of a product is determined during the manufacturing process, not during quality testing, the quality of software is determined during the design and coding stages, and testing is only a verification of software quality, because testing is impossible Find all bugs in the software.
Lock table processing steps:
1. onstat -ks|grep HDR+X //The query is which table is locked
address wtlist owner lklist type tblsnum rowid key#/bsiz
c1809510 0 d656e774 c181cb3c HDR+X 6002e1 2c602 0
You need to pay attention to the lklist and type items. From the above, the table with tblsnum of 6002e1 (6292193 hexadecimal converted to decimal) is locked. The table that can be re-queried is that the table is locked:
dbaccess ：select * from systables where partnum='6292193'得到
tabname basetab_mvpn
owner smpmml
partnum 6292193
tabid 12813
rowsize 464
ncols 61
nindexes 1
nrows 2984
created 12/10/2002
version 839843846
tabtype T
locklevel R
npused 746
fextsize 16
nextsize 16
flags 0
2. Onstat -u, find out the thread whose owner(address) is d656e774
address flags sessid user tty wait tout locks nreads nwrites
d656e774 Y--P--- 4261 smp20 - d6ad2330 0 180 99620 16
3. Onstat -g sql d656e774 can print out the sql statement executed by this thread.
4. Just use the informix user to execute onmode-z sessid to kill the thread
onmode-z 4261
Important note: onstat -g ses sessid find a process PID, then ps -ef|grep Pid; kill -9 pid
will encounter table locks when dealing with these problems because the thread has not finished executing, at this time Can't simply onmode -z kill threads
Reprinted from: https://www.cnblogs.com/SuperXJ/archive/2012/03/08/2384753.html