隔离级别(isolation
level
)
两个并发事务同时访问数据库表相同的行时,可能存在以下三个问题:
1、幻想读
:事务T1读取一条指定where条件的语句,返回结果集。此时事务T2插入一行新记录,恰好满足T1的where条件。然后T1使用相同的条件再次查询,结果集中可以看到T2插入的记录,这条新纪录就是幻想。
2、不可重复读取
:事务T1读取一行记录,紧接着事务T2修改了T1刚刚读取的记录,然后T1再次查询,发现与第一次读取的记录不同,这称为不可重复读。
3、脏读
:事务T1更新了一行记录,还未提交所做的修改,这个T2读取了更新后的数据,然后T1执行回滚操作,取消刚才的修改,所以T2所读取的行就无效,也就是脏数据。
l
隔离级别定义了事务与事务之间的隔离程度。
l
隔离级别与并发性是互为矛盾的:隔离程度越高,数据库的并发性越差;隔离程度越低,数据库的并发性越好。
l
ANSI/ISO SQL92
标准定义了一些数据库操作的隔离级别:
l
未提交读(read
uncommitted
)
l
提交读(read committed
)
l
重复读(repeatable read
)
l
序列化(serializable
)
l
通过一些现象,可以反映出隔离级别的效果。这些现象有:
l
更新丢失(lost update
):当系统允许两个事务同时更新同一数据是,发生更新丢失。
l
脏读(dirty read
):当一个事务读取另一个事务尚未提交的修改时,产生脏读。
l
非重复读(nonrepeatable
read
):同一查询在同一事务中多次进行,由于其他提交事务所做的修改或删除,每次返回不同的结果集,此时发生非重复读。(A transaction rereads data it has previously read and finds that
another committed transaction has modified or deleted the data. )
l
幻像(phantom read
):同一查询在同一事务中多次进行,由于其他提交事务所做的插入操作,每次返回不同的结果集,此时发生幻像读。(A transaction reexecutes a query returning a set of rows that
satisfies a search condition and finds that another committed transaction has inserted
additional rows that satisfy the condition. )
l
下面是隔离级别及其对应的可能出现或不可能出现的现象
|
Dirty Read
|
NonRepeatable
Read
|
Phantom Read
|
Read uncommitted
|
Possible
|
Possible
|
Possible
|
Read committed
|
Not possible
|
Possible
|
Possible
|
Repeatable read
|
Not possible
|
Not possible
|
Possible
|
Serializable
|
Not possible
|
Not possible
|
Not possible
|
ORACLE
的隔离级别
l
ORACLE
提供了SQL92
标准中的read
committed
和serializable
,同时提供了非SQL92
标准的read-only
。
l
read committed
:
l
这是ORACLE
缺省的事务隔离级别。
l
事务中的每一条语句都遵从语句级的读一致性。
l
保证不会脏读;但可能出现非重复读和幻像。
l
serializable
:
l
简单地说,serializable
就是使事务看起来象是一个接着一个地顺序地执行。
l
仅仅能看见在本事务开始前由其它事务提交的更改和在本事务中所做的更改。
l
保证不会出现非重复读和幻像。
l
Serializable
隔离级别提供了read-only
事务所提供的读一致性(事务级的读一致性),同时又允许DML
操作。
l
如果有在serializable
事务开始时未提交的事务在serializable
事务结束之前修改了serializable
事务将要修改的行并进行了提交,则serializable
事务不会读到这些变更,因此发生无法序列化访问的错误。(换一种解释方法:只要在serializable
事务开始到结束之间有其他事务对serializable
事务要修改的东西进行了修改并提交了修改,则发生无法序列化访问的错误。)
l
If a serializable
transaction contains data manipulation language (DML) that attempts to update
any resource that may have been updated in a transaction uncommitted at the
start of the serializable transaction,
(并且修改在后来被提交而没有回滚),then the DML statement fails.
返回的错误是ORA-08177:
Cannot serialize access for this transaction
。
l
ORACLE
在数据块中记录最近对数据行执行修改操作的N
个事务
的信息,目的是确定是否有在本事务开始时未提交的事务修改了本事务将要修改的行。具体见英文:Oracle permits a serializable transaction to modify a data row only
if it can determine that prior changes to the row were made by transactions
that had committed when the serializable transaction began. To make this
determination efficiently, Oracle uses control information stored in the data
block that indicates which rows in the block contain committed and uncommitted
changes. In a sense, the block contains a recent history of transactions that
affected each row in the block. The amount of history that is retained is
controlled by the INITRANS parameter of CREATE TABLE and ALTER TABLE. Under
some circumstances, Oracle may have insufficient history information to
determine whether a row has been updated by a "too recent"
transaction. This can occur when many transactions concurrently modify the same
data block, or do so in a very short period. You can avoid this situation by
setting higher values of INITRANS for tables that will experience many
transactions updating the same blocks. Doing so will enable Oracle to allocate
sufficient storage in each block to record the history of recent transactions
that accessed the block.
l
The INITRANS Parameter
:Oracle stores control information in
each data block to manage access by concurrent transactions. Therefore, if you
set the transaction isolation level to serializable, you must use the ALTER
TABLE command to set INITRANS to at least 3. This parameter will cause Oracle
to allocate sufficient storage in each block to record the history of recent
transactions that accessed the block. Higher values should be used for tables
that will undergo many transactions updating the same blocks.
l
read-only
:
l
遵从事务级的读一致性,仅仅能看见在本事务开始前由其它事务提交的更改。
l
不允许在本事务中进行DML
操作。
l
read only
是serializable
的子集。它们都避免了非重复读和幻像。区别是在read only
中是只读;而在serializable
中可以进行DML
操作。
l
Export with CONSISTENT =
Y sets the transaction to read-only.
l
read committed
和serializable
的区别和联系:
l
事务1
先于事务2
开始,并保持未提交状态。事务2
想要修改正被事务1
修改的行。事务2
等待。如果事务1
回滚,则事务2
(不论是read committed
还是serializable
方式)进行它想要做的修改。如果事务1
提交,则当事务2
是read committed
方式时,进行它想要做的修改;当事务2
是serializable
方式时,失败并报错“Cannot serialize access
”,因为事务2
看不见事务1
提交的修改,且事务2
想在事务一修改的基础上再做修改
。具体见英文:Both read committed and serializable transactions use row-level
locking, and both will wait if they try to change a row updated by an
uncommitted concurrent transaction. The second transaction that tries to update
a given row waits for the other transaction to commit or roll back and release
its lock. If that other transaction rolls back, the waiting transaction
(regardless of its isolation mode) can proceed to change the previously locked
row, as if the other transaction had not existed. However, if the other
(blocking) transaction commits and releases its locks, a read committed
transaction proceeds with its intended update. A serializable transaction,
however, fails with the error "Cannot serialize access", because the
other transaction has committed a change that was made since the serializable
transaction began.
l
read committed
和serializable
可以在ORACLE
并行服务器中使用。
l
关于SET TRANSACTION
READ WRITE
:read write
和read
committed
应该是一样的。在读方面,它们都避免了脏读,但都无法实现重复读。虽然没有文档说明read
write
在写方面与read committed
一致,但显然它在写的时候会加排他锁以避免更新丢失。在加锁的过程中,如果遇到待锁定资源无法锁定,应该是等待而不是放弃。这与read committed
一致。
l
语句级的读一致性
l
ORACLE
保证语句级的读一致性,即一个语句所处理的数据集是在单一时间点上的数据集,这个时间点是这个语句开始的时间。
l
一个语句看不见在它开始执行后提交的修改。
l
对于DML
语句,它看不见由自己所做的修改,即DML
语句看见的是它本身开始执行以前存在的数据。
l
事务级的读一致性
l
事务级的读一致性保证了可重复读,并保证不会出现幻像。
l
设置隔离级别
l
设置一个事务的隔离级别
l
SET TRANSACTION ISOLATION
LEVEL READ COMMITTED;
l
SET TRANSACTION ISOLATION
LEVEL SERIALIZABLE;
l
SET TRANSACTION READ
ONLY;
l
设置增个会话的隔离级别
l
ALTER SESSION SET
ISOLATION_LEVEL SERIALIZABLE;
l
ALTER SESSION SET
ISOLATION_LEVEL READ COMMITTED;
==================================
作者联系方式
:
E
TaoPuyin
G
System
Engineer Oracle DBA
G
Fuji
Xerox China Limited (Shanghai)
分享到:
相关推荐
Oracle数据库的隔离级别是确保多用户环境下数据一致性、避免并发问题的关键机制。隔离级别定义了不同事务在执行过程中如何处理数据的可见性和并发操作。根据ANSI/ISO SQL92标准,有四种主要的隔离级别: 1. **未...
Oracle数据库的事务隔离级别是确保数据一致性的重要机制,它决定了在一个事务执行期间,与其他并行事务的交互方式。事务隔离级别主要解决并发操作时可能出现的三个问题:幻读(Phantom Read)、不可重复读(Non-...
Oracle 数据库隔离级别是数据库事务处理中的核心概念,它决定了事务在并发环境下如何访问和处理数据,以确保数据的一致性和完整性。隔离级别主要解决的是并发操作中的脏读、不可重复读和幻读问题。 脏读(Dirty ...
二、Oracle隔离级别 1. **读未提交(Read Uncommitted)**:最低隔离级别,事务可以看到其他事务未提交的修改,可能导致脏读、不可重复读和幻读。 2. **读已提交(Read Committed)**:Oracle的默认隔离级别,每个...
介绍数据库事务的四种隔离级别,比较不同隔离级别的区别和影响
数据库事务的四种隔离级别的特点描述,他们的使用热度,以及各种锁在隔离级别下的释放时机。
数据库事务和隔离级别
Oracle隔离机制是数据库管理系统中确保事务之间相互独立和数据一致性的关键特性。它涉及到如何处理并发事务中的数据读取和修改,以防止出现脏读、不可重复读和幻读等并发问题。在Oracle中,提供了三种不同的隔离级别...
Spring 框架提供了一套完善的事务管理机制,其中包含了多种事务传播属性和事务隔离级别。这些特性使得在处理数据库操作时,能够更好地控制事务的边界和行为,从而确保数据的一致性和完整性。 首先,我们来看一下...
### 数据库事务隔离级别详解 ...例如,MySQL默认使用Repeatable Read作为隔离级别,而Oracle则默认使用Read Committed。每种隔离级别都有其适用场景,合理设置可以帮助开发者更好地管理数据的一致性和系统的性能。
数据库事务隔离级别和锁机制是确保数据库并发操作正确性和一致性的关键组成部分。在数据库系统中,尤其是大型企业级应用,多个用户可能同时访问和修改相同的数据,因此并发控制显得尤为重要。 事务的四个基本特征...
- Oracle数据库的默认隔离级别。 **3.1.3 Repeatable Read (可重复读)** - 可以防止脏读和不可重复读,但仍然可能发生幻读。 - MySQL的默认隔离级别。 **3.1.4 Serializable (串行化)** - 最高的隔离级别,可以...
Mysql的默认事务隔离级别是可重复读,而Oracle的默认事务隔离级别是读已提交。 事务隔离要解决的问题 -------------------- 事务隔离要解决的问题有三个:脏读、不可重复读和幻读。 * 脏读(Dirty Read):一个...