数据库的并发控制机制，顾名思义，是用来控制数据库的并发操作的机制。控制的目的是为了保证数据完整和数据一致性。

何为数据一致性？在数据库的并发操作中，多个事务同时读取同一份数据，要保证多个事务读取的同一份数据是准确的。

可能数据的不一致更好理解。例如：大家同时购买火车票，剩余100张，大家一起购买，如果不控制，同一时刻有若干人一起购买，A买了一张要更新库存99，B买了一张也要更新库存可能也是99，实际上票可能卖完了，库存还是99.

因此并发操作中，需要确保事务的隔离性以保证数据的一致性。那么如何确保事务的隔离性呢？接下来，我们将对Oracle三种数据库的并发控制机制进行比较分析。

数据库的数据一致性支持机制：事务、锁、日志。

首先我们看看什么是事务。

一、事务

事务：又称为交易，访问数据库系统的可恢复的最小单元。

1、事务的ACID

• 原子性（Atomicity）： 事务为一个整体的工作单元，事务对数据库的操作要么全部执行，要么全部取消；
• 一致性（Consistency）： 事务完成时，所有数据都保持一致状态；
• 隔离性（Isolation）： 事务所做的修改必须与其他事务所做的修改隔离。事务查看数据时数据的状态要么为其他事务修改之前要么为其他事务修改之后，不会为中间状态。即多个事务不能同时修改同一份数据；
• 持久性（Durability）： 事务提交后，对数据库所做的修改会永久保存。

2、事务的初始化和终止

事务在可执行的 SQL 第一次执行时会自动初始化，事务一旦初始化，就必须终止（COMMIT 或 ROLLBACK）。

1）关于事务的 COMMIT 和 ROLLBACK

多数情况下，事务通过执行 COMMIT 或 ROLLBACK 终止事务。执行 COMMIT 语句后，事务初始化后对数据库做出的所有改变都会变成永久的；执行 ROLLBACK 语句后，事务初始化后对数据库做出的所有改变都会被撤销，数据库返回事务开始之前的状态。

2）关于不成功的事务的结果

上面说了当事务被 COMMIT 或 ROLLBACK 终止语句后会发生什么，如果事务完成之前系统发生故障，会发生什么？这种情况下，数据库管理器将撤销所有未 COMMIT 的修改，从而恢复数据的一致性。

Oracle 利用 undo log 撤销修改。undo log 记录了行的修改操作，执行事务中由于某种原因失败，或使用 ROLLBACK 时，就可以利用 undo log 将数据恢复到修改之前的样子。

3、事务的隔离级别

1）潜在问题

事务为什么需要多种可以设置的隔离级别呢？通常，锁可以实现并发操作中事务的隔离，保证数据的一致性。锁提高了并发性能，但会带来潜在的问题：

• 脏读： 当前事务可以读到另外一个事务中未提交的数据。
• 不可重复读： 在一个事务内读到的同一条数据是不一样的。
• 幻读： 事务 A 在相同条件下第二次读取时读到新插入的数据。
• 丢失更新： 一个事务的更新操作会被另一个事务的更新操作所覆盖，从而导致数据的不一致。 例如：事务 T1 将行记录修改为 V1，事务 T1 未提交。事务 T2 将行记录修改为 V2，事务 T2 未提交。事务 T1 提交。事务 T2 提交。

在当前数据库的锁机制下不会导致理论意义上的丢失更新问题，但是实际上在所有多用户计算机系统环境下都有可能产生这个问题。例如：

• 事务 T1 查询一行数据，放入本地内存，显示给 User1。
• 事务 T2 查询一行数据，放入本地内存，显示给 User2。
• User1 修改这行记录，更新数据库并提交。
• User2 修改这行记录，更新数据库并提交。

这些问题往往和系统数据库的使用方式和形态有关。而设置事务的隔离级别，就是根据不同的场景来解决以上问题。比如上面所说的丢失更新问题，隔离级别中 SELECT…FOR UPDATE 即带有更新意图读的时候，步骤 1、2 都是要上写锁的，避免丢失更新的问题。下面详解数据库的隔离级别及其加锁方式。

2）数据库的隔离级别及其加锁方式

① SQL 标准定义的四个隔离级别

• READ UNCOMMITTED： 未提交读。事务可以看到其他事务所有未提交的数据。读取数据不加锁；
• READ COMMITTED： 提交读。事务只可以看到其他事务已经提交的数据；
• REPEATABLE READ： 重复度。锁定事务引用的符合检索条件的部分行，其他事务不可修改这些行，但可执行 INSERT 操作。即可能出现幻读；
• SERIALIZABLE： 可串行化。强制的进行排序，在每个读数据行上添加锁，所有事务依次逐个执行，事务之间不会产生干扰。事务提交后释放锁。会导致大量超时现象和锁竞争。

