informix锁表问题（informix锁表问题）.doc
上传者：小健
2022-06-01 15:09:11上传
DOC文件
86 KB
Informix锁表问题(informix锁表问题)
The exception that occurs when using Informix: "could not do a order read to fetch next row”, specifically manifested in large data manipulation database, prone to physical. Find the solution to the problem:
On the one hand can make changes in the choice of isolation level (but not completely), on the other hand it is because the Informix default lock waiting time is 0, which is in operation (update, delete) database, if other operations are used in the same table when not wait and return abnormal.
The simplest solution is that each time you get a new (note that the new, original connection doesn't matter, but it affects efficiency), the database connection first executes the Sql that sets the connection lock waiting time:
SET LOCK MODE TO WAIT 10 (meaning set lock, wait time is 10ms),
This basically solves the problem and no more unusual conditions.
Sqlcode -244 deadlock resolution
Stop the Informix database
Onmode - KY
Start the Informix database
Oninit
This problem is usually caused by lock tables. Either multiple users access the database at the same time, leading to the problem, either because the resource is not released after a process has died. If this is the first case, consider locking level database table to row lock, to reduce the chance of colliding: or in the application program, using set lock mode wait 3 this statement, in the lock after waiting for several seconds and try again. If the latter is the case, you can find the command table lock process using onstat -g ses/onstat -g sql/onstat -k in the database, the end of the onmode process with the -z command: if not, you need to restart the database to release resources.
Method one
Onmode -u forces the database server into a single user mode to release the locked table. The production environment is not suitable.
Method two
1:$onstat -k grep HDR+X
HDR+X is the exclusive lock
HDR head
X mutex
Owner
Is the shared memory address of the thread that is ho
The exception that occurs when using Informix: "could not do a order read to fetch next row”, specifically manifested in large data manipulation database, prone to physical. Find the solution to the problem:
On the one hand can make changes in the choice of isolation level (but not completely), on the other hand it is because the Informix default lock waiting time is 0, which is in operation (update, delete) database, if other operations are used in the same table when not wait and return abnormal.
The simplest solution is that each time you get a new (note that the new, original connection doesn't matter, but it affects efficiency), the database connection first executes the Sql that sets the connection lock waiting time:
SET LOCK MODE TO WAIT 10 (meaning set lock, wait time is 10ms),
This basically solves the problem and no more unusual conditions.
Sqlcode -244 deadlock resolution
Stop the Informix database
Onmode - KY
Start the Informix database
Oninit
This problem is usually caused by lock tables. Either multiple users access the database at the same time, leading to the problem, either because the resource is not released after a process has died. If this is the first case, consider locking level database table to row lock, to reduce the chance of colliding: or in the application program, using set lock mode wait 3 this statement, in the lock after waiting for several seconds and try again. If the latter is the case, you can find the command table lock process using onstat -g ses/onstat -g sql/onstat -k in the database, the end of the onmode process with the -z command: if not, you need to restart the database to release resources.
Method one
Onmode -u forces the database server into a single user mode to release the locked table. The production environment is not suitable.
Method two
1:$onstat -k grep HDR+X
HDR+X is the exclusive lock
HDR head
X mutex
Owner
Is the shared memory address of the thread that is ho
informix锁表问题（informix锁表问题）
