13 Data Concurrency and Consistency

001 This chapter explains how Oracle maintains consistent data in a multiuser database environment.
　		 本章讲述 Oracle 如何在多用户数据库系统中保证数据一致性（consistent）。
　
002 This chapter contains the following topics: 本章包含以下主题：
003

Introduction to Data Concurrency and Consistency in a Multiuser Environment

13.1 多用户环境下的数据并发访问及数据一致性简介
004 In a single-user database, the user can modify data in the database without concern for other users modifying the same data at the same time. However, in a multiuser database, the statements within multiple simultaneous transactions can update the same data. Transactions executing at the same time need to produce meaningful and consistent results. Therefore, control of data concurrency and data consistency is vital in a multiuser database.
  • Data concurrency means that many users can access data at the same time.
  • Data consistency means that each user sees a consistent view of the data, including visible changes made by the user's own transactions and transactions of other users.
 在只有单一用户的数据库中，用户可以任意修改数据，而无需考虑同时有其他用户正在修改相同的数据。但在一个多用户数据库中，多个并发事务中包含的语句可能 会修改相同的数据。数据库中并发执行的事务最终应产生有意义且具备一致性的结果。因此在多用户数据库中，对数据并发访问（data concurrency）及数据一致性（data consistency）进行控制是两项极为重要的工作。
  • 数据并发访问指多用户同时访问相同的数据。
  • 数据一致性指系统中每个用户都能够取得具备一致性的数据，同时还能够看到自己或其他用户所提交的事务对数据的修改。
005 To describe consistent transaction behavior when transactions run at the same time, database researchers have defined a transaction isolation model called serializability. The serializable mode of transaction behavior tries to ensure that transactions run in such a way that they appear to be executed one at a time, or serially, rather than concurrently.
　		 为了描述同时执行的多个事务如何实现数据一致性，数据库研究人员定义了被称为串行化处理（serializability）的事务隔离模型（transaction isolation model）。当所有事务都采取串行化的模式执行时，我们可以认为同一时间只有一个事务在运行（串行的），而非并发的。
　
006 While this degree of isolation between transactions is generally desirable, running many applications in this mode can seriously compromise application throughput. Complete isolation of concurrently running transactions could mean that one transaction cannot perform an insert into a table being queried by another transaction. In short, real-world considerations usually require a compromise between perfect transaction isolation and performance.
　		 以串行化模式对事务进行隔离的效果很好，但在此种模式下应用程序的效率将大大降低。将并行执行的事务完全隔离意味着即便当前只存在一个对表进行查询（query）的事务，其他事务 也不能再对此表进行插入（insert）操作了。总之，为了满足实际要求，我们需要在事务的隔离程度与应用的性能之间找出一个平衡点。
　
007 Oracle offers two isolation levels, providing application developers with operational modes that preserve consistency and provide high performance.
　		 Oracle 支持两种事务隔离级别（isolation level），使应用程序开发者在对事务进行控制时，既能保证数据的一致性，又能获得良好的性能。
　
008

See Also:

Chapter 21, "Data Integrity" for information about data integrity, which enforces business rules associated with a database
另见：

第 21 章，“数据完整性” 了解数据完整性（data integrity）如何确保数据符合业务规则
009

Preventable Phenomena and Transaction Isolation Levels

13.1.1 需要防止的现象和事务隔离级别
010 The ANSI/ISO SQL standard (SQL92) defines four levels of transaction isolation with differing degrees of impact on transaction processing throughput. These isolation levels are defined in terms of three phenomena that must be prevented between concurrently executing transactions.
　		 ANSI/ISO SQL 标准（SQL92）定义了四种事务隔离级别（transaction isolation level），这四种隔离级别所能提供的事务处理能力各不相同。这些事务隔离级别是针对三种现象定义的，在并发事务执行时，需要阻止这三种现象 中的一种或多种发生。
　
011 The three preventable phenomena are:
  • Dirty reads: A transaction reads data that has been written by another transaction that has not been committed yet.
  • Nonrepeatable (fuzzy) reads: A transaction rereads data it has previously read and finds that another committed transaction has modified or deleted the data.
  • Phantom reads (or phantoms): A transaction re-runs 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.
 三种需要阻止的现象（preventable phenomena）是：
  • 脏读取（dirty read）：一个事务读取了被其他事务写入但还未提交的数据。
  • 不可重复读取（nonrepeatable read）：一个事务再次读取其之前曾经读取过的数据时，发现数据已被其他已提交的事务修改或删除。
  • 不存在读取（phantom read）：事务按照之前的条件重新查询时，返回的结果集中包含其他已提交事务插入的满足条件的新数据。
012 SQL92 defines four levels of isolation in terms of the phenomena a transaction running at a particular isolation level is permitted to experience. They are shown in Table 13-1:
　		 SQL92 标准中定义了四个隔离级别，在各隔离级别中，允许发生上述三种需要阻止的现象中的一种或多种。详细情况见表13-1：
　
013 Table 13-1 Preventable Read Phenomena by Isolation Level
　		 表13-1 各隔离级别中允许出现的需要防止的读取现象
　
014
Isolation Level 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
　
           现象 脏读取 不可重复读取 不存在读取
隔离级别
未提交读取（read uncommitted）
　		 允许 允许 允许
已提交读取（read committed）
　		 不允许
　		 允许 允许
可重复读取（repeatable read）
　		 不允许
　		 不允许 允许
串行化（rerializable）
　		 不允许
　		 不允许 不允许
　
015 Oracle offers the read committed and serializable isolation levels, as well as a read-only mode that is not part of SQL92. Read committed is the default.
　		 Oracle 支持三种事务隔离级别：已提交读取，串行化，以及 SQL92 中没有包含的只读模式（read-only mode）。已提交读取是 Oracle 默认使用的事务隔离级别。
　
016
See Also:

"How Oracle Manages Data Concurrency and Consistency" for a full discussion of read committed and serializable isolation levels
另见：

“Oracle 如何管理数据并发访问及数据一致性”详细了解已提交读取及串行化两种事务隔离级别
017

Overview of Locking Mechanisms

