事务SQL语句

-- 创建表
create table t1(
	name char(1)
);
-- 开始一个事务
  begin;
  insert into t1 values ('1');
  insert into t1 values ('2');
  insert into t1 values ('3');
-- 设置保存点
	savepoint temppoint;
 insert into t1 values ('4');
 insert into t1 values (5);
 --事务出现错误则发生回滚，回到保存点
 rollback to temppoint;
-- -- 事务全部正确完成，提交给数据库保存
   commit;

执行结果：

恢复的实现技术

日志记录的内容

• 事物标志
• 操作类型(插删改)
• 操作对象
• 跟新前数据的旧值，称前像AI
• 跟新后数据的新值，称后像BI

以数据块为单位的日志文件
日志文件的作用：
静态存储：数据库损坏后，重装后援副本，根据
日志文件，重做已完成
为保证数据库可恢复应遵守的规则

• 提交规则：后像应提交前写入磁盘DB或者日志
• 先记后写规则：先写日志后写数据库

登记日志文件

恢复策略

利用日志文件进行恢复
基本策略：
对于尚未提交的事务，执行撤销处理。
对于已经提交的事务，执行重做处理。

基本方法：
扫描日志文件，确定所有已开始但是尚未提交的事务(UNDO)，再确定所有已经提交的事务()
UNDO处理：
已执行的操作进行撤销处理，使数据库恢复到该事务开始前的状态。
具体做法是反向扫描文件，对每个UNDO的事务进行反操作
UNDO处理时维护事务原子性所必须的

REDO处理：
重做已提交事务的操作。 具体做法是：正向扫描日志文件重新执行登记的操作
有些事务已经发出commit操作，但是更新结果知识写入缓冲区或磁盘上的数据库被破坏，因此需要进行REDO处理。

故障恢复过程的处理
1、事务故障的恢复
事务故障是指事务被非正常终止，应根据日志文件对未完成 事务做UNDO处理，步骤如下： （1）反向扫描日志文件，查找未完成事务的更新操作；
（2）对该事务的更新操作执行逆操作；
（3）继续反向扫描日志文件，对遇到的更新操作做同样 处理；
（4）当遇到某事务的开始标记时，停止对该事务的处理。
（5）重复上述过程，直到所有未完成事务全部UNDO完毕。

2、系统故障的恢复 系统故障造成数据库不一致的原因，一是未完成事务对数 据库的更新已写入数据库，二是已提交事务的结果在故障发 生前留在缓冲区没来得及写入数据库。恢复操作是撤消未完 成事务，重做已完成事务。步骤如下： （1）正向扫描日志文件，找出在故障发生前已提交的事 务，将它们记入重做（REDO）队列，同时找出故 障发生前尚未完成的事务，将它们记入撤消 （UNDO）队列。 （2）反向扫描日志文件，对UNDO队列的每个事务执行 逆操作，即做撤消处理。 （3）正向扫描日志文件，对REDO队列中的每个事务重 新执行日志文件登记的操作

3、介质故障的恢复 介质故障发生后，磁盘上的数据文件和日志文件均被破坏 ，恢复的方法是重装数据库和日志文件，然后重做自转储以 来已完成的事务。步骤如下：
（1）装入最近转储的数据库后援副本，若是动态转储，则还 应装入转储期间的日志文件，将数据库恢复到一致性状态。
（2）装入转储结束后的日志副本，重做已完成的事务

系统故障与事务故障的恢复由系统自动完成，对用户透明 ，介质故障的恢复，需要DBA重装数据库和日志文件副本， 然后执行相应的恢复命令。不论那种恢复，一般都要扫描整
个日志文件。

