A transaction holds exclusive row locks for all rows inserted, updated, or deleted
within the transaction. Because row locks are acquired at the highest degree of
restrictiveness, no lock conversion is required or performed.
Oracle automatically converts a table lock of lower restrictiveness to one of higher
restrictiveness as appropriate. For example, assume that a transaction uses a SELECT
statement with the FOR UPDATE clause to lock rows of a table. As a result, it acquires
the exclusive row locks and a row share table lock for the table. If the transaction later
updates one or more of the locked rows, the row share table lock is automatically
converted to a row exclusive table lock.
Lock escalation occurs when numerous locks are held at one level of granularity (for
example, rows) and a database raises the locks to a higher level of granularity (for
example, table). For example, if a single user locks many rows in a table, some
databases automatically escalate the user’s row locks to a single table. The number of
locks is reduced, but the restrictiveness of what is being locked is increased.
Oracle never escalates locks. Lock escalation greatly increases the likelihood of
deadlocks.Imagine the situation where the system is trying to escalate locks on behalf of
transaction T1 but cannot because of the locks held by transaction T2. A deadlock is
created if transaction T2 also requires lock escalation of the same data before it can
proceed.
锁的转化和锁级别的升级
1. 事务内进行DML操作时 , 将获得排他行锁 . 行锁是限制程度最高的锁
2. 对于表,Oracle 能够自动地将限制程度较低的锁转化为限制程度更高的锁
3. 锁升级是指处于同一粒度级别上的锁被数据库升级为更高粒度级别上的锁 .
锁的数量减少了, 但对锁定资源的限制程度增加了
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/10599713/viewspace-990400/ ,如需转载,请注明出处,否则将追究法律责任。