13.1.2 锁机制概述
018 In general, multiuser databases use some form of data locking to solve the problems associated with data concurrency, consistency, and integrity. Locks are mechanisms that prevent destructive interaction between transactions accessing the same resource.
　		 通常，多用户数据库需要利用锁机制解决数据并发访问，数据一致性及完整性问题。锁（lock）是一种防止多个事务访问同一资源时产生破坏性的相互影响的机制。
　
019 Resources include two general types of objects:
  • User objects, such as tables and rows (structures and data)
  • System objects not visible to users, such as shared data structures in the memory and data dictionary rows
 前面提到的资源（resource）大致可以分为两类：
  • 用户对象，例如表及数据行（即数据结构及其中的数据）
  • 对用户不可见的系统对象，例如内存中的共享数据结构（shared data structure）数据字典中的信息
020
See Also:

"How Oracle Locks Data" for more information about locks
另见：

“Oracle 如何锁数据”了解更多关于锁的信息
021

How Oracle Manages Data Concurrency and Consistency

13.2 Oracle 如何管理数据并发访问及数据一致性
022 Oracle maintains data consistency in a multiuser environment by using a multiversion consistency model and various types of locks and transactions. The following topics are discussed in this section: Oracle 利用多版本一致性模型（multiversion consistency model），各种类型的锁（lock）及事务（transaction）来管理多用户系统中的数据一致性（data consistency）。本节讨论以下主题：
023

Multiversion Concurrency Control

13.2.1 多版本并发访问控制
024 Oracle automatically provides read consistency to a query so that all the data that the query sees comes from a single point in time (statement-level read consistency). Oracle can also provide read consistency to all of the queries in a transaction (transaction-level read consistency).
　		 Oracle 能够自动地实现一个查询的读一致性（read consistency），即一个查询所获得的数据来自同一时间点（single point in time）（这也被称为语句级读一致性（statement-level read consistency））。Oracle 还能令一个事务内的所有查询都具备读一致性（即事务级读一致性（transaction-level read consistency））。
　
025 Oracle uses the information maintained in its rollback segments to provide these consistent views. The rollback segments contain the old values of data that have been changed by uncommitted or recently committed transactions. Figure 13-1 shows how Oracle provides statement-level read consistency using data in rollback segments.
　		 Oracle 利用回滚段（rollback segment）中的信息生成一个能保证一致性的数据视图。回滚段内保存了未提交或最近提交的事务中所修改数据的原值。图13-1 展示了 Oracle 如何利用回滚段实现语句级的读一致性。
　
026 Figure 13-1 Transactions and Read Consistency
　		 图13-1 事务及读一致性
027


　


　
028 As a query enters the execution stage, the current system change number (SCN) is determined. In Figure 13-1, this system change number is 10023. As data blocks are read on behalf of the query, only blocks written with the observed SCN are used. Blocks with changed data (more recent SCNs) are reconstructed from data in the rollback segments, and the reconstructed data is returned for the query. Therefore, each query returns all committed data with respect to the SCN recorded at the time that query execution began. Changes of other transactions that occur during a query's execution are not observed, guaranteeing that consistent data is returned for each query.
　		 在查询开始执行时，将记录当前的系统变化编号（system change number，SCN）。在 图13-1 中，记录的系统变化编号为 10023。当查询进行扫描时，只会使用有效的（observed）数据块。如果某个数据块内的数据被修改过（即数据块的 SCN 晚于查询开始执行时记录的 SCN），Oracle 将使用回滚段中的信息重建此数据块，并以重建的数据块替代被修改的数据块供查询使用。因此，查询的结果集只包含查询开始执行时就已经提交的数据。在查询执行时，其他事务修改的数据对此查询来说是无效的，这保证了每个查询都能 得到满足一致性的数据。
　
029

Statement-Level Read Consistency

13.2.2 语句级读一致性
030 Oracle always enforces statement-level read consistency. This guarantees that all the data returned by a single query comes from a single point in time—the time that the query began. Therefore, a query never sees dirty data or any of the changes made by transactions that commit during query execution. As query execution proceeds, only data committed before the query began is visible to the query. The query does not see changes committed after statement execution begins.
　		 Oracle 强制实现语句级读一致性（statement-level read consistency）。这保证了单一查询的结果集来自一个时间点——即查询开始执行的时间。因此，一个查询的结果集永远不会包含脏数据及此查询执行时其他事务提交的数据。在一个查询执行期间，只有在查询执行前提交的数据对此查询才是可见的。查询无法看到其开始执行后提交的数据。
　
031 A consistent result set is provided for every query, guaranteeing data consistency, with no action on the user's part. The SQL statements SELECT, INSERT with a subquery, UPDATE, and DELETE all query data, either explicitly or implicitly, and all return consistent data. Each of these statements uses a query to determine which data it will affect (SELECT, INSERT, UPDATE, or DELETE, respectively).
　		 任何一个查询都能得到满足一致性的结果集，这保证了用户无需额外操作就能确保数据一致性。SELECT，使用子查询的 INSERT，及包含显式或隐式查询的 UPDATE 或 DELETE 语句，都能够保证数据一致性。上述语句通过一个查询（query）来得到她们所需的满足一致性的结果集（分别使用 SELECT，INSERT，UPDATE 或 DELETE 语句）。
　
032 A SELECT statement is an explicit query and can have nested queries or a join operation. An INSERT statement can use nested queries. UPDATE and DELETE statements can use WHERE clauses or subqueries to affect only some rows in a table rather than all rows.
　		 SELECT 语句是一个显式地查询，且其中可以包含嵌套查询（nested query）或连接操作（join operation）。INSERT 语句中也能够使用嵌套查询。UPDATE 及 DELETE 语句能够利用 WHERE 子句或子查询进行限制，只操作数据表内的部分数据行。
　
033 Queries used in INSERT, UPDATE, and DELETE statements are guaranteed a consistent set of results. However, they do not see the changes made by the DML statement itself. In other words, the query in these operations sees data as it existed before the operation began to make changes.
　		 INSERT，UPDATE，及 DELETE 语句中包含的查询能够获得一致性的结果集。这些查询无法看到其所在 DML 语句对数据的修改。换句话说，这些查询只能看到其所在 DML 语句开始之前的数据。
　
034
Note:

If a SELECT list contains a function, then the database applies statement-level read consistency at the statement level for SQL run within the PL/SQL function code, rather than at the parent SQL level. For example, a function could access a table whose data is changed and committed by another user. For each execution of the SELECT in the function, a new read consistent snapshot is established.
提示：

