《Oracle数据库的事务管理与故障恢复技术分析报告》由会员分享，可在线阅读，更多相关《Oracle数据库的事务管理与故障恢复技术分析报告（10页珍藏版）》请在金锄头文库上搜索。
1、. . . . .Oracle数据库的事务管理与故障恢复技术分析Oracle事务管理技术与故障恢复技术的分析 Oracle是一个最早商品化的关系型数据库管理系统，也是目前最流行的关系型数据库管理系统，被越来越多的用户在信息系统管理、企业数据处理、 Internet、电子商务网站等领域作为应用数据的后台处理系统。Oracle作为一个通用的数据库管理系统，不仅具有完整的数据管理功能，还是一个分 布式数据库系统，支持各种分布式功能，特别是支持Internet应用。作为一个应用开发环境，Oracle提供了一套界面友好、功能齐全的数据库开发工 具。Oracle使用PL/SQL语言执行各种操作，具有可开放
2、性、可移植性、可伸缩性等功能。特别是在Oracle 8i中，支持面向对象的功能，如支持类、方法、属性等，使得Oracle 产品成为一种对象/关系型数据库管理系统。目前最新版本是Oracle 11g。本文将立足于对Oracle数据库管理系统的细致解读， 对Oracle的事务管理技术以及故障恢复技术进行分析讲述。1 Oracle的事务管理技术目 前的数据库系统中大多数都是开放的、允许多个用户共享的，并且存在多用户同时并发地访问、存取数据库中的相同数据的情况，如果DBMS不能对这些并发执行 的操作进行准确处理和控制，就有可能造成不正确的结果，进而破坏数据的完整性和一致性。同时，由于网络、机器故障以及
3、应用程序的执行的错误使可能正在执行 的数据存取操作发生意料之外的中断，也有可能使数据库中的数据受到破坏。因此，设计一个应用系统必须能够对并发执行的操作进行很好地控制，以及当出现执行 中断时，系统能够使数据库恢复到一个正确的状态。事务管理技术就是保证共享数据的并发访问一致性和失效恢复正确性的关键技术。1.1 Oracle中的事务介绍事务是DBMS的执行单位，它是由有限的数据库操作序列组成，但不是任意数据库操作序列都能成为事务。一般要求事务具有以下4个特性，也就是ACID特性，ACID特性描述了事务处理的规则。下面是这4个特性:（1）执行的原子性。在Oracle系统中，事务处理具有原子性。换句话说
4、，或者提交所有的工作，或者什么工作都不提交；（2） 功能上的保持一致性。这是非常重要的事务处理特性，任何事务处理都会将数据库从一种逻辑 上的一致状态转变为另一种逻辑上的一致状态。这就是说，在事务处理开始之前，数据库中的所有数据都会满足已经施加给数据库的业务规则(约束)。与此相似， 当提交了事务处理之后，数据库仍然会满足施加的所有业务规则；（3） 彼此的隔离性。隔离性是数据库允许对其中数据进行并发修改和读取的能力。隔离性不仅可用于防止其他事务处理受到当前事务处理的干扰，而且也可以防止当前事 务处理受到其他事务处理的干扰；（4）作用的持久性。持久性是数据库提供的最重要的特性之一。它可以确保一旦事务
5、处理提交之后，它的改变就会永久生效。它 们不会由于系统故障或错误而消失。数据库通过在线重做日志(也称为事务处理日志)可以确保当系统发生故障或崩溃时，能够提供复原数据所需的全部信息。1.2 Oracle 的事务管理1.2.1 Oracle的事务处理概述Oracle 中的一个重要概念就是没有“开始事务处理”的语句。用户不能显式地开一个事务处理。事务处理会隐式地开始与第一条修改数据的语句，或者一些要求事务处理的 场合。使用commit或rollback语句将会显式地终止事务处理。事务处理具有原子性，即要么所有的语句都成功执行，要么所有语句都不能成功执行。Oracle提供了许多事务处理控制语句，用户可
6、以用这些语句来控制这种行为。主要的事务处理控制语句包括：commit、rollback、savepoint、rollback to savepoint、set transaction以及set constraints语句等。下面通过这几条语句的阐述来了解Oracle的事务管理技术。commit处理：在事务处理的最简单的形式中，用户只需使用SQL的commit命令即可。提交会结束用户的事务处理，并且使用户已经执行的任何改变永久生效。rollback 处理：回滚可以允许用户撤销其工作。当应用中出现错误，或运行程序的终端用户决定不保存其所做的改变时，可能需要进行回滚。如果不能够回滚错误或用户命 令，
7、就无法支持数据库中的事务处理。在回滚处理最简单的形式中，只需使用rollback。与提交不同，回滚事务处理的时间是所改变数据量的函数。这是可 以预料的，因为回滚必须在物理上撤销用户已经完成的工作。savepoint：savepoint可以允许用户在事务处理中建立标记点。用户可以在单独的事务处理中拥有多个保存点。保存点是很有用的事务处理特性，它们可以让用户将单独的大规模事务处理分割成一系列较小的部分。set transaction：set transaction语句可以使用户设置事务处理的各种属性，必须是事务处理中第一个使用的语句。set transaction语句的作用域只是当前的事务处理。只
8、要用户进行了提交或回滚，set transaction语句的结果才会完整。set constraint：在Oracle中，约束可以在DML语句执行之后立即生效，也可以延迟到事务处理提交时才生效。set constraint语句可以允许用户在事务处理中设置延迟约束的强制模式。1.2.2 Oracle事务的核心技术并发控制技术概述数 据库是一个共享资源，可为多个应用程序所共享。这些程序可串行运行，但在许多情况下，由于应用程序涉及的数据量可能很大，常常会涉及输入输出的交换。为 了有效地利用数据库资源，可能多个程序或一个程序的多个进程并行地运行，这就是数据库的并行操作。在多用户数据库环境中，多个用户程
9、序可并行地存取数据 库，如果不对并发操作进行控制，会存取不正确的数据，或破坏数据库数据的一致性。为防止出现这些数据的不一致性，必须使并发的事务串行化， 使各个事务都按某种次序来执行，避免相互干扰，这就是并发控制所要解决的问题。在Oracle数据库中所提供的并发控制机制是利用封锁机制来实现的。在多 用户数据库中一般采用某些数据封锁来解决并发操作中的数据一致性和完整性问题。封锁是防止存取同一资源的用户之间破坏性的干扰的机制，干扰 是指不正确地修改数据或不正确地更改数据结构。在多用户数据库中使用两种封锁：排它(专用)封锁和共享封锁。排它封锁禁止相关资源的共享，如果事务以排它 方式封锁一资源，仅仅该事
10、务可更改该资源，直至释放排它封锁。共享封锁允许相关资源可以共享，几个用户可同时读取同一数据，几个事务可在同一资源上获取共 享封锁。共享封锁比排它封锁具有更高的数据并行性。 2 Oracle的故障恢复技术使用数据库的过程中难免出现人为故障(误操作及恶意操作)及计算机系统的故障(硬件故障、软件故障、网络故障、进程故障和系统故障等)等，这都会影响到数据库系统的操作及数据库中数据的正确性和完整性，甚至破坏数 据库，使数据库中部分或全部数据丢失。这就会需要对数据库进行重构，也就是数据库恢复。数据恢复是指把意外改变或意外删除的数据恢复为原貌，恢复过程大致 可以分为复原(Restore)与恢复(Recove
11、r)过程。ORACLE数据库使用几种结构对可能故障来保护数据：数据库后备、日志、回滚段、控制文 件、系统修改号(SCN)、检查点。下面着重介绍Oracle的日志技术以及利用日志文件实现数据库故障恢复，简要介绍Oracle的检查点技术。2.1 Oracle的日志技术2.1.1 事务日志概述数据库的事务日志是Oracle保护机制中至关重要的组成部分，其任务是随时记录数据库中正在进行的数据变化，一旦有突发故障，所有已被提交的工作均可完全恢复。数据库的恢复操作中重要的1个环节就是依赖事务日志中信息，重建或重做丢失事务中已被提交的各种改变。事 务是数据库执行数据处理的基本单位。在执行一个事务时，如果我们
12、把该事务处理从开始到结束所涉及的操作信息(包括事务涉及的数据库对象以及在这个对象上执 行的操作类别、操作前后的数据映像、事务的状态等信息)作为一个特殊的数据项以二进制的方式记录下来，这就是事务日志，事务日志是以事务为单位进行记录 的，每一个日志项(Logitem)详细记录了事务处理的足够信息，以确保系统在必要的时候能够重演(Redo)该事务。如果说数据库中的Data是我们 的直接数据或“一次数据”，那么数据库中的日志则是我们的间接数据或“二次数据”，它记录着数据的变更信息。从另外一个角度看，数据反映的是事务处理操作 的结果，而日志记录的则是事务处理操作的过程，有了这样的历史变更过程，在一定条件
13、下我们就可以依次“重演”这个过程(即重新执行事务处理的操作)，以达 到恢复数据的目的。可以说事务日志是记录数据库系统数据操作的“流水账”，目前绝大多数数据库系统都支持对事务日志的记录。Oracle的日志文件有两类：一类是联机日志文件，即Oracle用于管理数据库的事务日志文件；另一类称为归档日志，是不活动联机文件的备份，这种日志文件主要用于数据库的恢复。日志中记录的信息包括：数据库的逻辑更改、用户的误操作、事后审计、数据库的更改历史、更改类型（INSERT、UPDATE、DELETE、DDL等）、更改对应的SCN号、以及执行这些操作的用户信息等。2.1.2 基于日志的数据库恢复无 论何种原因故
14、障导致Oracle数据库不能正常启动(即不能进入Open状态)，此时即需要执行数据库恢复(Recovery)。典型的数据库恢复过程需 要如下3个阶段：(1)Restore：选择某个历史备份作为恢复的起点，即首先将数据恢复至备份时刻的状态；(2)Roll Forward：利用归档日志和联机日志依次重做自备份时刻以来的事务；(3)Roll Back：在故障时刻前附近的一些事务，有些还未来得及提交(Commit)，但由于系统内部的Checkpoint事件的触发导致已经写入联机日志，这 部分事务需要利用数据映像(Before Image)进行必要的回滚。如果这3个阶段的操作都能够顺利进行，则可以将数据
15、库毫无损失地恢复到损坏前一时刻的状态，即所谓的完全数据库恢复 (Complete Recovery)，如果这个恢复过程在第二、三阶段由于某种原因中途结束，则数据库只能恢复到过去的某个时问点，即不完全恢复(Incomplete Recovery)。下图给出了Oracle数据库恢复的典型示例。假设系统在T7时刻出现故障导致Oracle数据库停止运行，数据库分别在T1、T3、T6有3次历史备份，由图示可知，归档日志中包含了T2至T5时间段的事务日志，联机重做日志中包含了T4至T7时间段的事务日志。下面说明恢复过程：(1)选择T3时刻的备份作为恢复的起点；(2)利用归档日志重做T3至T4(或T5)时间
16、段的事务；(3)利用联机重做日志重做T4(或T5)至T7时间段的事务，将数据库恢复到故障时刻，实现Complete Recovery。日志中记录的事务处理信息是与当时的数据库状态相关联的，离开了特定的数据状态，数据操作也就失去了意义。因此事务日志的重演是有前提的：一是数据库首先必须处于某一时刻点的完整状态(通常由数据库备份来实现)。只有处于这个状态，在这一时间点之后的事务才有重新运行的基础；二是重新运 行的事务处理必须严格按照原来的时间顺序进行，只有这样，才能实现逐步推演，因为实际的数据库操作其后一步操作总是依赖于前一步操作的结果。正因为此，数 据库的事务日志必须连续地保存，如果某个时间段的事务日志损坏或丢失，则此时间段之后的日志也就失去了存在的意义。2.1.3 Oracle
