The locking characteristics of INSERT, UPDATE, DELETE, and SELECT ... FOR UPDATE
statements are as follows:
■ The transaction that contains a DML statement acquires exclusive row locks on the
rows modified by the statement. Other transactions cannot update or delete the
locked rows until the locking transaction either commits or rolls back.
■ The transaction that contains a DML statement does not need to acquire row locks
on any rows selected by a subquery or an implicit query, such as a query in a
WHERE clause. A subquery or implicit query in a DML statement is guaranteed to
be consistent as of the start of the query and does not see the effects of the DML
statement it is part of.
■ A query in a transaction can see the changes made by previous DML statements in
the same transaction, but cannot see the changes of other transactions begun after
its own transaction.
■ In addition to the necessary exclusive row locks, a transaction that contains a DML
statement acquires at least a row exclusive table lock on the table that contains the
affected rows. If the containing transaction already holds a share, share row
exclusive, or exclusive table lock for that table, the row exclusive table lock is not
acquired. If the containing transaction already holds a row share table lock, Oracle
automatically converts this lock to a row exclusive table lock.
NSERT,UPDATE,DELETE,及 SELECT ... FOR UPDATE 语句默认获取的锁
1. 包含 DML 语句的事务需要获得被其修改的数据行上的排他行级锁
2. 事务无需获取 DML 语句内的子查询或隐式查询所选择的行上的行级锁
3. 事务内的查询能够看到本事务内之前执行的 DML 语句对数据的修改,之后的无法看到
4. 事务内的 DML 语句除了需要获得必要的排他行级锁外,至少还需获得包含被修改数据行的表上
的行排他表级锁 . 如果事务已经获得了相关表上的行共享表级锁 ,Oracle 将自动地将此锁转换为行排
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10599713/viewspace-991301/，如需转载，请注明出处，否则将追究法律责任。