如果 SELECT 列表中存在 PL/SQL 函数，那么函数中包含的 SQL 语句将遵从其自身的语句级读一致性，而非其所在 SQL 的读一致性。例如，SELECT 语句中的某个函数访问的表可能会在语句执行时被其他事务修改并提交。此函数每次执行时都将建立一个新的一致性视图（snapshot）。
035

Transaction-Level Read Consistency

13.2.3 事务级读一致性
036 Oracle also offers the option of enforcing transaction-level read consistency. When a transaction runs in serializable mode, all data accesses reflect the state of the database as of the time the transaction began. This means that the data seen by all queries within the same transaction is consistent with respect to a single point in time, except that queries made by a serializable transaction do see changes made by the transaction itself. Transaction-level read consistency produces repeatable reads and does not expose a query to phantoms.
　		 Oracle 还能够实现事务级读一致性（transaction-level read consistency）。当一个事务运行在串行化模式（serializable mode）下时，则事务内所有数据访问均反映的是事务开始时的数据状态。即事务内的所有查询对某个时间点来说具备一致性，但是运行在串行化模式下的事务能够看到事务自身对数据所作的修改。事务级的读一致性能够保证可重复读取（repeatable read）并可阻止出现不存在读取（phantom read）。
　
037

Read Consistency with Real Application Clusters

13.2.4 RAC 环境下的读一致性
038 Real Application Clusters (RAC) use a cache-to-cache block transfer mechanism known as Cache Fusion to transfer read-consistent images of blocks from one instance to another. RAC does this using high speed, low latency interconnects to satisfy remote requests for data blocks.
　		 RAC 系统采用缓存对缓存（cache-to-cache）的数据块传输机制（此技术被称为 Cache Fusion）在实例间传输满足读一致性（read-consistent）的数据块镜像。RAC 系统通过高速度低延迟的内部连接（interconnect）实现上述数据传输，从而满足实例之间对数据块的请求。
　
039
See Also:

Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide
另见：

Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide
040

Oracle Isolation Levels

13.2.5 Oracle 事务隔离级别
041 Oracle provides these transaction isolation levels.
　		 Oracle 支持以下三种事务隔离级别（transaction isolation level）。
　
042
Isolation Level Description
Read committed This is the default transaction isolation level. Each query executed by a transaction sees only data that was committed before the query (not the transaction) began. An Oracle query never reads dirty (uncommitted) data.

Because Oracle does not prevent other transactions from modifying the data read by a query, that data can be changed by other transactions between two executions of the query. Thus, a transaction that runs a given query twice can experience both nonrepeatable read and phantoms.
　
Serializable Serializable transactions see only those changes that were committed at the time the transaction began, plus those changes made by the transaction itself through INSERT, UPDATE, and DELETE statements. Serializable transactions do not experience nonrepeatable reads or phantoms.
　
Read-only Read-only transactions see only those changes that were committed at the time the transaction began and do not allow INSERT, UPDATE, and DELETE statements.
　
　
隔离级别 描述
已提交读取 Oracle 默认使用的事务隔离级别。事务内执行的查询只能看到查询执行前（而非事务开始前）就已经提交的数据。Oracle 的查询永远不会读取脏数据（未提交的数据）。

Oracle 不会阻止一个事务修改另一事务中的查询正在访问的数据，因此在一个事务内的两个查询的执行间歇期间，数据有可能被其他事务修改。举例来说，如果一个事务内同一查询执行两次，可能会遇到不可重复读取（nonrepeatable read）或不存在读取（phantom）的现象。
　
串行化 串行化隔离的事务只能看到事务执行前就已经提交的数据，以及事务内 INSERT，UPDATE，及 DELETE 语句对数据的修改。串行化隔离的事务不会出现不可重复读取或不存在读取的现象。
　
只读模式 只读事务只能看到事务执行前就已经提交的数据，且事务中不能执行 INSERT，UPDATE，及 DELETE 语句。
　
043

Set the Isolation Level

13.2.5.1 设置隔离级别
044 Application designers, application developers, and database administrators can choose appropriate isolation levels for different transactions, depending on the application and workload. You can set the isolation level of a transaction by using one of these statements at the beginning of a transaction:
　		 应用程序的设计开发者及数据库管理员可以依据应用程序的需求及系统负载（workload）而为不同的事务选择不同的隔离级别（isolation level）。用户可以在事务开始时使用以下语句设定事务的隔离级别：
　
045
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

SET TRANSACTION READ ONLY;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

SET TRANSACTION READ ONLY;
046 To save the networking and processing cost of beginning each transaction with a SET TRANSACTION statement, you can use the ALTER SESSION statement to set the transaction isolation level for all subsequent transactions:
　		 如果在每个事务开始时都使用 SET TRANSACTION 语句，将加重网络及处理器的负担。用户可以使用 ALTER SESSION 语句改变一个会话所有内事务的默认隔离级别：
　
047
ALTER SESSION SET ISOLATION_LEVEL SERIALIZABLE;

ALTER SESSION SET ISOLATION_LEVEL READ COMMITTED;
ALTER SESSION SET ISOLATION_LEVEL SERIALIZABLE;

ALTER SESSION SET ISOLATION_LEVEL READ COMMITTED;
048
See Also:

Oracle Database SQL Reference for detailed information on any of these SQL statements
另见：

Oracle Database SQL Reference 了解关于上述 SQL 语句的详细信息
049

Read Committed Isolation

13.2.5.2 已提交读取隔离
050 The default isolation level for Oracle is read committed. This degree of isolation is appropriate for environments where few transactions are likely to conflict. Oracle causes each query to run with respect to its own materialized view time, thereby permitting nonrepeatable reads and phantoms for multiple executions of a query, but providing higher potential throughput. Read committed isolation is the appropriate level of isolation for environments where few transactions are likely to conflict.
　		 Oracle 默认使用的隔离级别（isolation level）是已提交读取（read committed）隔离。这种程度的隔离适合在事务发生冲突的可能性较小的系统中使用。在这种隔离级别下，Oracle 能够保证事务内每个查询在执行期间都拥有一个唯一的数据视图，因此事务可能出现不可重复读取（nonrepeatable read）或不存在读取（phantom）的现象，但此时系统的数据处理能力较高。因此已提交读取隔离（read committed isolation）适合在事务发生冲突的可能性较小的系统中使用。
　
051

