这里记录下来所想到的问题：
1. locklist的大小需要重新调整了，因为在32位环境下和64位环境下一个锁所占用的内存资源大小不一样，所以同样的locklist大小在32位下可以锁500万行的数据，但是在64位下可能只有300万这样；
locklist - Maximum storage for lock list configuration
parameter
On
all platforms, each lock requires 128 or 256 bytes of the lock list,
depending on whether other locks are held on the object:
- 256 bytes are required to hold a lock on an object that has no
other locks held on it
- 128 bytes are required to record a lock on an object that has
an existing lock held on it.
When the percentage of the lock list used by one application
reaches
maxlocks, the database manager will perform lock escalation,
from row to table, for the locks held by the application.
![Start of change]()
This calculation is an approximation, assuming shared locks only.
The percentage of the lock list used is calculated by multiplying
the number of locks held by the application by the value required
to hold a lock on an object that has other locks held on it.
![End of change]()
Although
the escalation process itself does not take much time, locking entire
tables (versus individual rows) decreases concurrency, and overall
database performance might decrease for subsequent accesses against
the affected tables. Suggestions of how to control the size of the
lock list are:
- Perform frequent COMMITs to release locks.
- When performing many updates, lock the entire table before updating
(using the SQL LOCK TABLE statement). This will use only one lock,
keeps others from interfering with the updates, but does reduce concurrency
of the data.
You can also use the LOCKSIZE option of the ALTER
TABLE statement to control how locking is done for a specific table.
Use
of the Repeatable Read isolation level might result in an automatic
table lock.
- Use the Cursor Stability isolation level when possible to decrease
the number of share locks held. If application integrity requirements
are not compromised use Uncommitted Read instead of Cursor Stability
to further decrease the amount of locking.
- Set
locklist to AUTOMATIC. The lock
list will increase synchronously to avoid lock escalation or a lock
list full situation.
Once the lock list is full, performance
can degrade since lock escalation will generate more table locks and
fewer row locks, thus reducing concurrency on shared objects in the
database. Additionally there might be more deadlocks between applications
(since they are all waiting on a limited number of table locks), which
will result in transactions being rolled back. Your application will
receive an SQLCODE of -912 when the maximum number of lock requests
has been reached for the database.
阅读(1602) | 评论(0) | 转发(0) |