② 四种隔离级别会导致的问题

③ 数据库中的隔离级别

Oracle 数据库支持 READ COMMITTED（提交读）和 SERIALIZABLE 这两种事务隔离级别。 默认的隔离级别是 READ COMMITTED（提交读）。

二、锁

事务隔离级别是并发控制的整体解决方案，其实际上是综合利用各种类型的锁和行版本控制来解决并发问题。

这里我们主要看数据库中的基本锁。

1、锁的类型

• S-LOCK： 共享锁。又叫读锁，当用户要进行数据的读取时，对数据加上共享锁。共享锁可以同时加多个；
• X-LOCK： 排他锁。又叫写锁。SQL INSERT/UPDATE/DELETE 语句执行时会上 X-LOCK。排他锁只可以加一个，和其他的排他锁共享锁都相斥；
• U-LOCK： 修改锁。CURSOR SELECT 有 UPDATE OF 子句时，FETCH 时对读出的记录，会上 U-LOCK。

Oracle 支持 S-LOCK 和 X-LOCK。

2、事务隔离级别中读数据时的锁类型

如上，数据库在各种隔离级别下，SQL 执行 INSERT/UPDATE/DELETE 语句时都会上 X-LOCK，那么在读数据时如何上锁呢?

Oracle 中只支持 READ COMMITED 和 SERIALIZABLE 隔离级别。这两种隔离级别下的锁机制和 InnoDB 一致。Oracle 中不需要 READ UNCOMMITTED 隔离级别，是因为 READ UNCOMMITTED 主要功能是提高只读时的并发性，而 Oracle 在 READ COMMITED 隔离级别下使用一致性非锁定读也有同样的功能。

3、一致性非锁定读

隔离级别 READ COMMITED 和 REPEATABLE READ（MySQL 的默认隔离级别）都使用一致性非锁定读， SELECT 时不上锁，那么如何保证事务的隔离性呢？这两种隔离级别采用快照数据的方式保证隔离性。读取时对于上了 X 锁的数据，都会去读取行的一个快照数据。快照数据是指该行的之前版本的数据，通过 undo 段实现。而 undo 段用来在事务中回滚数据，因此快照数据本身没有额外的开销。

READ COMMITED 和 REPEATABLE READ 两种隔离级别在读快照数据时的区别是，RC 总是读取最新的快照数据，所以可能会发生不可重复读，即第二次读取的数据和第一次不一致；而 RR 总是读取事务开始时的快照，所以不会发生不可重复度。

非锁定读机制不会等待行上 X 锁的释放，极大的提高了数据库的并发性。是 InnoDB 的默认读取方式。

三、直接上代码

--请求加锁
procedure get_admin_lock(status out nocopy number)
is
  l_lockhandle varchar2(128);
  l_status number := 100;
  l_exit_loop boolean := FALSE;
begin
  dbms_lock.allocate_unique('xxx', l_lockhandle);

  l_exit_loop := FALSE;

  loop
    exit when l_exit_loop;

    l_status := dbms_lock.request(l_lockhandle);

    if l_status in (0, 4) then
      -- 0 => success
      -- 1 => already held. deem as success.

      l_exit_loop := TRUE;

    elsif l_status <> 1 then

      -- 1 => Timeout, in which case we want to keep trying (ie. stay in the
      -- loop). Any value other than 1 is a fatal error.

      raise_application_error(-20000, 'Fatal error in get_admin_lock() - '||
                                      to_char(l_status));
    end if;

  end loop;

  status := l_status;

return;

end get_admin_lock;

---释放锁
procedure release_admin_lock(status out nocopy number)
is
l_lockhandle varchar2(128);
l_status number := 100;
l_exit_loop boolean := FALSE;
begin
dbms_lock.allocate_unique('xxx',l_lockhandle);

l_exit_loop := FALSE;

loop

exit when l_exit_loop;

l_status:=dbms_lock.release(l_lockhandle);

if l_status in (0, 4) then
-- 0 => success
-- 1 => already held. deem as success.

l_exit_loop := TRUE;
else
raise_application_error(-20000,'Fatal error in release_admin_lock() - '|| to_char(l_status));
end if;

end loop;


status:=l_status;


return;
end release_admin_lock;

希望对对大家有帮助。