Serializable Isolation

13.2.5.3 串行化隔离
052 Serializable isolation is suitable for environments:
  • With large databases and short transactions that update only a few rows
  • Where the chance that two concurrent transactions will modify the same rows is relatively low
  • Where relatively long-running transactions are primarily read only
 符合以下特性的系统适合采用串行化隔离（serializable isolation）：
  • 数据量大，但事务短小，只会更新较少数据行的数据库
  • 两个并发事务修改相同数据的概率较小
  • 运行时间相对较长的事务只执行只读操作
053 Serializable isolation permits concurrent transactions to make only those database changes they could have made if the transactions had been scheduled to run one after another. Specifically, 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.
　		 在串行化隔离下，并发事务对数据库进行修改时只能顺序执行。具体来说，在串行化隔离下，Oracle 在允许一个采用串行化隔离的事务修改某些数据行时，需要判断在此事务开始执行之前，其他所有事务对这些数据行的修改已经被提交。
　
054 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.
　		 为了实现上述判断，Oracle 在数据块（data block）内存储了相关的控制信息，用于记录此块内数据行中所包含的数据是已提交或未提交的。即数据块内记录了近期对本数据块内数据行进行了修改的所有事务及事务的状态。在一个数据块内能够保留多少这样的记录是由 CREATE TABLE 或 ALTER TABLE 语句中的 INITRANS 参数设定的。
　
055 Under some circumstances, Oracle can 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 enables Oracle to allocate sufficient storage in each block to record the history of recent transactions that accessed the block.
　		 有些情况下，Oracle 无法获得足够的历史信息来判断某个数据行是否被一个事务修改过。当大量事务在短时间内并发地修改同一数据块就会出现以上情况。用户可以为可能被多个事务同时更新相同数据块的表设置较大的 INITRANS 值，以便避免上述情况。设置了较大的 INITRANS 值后，Oracle 就能为每个数据块分配足够的空间来记录访问此数据块的事务的信息。
　
056 Oracle generates an error when a serializable transaction tries to update or delete data modified by a transaction that commits after the serializable transaction began:
　		 当一个串行化事务试图更新或删除数据，而这些数据在此事务开始后被其他事务修改并进行了提交，Oracle 将报错：
　
057
ORA-08177: Cannot serialize access for this transaction
ORA-08177: 无法进行串行化访问
058 When a serializable transaction fails with the Cannot serialize access error, the application can take any of several actions:
  • Commit the work executed to that point
  • Execute additional (but different) statements (perhaps after rolling back to a savepoint established earlier in the transaction)
  • Undo the entire transaction
 当一个串行化事务因为无法进行串行化访问（Cannot serialize access）错误而失败时，应用程序可以 选择以下几种处理方式：
  • 将错误发生之前的操作提交
  • 执行其他操作（执行前可以回滚到事务内的某个保存点）
  • 撤销整个事务
059 Figure 13-2 shows an example of an application that rolls back and retries the transaction after it fails with the Cannot serialize access error:
　		 图13-2 显示了一个事务遇到无法进行串行化访问后， 程序进行回滚并尝试重新执行此事务的例子：
　
060 Figure 13-2 Serializable Transaction Failure
　		 图13-2 串行化事务失败
　
061


　

062
Figure 13-2 shows a serializable transaction consisting of a SELECT query that is repeated, followed by an UPDATE query. The second SELECT query sees the same data as the first, even though between the two SELECT queries someone else has changed the data. The UPDATE query fails if attempting to update a row changed and committed by another transaction since this transaction began. The "Cannot Serialize Access" error causes the transaction to roll back to the beginning and retry.
图13-2 显示了一个串行化事务，其中首先执行了两个相同的 SELECT 语句，接着执行了一个 UPDATE 语句。即便在两个 SELECT 执行之间有其他事务修改了相关数据，这两个 SELECT 也能够返回相同的结果。当 UPDATE 语句更新数据时，所更新的数据在此事务开始后被其他事务修改并提交过，Oracle 将报错 Cannot Serialize Access。这个错误将导致事务回滚并尝试重新执行。
063

Comparison of Read Committed and Serializable Isolation

13.2.6 已提交读取隔离与串行化隔离的区别
064 Oracle gives the application developer a choice of two transaction isolation levels with different characteristics. Both the read committed and serializable isolation levels provide a high degree of consistency and concurrency. Both levels provide the contention-reducing benefits of Oracle's read consistency multiversion concurrency control model and exclusive row-level locking implementation and are designed for real-world application deployment.
　		 Oracle 为应用程序开发者提供了两种特性相异的事务隔离级别。已提交读取（read committed）隔离和串行化（serializable）隔离都能实现高度的数据一致性及并发访问能力。这两种隔离级别都能够利用 Oracle 的读一致性多版本并发访问控制模型及独有的行级锁（row-level locking）技术，从而减少并发事务间的竞争。应用程序开发者可以使用这两种隔离级别开发符合现实要求的应用系统。
　
065

Transaction Set Consistency