具有检查点的恢复技术
利用日志文件恢复数据库，一般要扫描整个日志文件，
日志是个流水帐，往往很长，这样做具有两个问题： * 搜索整个日志文件将耗费大量的时间； * 许多已提交事务的更新结果实际上已写入数据库中， 重新做这些事务只会浪费大量的时间。 因此，确定哪些事务需REDO，哪些不需REDO，就很 有意义。解决的方法是： 在日志文件中设置检查点记录
DBMS周期性地在日志中记录一个检查点：将当前 正在执行（尚未提交）的所有事务记录于一个记录中— —检查点记录。
具体工作为：
检查点恢复技术的数据库和日志写入磁盘的过程
① 将内存中所有日志记录写入磁盘； ② 在磁盘日志文件中写入一个检查点记录； ③ 将内存中所有数据库记录写入磁盘数据库中； ④ 把检查点记录在日志文件中的地址写入一个重新 开始文件中。
在检查点之前已提交的事务对数据库的修改在检 查点之前或检查点建立时已记入磁盘，只要数据库未 被破坏，不需要对这些事务执行重做（REDO）。
具有检查点的恢复算法
① 根据重新开始文件中最后一个检查点记录的地址，在 日志文件中找到最近的一个检查点记录； ② 设置两个队列，将检查点中的所有事务放入UNDOLIST，并令REDO-LIST暂为空集； UNDO-LIST：需要UNDO操作的事务集合； REDO-LIST：需要REDO操作的事务集合；
③ 从该检查点开始扫描日志文件到文件结束为止： 凡遇有begin_transaction的事务放入UNDO-LIST； 凡遇有commit的事务, 将它从UNDO-LIST移入 REDO-LIST；
④ 对UNDO-LIST中的事务执行UNDO操作
⑤ 对REDO-LIST中的事务执行REDO操作

§6 数据库镜像 前面已介绍，当数据库系统发生故障时，可利用日 志文件进行数据库恢复，但前提是日志文件必须完好。 然而当发生介质故障时，往往不仅数据库被摧毁，日志 文件也难逃恶运，此时恢复操作就无法实施。这在银行 数据库等系统中是绝对不允许的。
解决办法： 1、数据库镜象：将整个数据库或其中的关键数据同时 存放在两个分离的物理磁盘上。每当主数据库更新时， DBMS自动把更新后的数据复制到另一个磁盘上，从而 自动保证主数据库与镜像数据库的一致性。 但镜象的内容可选，如只是事务日志，或服务器上 所有内容，等等。
DBMS级的镜像技术
对等复制：是理想的复制方式。各场地DB地位平等，可互相 复制数据。用户可在任一场地读取/更新公共数据，DBMS应将更新 数据复制到所有副本。
数据库复制的三种方式：对等(peer-to-peer)复制、主从 (master/slave)复制和级联(cascade)复制。
主从复制：数据从主DB复制到从DB。只能主DB更新数据， 从DB供用户读数据。当主场地出现故障时，应用可转到某从BD。
级联复制: 从主DB复制来的数据又从该DB复制到其他DB。级 联复制可平衡当前各种数据需求对网络流量的压力。
双数据库镜像:DBMS为避免磁盘介质故障，提供了数据库镜 像，由DBMS根据DBA要求，自动将整个DB或其中关键数据复制 到另一个磁盘上。当主DB更新时，DBMS自动将复制更新后的数 据。出现介质故障时，可由镜像磁盘提供应用服务，并进行数据库
恢复。
设备级的数据库恢复技术
NOS/OS级的可靠性技术：镜像磁盘（Mirroring Disk）、双工 磁盘（Duplex Disk）、镜像服务器（Mirroring Server）、群集 （Cluster）系统。 方法：利用多副本互为备份、恢复
数据库镜像的优缺点
优点：可提高数据库的可用性。
① 在介质故障时，不需关闭系统和重装后援副本，
保证“不间断”地恢复；
② 便于并发操作，当主数据库的某个对象被加排它
锁时，其它应用可以读镜像数据库。
缺点：
① 由于频繁地复制数据，会降低系统的运行效率；
② 使用更多的磁盘设备。