13.2.6.1 事务集数据一致性
066 A useful way to view the read committed and serializable isolation levels in Oracle is to consider the following scenario: Assume you have a collection of database tables (or any set of data), a particular sequence of reads of rows in those tables, and the set of transactions committed at any particular time. An operation (a query or a transaction) is transaction set consistent if all its reads return data written by the same set of committed transactions. An operation is not transaction set consistent if some reads reflect the changes of one set of transactions and other reads reflect changes made by other transactions. An operation that is not transaction set consistent in effect sees the database in a state that reflects no single set of committed transactions.
　		 我们可以参考以下场景来研究 Oracle 中的两种隔离级别：假设现有一组数据库表（或称为一组数据集），一系列读取表数据的查询，以及一组在任意时间提交的事务。如果一个数据库操作（一个查询或一个事务）中所有读取返回的数据是由同一组已提交事务写入的，我们就称此操作满足事务集数据一致性（transaction set consistent）。相反，当一个数据库操作内的不同读取反映了不同事务集对数据的修改，此操作就不满足事务集数据一致性。换句话说，一个不满足事务集数据一致性的操作所看到的数据库的状态是由不同的已提交事务集决定的。
　
067 Oracle provides transactions executing in read committed mode with transaction set consistency for each statement. Serializable mode provides transaction set consistency for each transaction.
　		 在已提交读取（read committed）隔离模式下，Oracle 能保证每个语句的事务集数据一致性。而在串行化（serializable）隔离模式下，Oracle 能保证每个事务的事务集数据一致性。
　
068 Table 13-2 summarizes key differences between read committed and serializable transactions in Oracle.
　		 表13-2 总结了 Oracle 中已提交读取事务和串行化事务的关键区别。
　
069 Table 13-2 Read Committed and Serializable Transactions
　		 表13-2 已提交读取事务和串行化事务
　
070
　 Read Committed Serializable
Dirty write
　		 Not possible
　		 Not possible
　
Dirty read
　		 Not possible
　		 Not possible
　
Nonrepeatable read
　		 Possible
　		 Not possible
　
Phantoms
　		 Possible
　		 Not possible
　
Compliant with ANSI/ISO SQL 92
　		 Yes
　		 Yes
　
Read materialized view time
　		 Statement
　		 Transaction
　
Transaction set consistency
　		 Statement level
　		 Transaction level
　
Row-level locking
　		 Yes
　		 Yes
　
Readers block writers
　		 No
　		 No
　
Writers block readers
　		 No
　		 No
　
Different-row writers block writers
　		 No
　		 No
　
Same-row writers block writers
　		 Yes
　		 Yes
　
Waits for blocking transaction
　		 Yes
　		 Yes
　
Subject to cannot serialize access
　		 No
　		 Yes
　
Error after blocking transaction terminates
　		 No
　		 No
　
Error after blocking transaction commits
　		 No
　		 Yes
　
　
　 已提交读取
　		 串行化
　
脏写入（dirty write）
　		 不可能
　		 不可能
　
脏读取（dirty read）
　		 不可能
　		 不可能
　
不可重复读取（nonrepeatable read）
　		 可能
　		 不可能
　
不存在读取（phantom）
　		 可能
　		 不可能
　
与 ANSI/ISO SQL 92 标准兼容
　		 是
　		 是
　
唯一的数据视图的使用范围
　		 语句
　		 事务
　
事务集数据一致性
　		 语句级
　		 事务级
　
行级锁
　		 是
　		 是
　
读操作（reader）阻塞写操作（writer）
　		 否
　		 否
　
写操作阻塞读操作
　		 否
　		 否
　
针对不同数据行的写操作
是否相互阻塞
　		 否
　		 否
　
针对相同数据行的写操作
是否相互阻塞
　		 是
　		 是
　
等待导致阻塞的事务（blocking transaction）
　		 是
　		 是
　
会出现无法进行串行化访问（Cannot serialize access）错误
　		 否
　		 是
　
在导致阻塞的事务结束后
将发生错误
　		 否
　		 否
　
在导致阻塞的事务提交后
将发生错误
　		 否
　		 是
　
[参考 051-062，尤其是 056，关于串行化隔离的特点；而与阻塞相关的条目可以参考 13.2.6.2 关于行级锁的介绍。]
　
071

Row-Level Locking

13.2.6.2 行级锁
072 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 undo 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.
　		 在已提交读取隔离模式（read committed）及串行化隔离模式（serializable）下执行的事务都采用行级锁（row-level locking）技术，他们在更新被未提交的并发事务修改的数据行时都会发生等待--等待未提交的并发事务提交或撤销，并释放锁。如果未提交的并发事务进行了回滚，那么无论发生等待的事务运行在何种隔离模式下，都能修改之前被锁住的数据行，如同未提交的并发事务不存在一样。
　
073 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 error, because the other transaction has committed a change that was made since the serializable transaction began.
　		 当导致阻塞的事务（blocking transaction）[前文中提到的未提交的并发事务]提交并释放了锁后，运行在已提交读写模式下的等待事务就能够继续执行其中的更新操作。而运行在串行化模式下的等待事务将出现无法进行串行化访问（Cannot serialize access）错误，因为阻塞事务在串行化等待事务开始后更新了后者所存取的数据。
　
074

Referential Integrity

13.2.6.3 引用完整性
075 Because Oracle does not use read locks in either read-consistent or serializable transactions, data read by one transaction can be overwritten by another. Transactions that perform database consistency checks at the application level cannot assume that the data they read will remain unchanged during the execution of the transaction even though such changes are not visible to the transaction. Database inconsistencies can result unless such application-level consistency checks are coded with this in mind, even when using serializable transactions.
　		 无论在已提交读取隔离模式（read committed）还是串行化隔离模式（serializable）中，Oracle 都不会使用读取锁，即某一个事务读取的数据可能会被其他事务更新。在应用 级（application level）进行数据库一致性检查的事务无法确定在其执行期间所读取的数据是否同时已被修改，因为所有修改对此事务来说是透明的。如果应用程序的代码逻辑 需要进行应用级的一致性检查，即便采用串行化事务（serializable transaction），也不能避免数据不一致的问题。
　
076
See Also:

Oracle Database Application Developer's Guide - Fundamentals for more information about referential integrity and serializable transactions
另见：

Oracle Database Application Developer's Guide - Fundamentals 了解关于引用完整性和串行化事务的详细信息
077
Note:

You can use both read committed and serializable transaction isolation levels with Real Application Clusters.
Note:

在 RAC 环境中，用户也可以选择已提交读取或串行化两种事务隔离级别。
078

Distributed Transactions

13.2.6.4 分布式事务
079 In a distributed database environment, a given transaction updates data in multiple physical databases protected by two-phase commit to ensure all nodes or none commit. In such an environment, all servers, whether Oracle or non-Oracle, that participate in a serializable transaction are required to support serializable isolation mode.
　		 在分布式数据库系统中，一个更新多个物理数据库中数据的事务将采用两步提交机制（two-phase commit）以保证事务在所有节点上全部提交或全部回滚。在分布式数据库系统中，一个采用串行化隔离（serializable）的事务所涉及的所有 Oracle 及非 Oracle 数据库都必须支持串行化隔离模式。
　
080 If a serializable transaction tries to update data in a database managed by a server that does not support serializable transactions, the transaction receives an error. The transaction can undo and retry only when the remote server does support serializable transactions.
　		 当一个串行化事务试图在不支持串行化隔离模式的数据库中更新数据时，此事务将发生错误。只有远程数据库支持串行化隔离模式时，事务发生错误后才能撤销并重试。
　
081 In contrast, read committed transactions can perform distributed transactions with servers that do not support serializable transactions.
　		 与串行化隔离模式相反，采用已提交读取隔离模式（read committed）的事务在不支持串行化隔离模式的数据库中执行分布式事务。
　
082
See Also:

Oracle Database Administrator's Guide
另见：

Oracle Database Administrator's Guide
083

Choice of Isolation Level

13.2.7 选择事务隔离级别
084 Application designers and developers should choose an isolation level based on application performance and consistency needs as well as application coding requirements.
　		 应用程序的设计、开发者应当根据应用程序的性能要求，数据一致性要求，以及应用程序的编码需求来决定选择何种隔离级别（isolation level）。
　
085 For environments with many concurrent users rapidly submitting transactions, designers must assess transaction performance requirements in terms of the expected transaction arrival rate and response time demands. Frequently, for high-performance environments, the choice of isolation levels involves a trade-off between consistency and concurrency.
　		 对于存在大量并发用户快速地提交事务的系统来说，应用程序设计者应该从事务处理量及响应时间的角度评估事务处理的性能。通常来说，为一个对性能要求高的系统选择事务隔离级别时，需要在数据一致性及数据并发处理间进行平衡。
　
086 Application logic that checks database consistency must take into account the fact that reads do not block writes in either mode.
　		 在应用层对数据库一致性进行检查的应用逻辑必须注意，在两种隔离模式下读操作都不会阻塞写操作。
　
087 Oracle isolation modes provide high levels of consistency, concurrency, and performance through the combination of row-level locking and Oracle's multiversion concurrency control system. Readers and writers do not block one another in Oracle. Therefore, while queries still see consistent data, both read committed and serializable isolation provide a high level of concurrency for high performance, without the need for reading uncommitted data.
　		 在 Oracle 行级锁（row-level locking）及 Oracle 多版本并发访问控制系统（multiversion concurrency control system）的基础上，Oracle 的两种事务隔离模式能够实现高一致性，高并发性及高性能。在 Oracle 系统中，读写操作不会相互阻塞。因此，已提交读取（read committed）和串行化（serializable）两种隔离模式都能提供高度的并发访问能力，从而保证系统的高性能，同时查询无需读取未提交的数据 。
　
088

Read Committed Isolation

13.2.7.1 已提交读取隔离
089 For many applications, read committed is the most appropriate isolation level. Read committed isolation can provide considerably more concurrency with a somewhat increased risk of inconsistent results due to phantoms and non-repeatable reads for some transactions.
　		 对于大多数应用来说，已提交读取隔离（read committed）是最适合的事务隔离级别。已提交读取隔离能够最大限度地保证数据并发性，但在某些事务中可能会出现不可重复读取（non-repeatable read）或不存在读取（phantom），因此略微增加了出现数据不一致性的风险。
　
090 Many high-performance environments with high transaction arrival rates require more throughput and faster response times than can be achieved with serializable isolation. Other environments that supports users with a very low transaction arrival rate also face very low risk of incorrect results due to phantoms and nonrepeatable reads. Read committed isolation is suitable for both of these environments.
　		 在对性能要求较高的系统中，为了应对较高的事务到来率（transaction arrival rate），系统需要提供更大的事务吞吐量和更快的响应速度，此时采用串行化隔离可能难以实现。还有一类系统，其事务到来率较低，出现不可重复读取或不存在读取的风险也较低。以上两种系统均适合采用已提交读取隔离 。
　
091 Oracle read committed isolation provides transaction set consistency for every query. That is, every query sees data in a consistent state. Therefore, read committed isolation will suffice for many applications that might require a higher degree of isolation if run on other database management systems that do not use multiversion concurrency control.
　		 Oracle 的已提交读取隔离能够确保所有查询的事务集数据一致性（transaction set consistent）。即查询获得的数据是处于一致性状态下的。因此在 Oracle 中已提交读取隔离能够满足大多数应用的要求。而在没有多版本并发访问控制的数据库管理系统中，开发者可能需要采用更高程度的隔离方式。
　
092 Read committed isolation mode does not require application logic to trap the Cannot serialize access error and loop back to restart a transaction. In most applications, few transactions have a functional need to issue the same query twice, so for many applications protection against phantoms and non-repeatable reads is not important. Therefore many developers choose read committed to avoid the need to write such error checking and retry code in each transaction.
　		 在已提交读取隔离模式下，开发者不需要在应用逻辑中捕获无法进行串行化访问（Cannot serialize access）错误，也无需回滚并重新执行事务。在大多数应用程序中，几乎不会有在一个事务中执行同一查询多次的情况，因此在这些应用程序中，为防止出现不可重复读取或不存在读取而采取的保护措施并不重要。 如果开发者选择已提交读取隔离，就能够省略在每个事务中加入错误检查及事务重做的代码。
　
093

Serializable Isolation

13.2.7.2 串行化隔离
094 Oracle's serializable isolation is suitable for environments where there is a relatively low chance that two concurrent transactions will modify the same rows and the long-running transactions are primarily read only. It is most suitable for environments with large databases and short transactions that update only a few rows.
　		 Oracle 的串行化隔离（serializable isolation）适合于具备以下特点的系统：出现修改相同数据的事务的几率较小，且长时间执行的事务以只读操作为主。最适合采用串行化隔离的系统是大型数据库，且其中主要运行更新少量数据的短小事务。
　
095 Serializable isolation mode provides somewhat more consistency by protecting against phantoms and nonrepeatable reads and can be important where a read/write transaction runs a query more than once.
　		 串行化隔离能够提供更好的数据一致性，她能阻止不可重复读取（nonrepeatable read）或不存在读取（phantom）的现象。当一个读或写事务中需要运行同一查询多次时，串行化隔离的作用更加明显。
　
096 Unlike other implementations of serializable isolation, which lock blocks for read as well as write, Oracle provides nonblocking queries and the fine granularity of row-level locking, both of which reduce read/write contention. For applications that experience mostly read/write contention, Oracle serializable isolation can provide significantly more throughput than other systems. Therefore, some applications might be suitable for serializable isolation on Oracle but not on other systems.
　		 某些数据库管理系统在实现串行化隔离时，无论读写操作都要对整个数据块加锁。而 Oracle 则采用了无阻塞查询（nonblocking query）及低粒度的行级锁技术（row-level locking），减少了读写操作间的竞争。对于存在较多读写竞争的应用，Oracle 的串行化隔离与其他数据库管理系统相比能够大大地提高事务处理能力。因此，某些应用在 Oracle 中可以采用串行化隔离，而在其他数据库管理系统则未必可行。
　
097 All queries in an Oracle serializable transaction see the database as of a single point in time, so this isolation level is suitable where multiple consistent queries must be issued in a read/write transaction. A report-writing application that generates summary data and stores it in the database might use serializable mode because it provides the consistency that a READ ONLY transaction provides, but also allows INSERT, UPDATE, and DELETE.
　		 运行在串行化隔离模式下的事务中的所有查询所获得的数据都来自同一时间点（single point in time），因此这种隔离级别适合于需要执行多个满足一致性的查询的事务。例如，汇总数据并将结果写入数据库的报表应用可以采用串行化隔离，因为串行化事务所提供的数据一致性与 READ ONLY 事务相同，但其中还可以执行 INSERT，UPDATE，和 DELETE 操作。
　
098
Note:

Transactions containing DML statements with subqueries should use serializable isolation to guarantee consistent read.
提示：

如果事务中存在使用了子查询的 DML 语句，应该使用串行化隔离来保证一致性的读取。
099 Coding serializable transactions requires extra work by the application developer to check for the Cannot serialize access error and to undo and retry the transaction. Similar extra coding is needed in other database management systems to manage deadlocks. For adherence to corporate standards or for applications that are run on multiple database management systems, it may be necessary to design transactions for serializable mode. Transactions that check for serializability failures and retry can be used with Oracle read committed mode, which does not generate serializability errors.
　		 在实现串行化隔离事务时，应用开发者必须编码来捕获无法进行串行化访问（Cannot serialize access）错误，之后回滚并重做事务。在其他数据库管理系统中需要类似的代码来处理死锁（deadlock）。有时为了遵从已有系统的标准，或者当应用可能运行在多种数据库管理系统上时，应按照串行化隔离的要求来设计事务处理代码。具备检查并处理串行化错误功能的事务也可以运行在 Oracle 的已提交读取（read committed）隔离模式下，因为此种隔离模式下不会产生串行化错误。
　
100 Serializable mode is probably not the best choice in an environment with relatively long transactions that must update the same rows accessed by a high volume of short update transactions. Because a longer running transaction is unlikely to be the first to modify a given row, it will repeatedly need to roll back, wasting work. Note that a conventional read-locking, pessimistic implementation of serializable mode would not be suitable for this environment either, because long-running transactions—even read transactions—would block the progress of short update transactions and vice versa.
　		 如果系统中存在长时间运行的写事务，且其所操作的数据同时还会被大量的小事务更新，则此类系统不应采用串行化模式。因为长事务所需更新的数据可能会被其他事务抢先更新，则长事务可能需要重复地回滚，浪费系统资源。需要注意的是，其他数据库管理系统所实现的串行化隔离（使用读取锁（read-locking））同样不适合上述情况，因为长事务（即便是只执行读取操作的事务）会和短小的写事务相互阻塞。
　
101 Application developers should take into account the cost of rolling back and retrying transactions when using serializable mode. As with read-locking systems, where deadlocks occur frequently, use of serializable mode requires rolling back the work done by terminated transactions and retrying them. In a high contention environment, this activity can use significant resources.
　		 应用开发者在采用串行化隔离时应考虑回滚及重做事务所带来的开销。而在采用读取锁的数据库管理系统中，死锁会频繁出现，在这样的系统中采用串行化隔离，必须 令因死锁而终止的事务回滚并重做。如果一个系统对数据访问的竞争较激烈，那么处理串行化错误将消耗大量资源。
　
102 In most environments, a transaction that restarts after receiving the Cannot serialize access error is unlikely to encounter a second conflict with another transaction. For this reason, it can help to run those statements most likely to contend with other transactions as early as possible in a serializable transaction. However, there is no guarantee that the transaction will complete successfully, so the application should be coded to limit the number of retries.
　		 在大多数系统中，一个事务发生无法进行串行化访问（Cannot serialize access）错误后重做时再次与其他事务冲突的几率较小。基于上述原因，采用串行化隔离时，容易与其他事务产生竞争的语句应该在事务开始后尽早执行。但是我们始终无法保证事务能够成功执行，因此在应用程序中应该限制重做的次数。
　
103 Although Oracle serializable mode is compatible with SQL92 and offers many benefits compared with read-locking implementations, it does not provide semantics identical to such systems. Application designers must take into account the fact that reads in Oracle do not block writes as they do in other systems. Transactions that check for database consistency at the application level can require coding techniques such as the use of SELECT FOR UPDATE. This issue should be considered when applications using serializable mode are ported to Oracle from other environments.
　		 尽管 Oracle 的串行化隔离模式与 SQL92 兼容，而且与采用读取锁的实现方式相比具备很多优点，但是 Oracle 串行化隔离所包含的语义与其他数据库管理系统不完全相同。应用开发者必须注意，与其他数据库管理系统不同，在 Oracle 中读操作不会阻塞写操作。在应用级（application level）对数据库一致性进项检查的事务需要使用 SELECT FOR UPDATE 之类的技巧才能避免错误。当从其他数据库管理系统向 Oracle 迁移应用时，尤其要注意上述问题。
　
104

Quiesce Database

13.2.7.3 静默数据库
105 You can put the system into quiesced state. The system is in quiesced state if there are no active sessions, other than SYS and SYSTEM. An active session is defined as a session that is currently inside a transaction, a query, a fetch or a PL/SQL procedure, or a session that is currently holding any shared resources (for example, enqueues--enqueues are shared memory structures that serialize access to database resources and are associated with a session or transaction). Database administrators are the only users who can proceed when the system is in quiesced state.
　		 管理员可以将数据库置于静默状态（quiesced state）。静默状态是指数据库中只存在 SYS 和 SYSTEM 用户建立的活动会话（active session）。活动会话的定义是，其中正在执行事务（transaction），查询（query），数据提取（fetch），或 PL/SQL 过程的会话，或者是当前拥有某种共享资源（例如，队列（enqueue）--队列是一个共享的内存结构，她总是和事务或会话相关，用于串行化地访问数据库资源）的会话。当数据库处于静默状态后，只有数据库管理员才能继续操作 数据库。
　
106 Database administrators can perform certain actions in the quiesced state that cannot be safely done when the system is not quiesced. These actions include:
  • Actions that might fail if there are concurrent user transactions or queries. For example, changing the schema of a database table will fail if a concurrent transaction is accessing the same table.
  • Actions whose intermediate effect could be detrimental to concurrent user transactions or queries. For example, suppose there is a big table T and a PL/SQL package that operates on it. You can split table T into two tables T1 and T2, and change the PL/SQL package to make it refer to the new tables T1 and T2, instead of the old table T.

    When the database is in quiesced state, you can do the following:
    CREATE TABLE T1 AS SELECT ... FROM T;
    CREATE TABLE T2 AS SELECT ... FROM T;
    DROP TABLE T;

    You can then drop the old PL/SQL package and re-create it.

 数据库管理员在静默状态下可以执行某些特殊的操作，而这类操作如果在非静默状态下执行可能存在不安全因素。这样的特殊操作包括：
  • 如存在并发的用户事务或查询可能会出错的操作。例如，改变数据库表的所属方案时，如果有并发事务正在访问此表将会出错。
  • 操作结果对并发的用户事务或查询有损害的操作。例如，假设现有一个大表 T，以及一个对此大表进行操作的 PL/SQL 包。在静默状态下，管理员可以将 T 分割为 T1 和 T2，并改写 PL/SQL 包，使其引用新表 T1 和 T2 来代替 原有的 T 表。

    当数据库处于静默状态时，管理员可以执行以下操作：
    CREATE TABLE T1 AS SELECT ... FROM T;
    CREATE TABLE T2 AS SELECT ... FROM T;
    DROP TABLE T;

    之后再移除旧 PL/SQL 包并重建。
107 For systems that must operate continuously, the ability to perform such actions without shutting down the database is critical.
　		 对于必须持续运行的系统，无需关闭数据库就能执行某些特殊操作的功能十分必要。
　
108 The Database Resource Manager blocks all actions that were initiated by a user other than SYS or SYSTEM while the system is quiesced. Such actions are allowed to proceed when the system goes back to normal (unquiesced) state. Users do not get any additional error messages from the quiesced state.
　		 当数据库静默后，数据库资源管理器（Database Resource Manager）将阻止 SYS 及 SYSTEM 之外的用户所提交的操作。当数据库恢复正常（非静默）状态后，用户操作可以继续进行。用户不会因为数据库进入了静默状态而得到额外的错误信息。
　
109

How a Database Is Quiesced

13.2.7.3.1 数据库如何进入静默模式
110 The database administrator uses the ALTER SYSTEM QUIESCE RESTRICTED statement to quiesce the database. Only users SYS and SYSTEM can issue the ALTER SYSTEM QUIESCE RESTRICTED statement. For all instances with the database open, issuing this statement has the following effect:
  • Oracle instructs the Database Resource Manager in all instances to prevent all inactive sessions (other than SYS and SYSTEM) from becoming active. No user other than SYS and SYSTEM can start a new transaction, a new query, a new fetch, or a new PL/SQL operation.
  • Oracle waits for all existing transactions in all instances that were initiated by a user other than SYS or SYSTEM to finish (either commit or terminate). Oracle also waits for all running queries, fetches, and PL/SQL procedures in all instances that were initiated by users other than SYS or SYSTEM and that are not inside transactions to finish. If a query is carried out by multiple successive OCI fetches, Oracle does not wait for all fetches to finish. It waits for the current fetch to finish and then blocks the next fetch. Oracle also waits for all sessions (other than those of SYS or SYSTEM) that hold any shared resources (such as enqueues) to release those resources. After all these operations finish, Oracle places the database into quiesced state and finishes executing the QUIESCE RESTRICTED statement.
  • If an instance is running in shared server mode, Oracle instructs the Database Resource Manager to block logins (other than SYS or SYSTEM) on that instance. If an instance is running in non-shared-server mode, Oracle does not impose any restrictions on user logins in that instance.
 数据库管理员使用 ALTER SYSTEM QUIESCE RESTRICTED 语句将数据库置为静默状态。只有 SYS 和 SYSTEM 能够提交 ALTER SYSTEM QUIESCE RESTRICTED 语句。当提交了上述语句后，将对数据库的所有实例产生以下影响：
  • Oracle 通过数据库资源管理器（Database Resource Manager）控制所有实例，阻止所有非活动（inactive）的会话（SYS 和 SYSTEM 的会话除外）恢复为活动（active）状态。SYS 及 SYSTEM 之外的用户不能执行新的事务（transaction），查询（query），数据提取操作（fetch）及 PL/SQL 过程。
  • Oracle 将等待所有实例中由 SYS 及 SYSTEM 之外的用户所提交的事务结束（提交或终止）。Oracle 还会等待所有实例中由 SYS 及 SYSTEM 之外的用户执行且不在事务内的查询（query），数据提取（fetch），PL/SQL 过程结束。如果一个查询是由多个连续的 OCI 数据提取操作执行的，Oracle 不会等待所有的数据提取全部结束。Oracle 只会等待当前的数据提取结束并阻塞之后的数据提取。Oracle 还会等待所有拥有共享资源的会话（SYS 及 SYSTEM 用户的资源除外）释放资源。上面提到的所有等待都结束之后，Oracle 可以将数据库置为静默状态，并结束 QUIESCE RESTRICTED 语句。
  • 如果数据库的某个实例是在共享服务模式（shared server mode）下运行的，Oracle 通过数据库资源管理器（Database Resource Manager）阻止用户（SYS 及 SYSTEM 用户除外）登录到此实例。如果实例运行在专用服务模式（dedicated server mode）下，Oracle 不会对此实例的用户登录进行限制。