ORACLE数据库事务处理和故障恢复

一、并发控制


　　数据库是一个共享资源，可为多个应用程序所共享。这些程序可串行运行，但在许多情况下，由于应用程序涉及的数据量可能很大，常常会涉及输入/输出的交换。为了有效地利用数据库资源，可能多个程序或一个程序的多个进程并行地运行，这就是数据库的并行操作。在多用户数据库环境中，多个用户程序可并行地存取数据库，如果不对并发操作进行控制，会存取不正确的数据，或破坏数据库数据的一致性。
　　
1） 数据库不一致的类型
　　◎ 不一致性
　　在一事务期间，其它提交的或未提交事务的修改是显然的，以致由查询所返回的数据集不与任何点相一致。
　　◎ 不可重复读
　　在一个事务范围内，两个相同查询将返回不同数据，由于查询注意到其它提交事务的修改而引起。
　　◎ 读脏数据
　　如果事务T1将一值（A）修改，然后事务T2读该值，在这之后T1由于某种原因撤销对该值的修改，这样造成T2读取的值是脏的。
　　◎ 丢失更改
　　在一事务中一修改重写另一事务的修改。
　　◎ 破坏性的DDL操作
　　在一用户修改一表的数据时，另一用户同时更改或删除该表。

　　2）封锁
　　在多用户数据库中一般采用某些数据封锁来解决并发操作中的数据一致性和完整性问题。封锁是防止存取同一资源的用户之间破坏性的干扰的机制，该干扰是指不正确地修改数据或不正确地更改数据结构。
　　在多用户数据库中使用两种封锁：排它（专用）封锁和共享封锁。排它封锁禁止相关资源的共享，如果一事务以排它方式封锁一资源，仅仅该事务可更改该资源，直至释放排它封锁。共享封锁允许相关资源可以共享，几个用户可　　同时读同一数据，几个事务可在同一资源上获取共享封锁。共享封锁比排它封锁具有更高的数据并行性。
在多用户系统中使用封锁后会出现死锁，引起一些事务不能继续工作。当两个或多个用户彼此等待所封锁数据时可发生死锁。

　　3） ORACLE多种一致性模型。
　　ORACLE利用事务和封锁机制提供数据并发存取和数据完整性。在一事务内由语句获取的全部封锁在事务期间被保持，防止其它并行事务的破坏性干扰。一个事务的SQL语句所作的修改在它提交之后所启动的事务中才是可见的。在一事务中由语句所获取的全部封锁在该事务提交或回滚时被释放。
　　ORACLE在两个不同级上提供读一致性：语句级读一致性和事务级一致性。ORCLE总是实施语句级读一致性，保证单个查询所返回的数据与该查询开始时刻相一致。所以一个查询从不会看到在查询执行过程中提交的其它事务所作的任何修改。为了实现语句级读一致性，在查询进入执行阶段时，在注视SCN的时候为止所提交的数据是有效的，而在语句执行开始之后其它事务提交的任何修改，查询将是看不到的。
　　ORACLE允许选择实施事务级读一致性，它保证在同一事务内所有查询的数据

　　4）封锁机制
　　ORACLE自动地使用不同封锁类型来控制数据的并行存取，防止用户之间的破坏性干扰。ORACLE为一事务自动地封锁一资源以防止其它事务对同一资源的排它封锁。在某种事件出现或事务不再需要该资源时自动地释放。
　　ORACLE将封锁分为下列类：
　　◎ 数据封锁：数据封锁保护表数据，在多个用户并行存取数据时保证数据的完整性。数据封锁防止相冲突的DML和DDL操作的破坏性干扰。DML操作可在两个级获取数据封锁：指定行封锁和整个表封锁，在防止冲突的DDL操作时也需表封锁。当行要被修改时，事务在该行获取排它数据封锁。表封锁可以有下列方式：行共享、行排它、共享封锁、共享行排它和排它封锁。
　　◎ DDL封锁（字典封锁）
　　DDL封锁保护模式对象（如表）的定义，DDL操作将影响对象，一个DDL语句隐式地提交一个事务。当任何DDL事务需要时由ORACLE自动获取字典封锁，用户不能显式地请求DDL封锁。在DDL操作期间，被修改或引用的模式对象被封锁。
　　◎ 内部封锁：保护内部数据库和内存结构，这些结构对用户是不可见的。

　　5）手工的数据封锁
　　下列情况允许使用选择代替ORACLE缺省的封锁机制：
　　◎ 应用需要事务级读一致或可重复读。
　　◎ 应用需要一事务对一资源可排它存取，为了继续它的语句，具有对资源排它存取的事务不必等待其它事务完成。
　　ORACLE自动封锁可在二级被替代：事务级各系统级。
　　◎ 事务级：包含下列SQL语句的事务替代ORACLE缺省封锁：LOCK TABLE命令、SELECT…FOR UPDATE命令、具有READ ONLY选项的SET TRANSACTIN命令。由这些语句所获得的封锁在事务提交或回滚后所释放。
　　◎ 系统级：通过调整初始化参数SERIALIZABLE和REO-LOCKING，实例可用非缺省封锁启动。该两参数据的缺省值为：
　　SERIALIZABLE=FALSE
　　ORW-LOCKING=ALWAYS

二、数据库后备和恢复


　　当我们使用一个数据库时，总希望数据库的内容是可靠的、正确的，但由于计算机系统的故障（硬件故障、软件故障、网络故障、进程故障和系统故障）影响数据库系统的操作，影响数据库中数据的正确性，甚至破坏数据库，使数据库中全部或部分数据丢失。因此当发生上述故障后，希望能重新建立一个完整的数据库，该处理称为数据库恢复。恢复子系统是数据库管理系统的一个重要组成部分。恢复处理随所发生的故障类型所影响的结构而变化。

　　1） 恢复数据库所使用的结构
　　ORACLE数据库使用几种结构对可能故障来保护数据：数据库后备、日志、回滚段和控制文件。
　　数据库后备是由构成ORACLE数据库的物理文件的操作系统后备所组成。当介质故障时进行数据库恢复，利用后备文件恢复毁坏的数据文件或控制文件。
　　日志，每一个ORACLE数据库实例都提供，记录数据库中所作的全部修改。一个实例的日志至少由两个日志文件组成，当实例故障或介质故障时进行数据库部分恢复，利用数据库日志中的改变应用于数据文件，修改数据库数据到故障出现的时刻。数据库日志由两部分组成：在线日志和归档日志。
　　每一个运行的ORACLE数据库实例相应地有一个在线日志，它与ORACLE后台进程LGWR一起工作，立即记录该实例所作的全部修改。在线日志由两个或多个预期分配的文件组成，以循环方式使用。
　　归档日志是可选择的，一个ORACLE数据库实例一旦在线日志填满后，可形成在线日志的归档文件。归档的在线日志文件被唯一标识并合成归档日志。
　　回滚段用于存储正在进行的事务（为未提交的事务）所修改值的老值，该信息在数据库恢复过程中用于撤消任何非提交的修改。
　　控制文件，一般用于存储数据库的物理结构的状态。控制文件中某些状态信息在实例恢复和介质恢复期间用于引导ORACLE。

　　2） 在线日志
　　一个ORACLE数据库的每一实例有一个相关联的在线日志。一个在线日志由多个在线日志文件组成。在线日志文件填入日志项，日志项记录的数据用于重构对数据库所作的全部修改。后台进程LGWR以循环方式写入在线日志文件。当当前的在线日志文件写满后，LGWR写入到下一可用在线日志文件当最后一个可用的在线日志文件的检查点已完成时即可使用。如果归档不实施，一个已填满的在线日志文件一当包含该在线日志文件的检查点完成，该文件已被归档后即可使用。在任何时候，仅有一个在线日志文件被写入存储日志项，它被称为活动的或当前在线日志文件，其它的在线日志文件为不活动的在线日志文件。
　　ORCLE结束写入一在线日志文件并开始写入到另一个在线日志文件的点称为日志开关。日志开关在当前在线日志文件完全填满，必须继续写入到下一个在线日志文件时总出现，也可由DBA强制日志开关。每一日志开关出现时，每一在线日志文件赋给一个新的日志序列号。如果在线日志文件被归档，在归档日志文件中包含有它的日志序列号。
ORACLE后台进程DBWR（数据库写）将SGA中所有被修改的数据库缓冲区（包含提交和未提交的）写入到数据文件，这样的事件称为出现一个检查点。因下列原因实现检查点：
　　◎ 检查点确保将内存中经常改变的数据段块每隔一定时间写入到数据文件。由于DBWR使用最近最少使用算法，经常修改的数据段块从不会作为最近最少使用块，如果检查点不出现，它从不会写入磁盘。
　　◎ 由于直至检查点时所有的数据库修改已记录到数据文件，先于检查点的日志项在实例恢复时不再需要应用于数据文件，所以检查点可加快实例恢复。
　　虽然检查点有一些开销，但ORACLE既不停止活动又不影响当前事务。由于DBWR不断地将数据库缓冲区写入到磁盘，所以一个检查点一次不必写许多数据块。一个检查点保证自前一个检查点以来的全部修改数据块写入到磁盘。检查点不管填满的在线日志文件是否正在归档，它总是出现。如果实施归档，在LGWR重用在线日志文件之前，检查点必须完成并且所填满的在线日志文件必须被归档。
　　检查点可对数据库的全部数据文件出现（称为数据库检查点），也可对指定的数据文件出现。下面说明一下什么时候出现检查点及出现什么情况：
　　◎ 在每一个日志开关处自动地出现一数据库检查点。如果前一个数据库检查点正在处理，由日志开关实施的检查点优于当前检查点。
　　◎ 初始化参数据LOG-CHECKPOINT-INTERVAL设置所实施的数据库检查点，当预定的日志块数被填满后（自最后一个数据库检查点以来），实施一数据库检查点。另一个参数LOG-CHECKPOINT-TIMEOUT可设置自上一个数据库检查点开始之后指定秒数后实施一数据库检查点。这种选择对使用非常大的日志文件时有用，它在日志开头之间增加检查点。由初始化参数所启动的数据库检查点只有在前一个检查点完成后才能启动。
　　◎ 当一在线表空间开始后备时，仅对构成该空间的数据文件实施一检查点，该检查点压倒仍在进行中的任何检查点。
　　◎ 当DBA使一表空间离线时，仅对构成该表空间的在线文件实施一检查点。
　　◎ 当DBA以正常或立即方式关闭一实例时，ORACLE在实例关闭之前实施一数据库检查点，该检查点压倒任何运行检查点。
　　◎ DBA可要求实施一数据库检查点，该检查点压倒任何运行检查点。

　　检查点机制：当检查点出现时，检查点后台进程记住写入在线文件的下一日志行的位置，并通知数据库写后台进程将SGA中修改的数据库缓冲区写入到磁盘上的数据文件。然后由CKPT修改全部控制文件和数据文件的标头，反映该最后检查点。当检查点不发生，DBWR当需要时仅将最近最少使用的数据库缓冲区写入磁盘，为新数据准备缓冲区。
　　镜象在线日志文件：为了安全将实例的在线日志文件镜象到它的在线日志文件ORACLE提供镜象功能。当具有镜象在线日志文件时，LGWR同时将同一日志信息写入到多个同样的在线日志文件。日志文件分成组，每个组中的日志文件称为成员，每个组中的全部成员同时活动，由LGWR赋给相同的日志序列号。如果使用镜象在线日志，则可建立在线日志文件组，在组中的每一成员要求是同一大小。
　　镜象在线日志的机制：LGWR总是寻找组的全部成员，对一组的全部成员并行地写，然后转换到下一组的全部成员，并行地写。


　　每个数据库实例有自己的在线日志组，这些在线日志组可以是镜象的或不是，称为实例的在线日志线索。在典型配置中，一个数据库实例存取一个ORACLE数据库，于是仅一个线索存在。然而在运行ORACLE并行服务器中，两个或多个实例并行地存取单个数据库，在这种情况下，每个实例有自己的线索。

3） 归档日志


　　ORACLE要将填满的在线日志文件组归档时，则要建立归档日志，或称离线日志。其对数据库后备和恢复有下列用处：
　　◎ 数据库后备以及在线和归档日志文件，在操作系统或磁盘故障中可保证全部提交的事务可被恢复。
　　◎ 在数据库打开时和正常系统使用下，如果归档日志是永久保持，在线后备可以进行和使用。
　　如果用户数据库要求在任何磁盘故障的事件中不丢失任何数据，那么归档日志必须要存在。归档已填满的在线日志文件可能需要DBA执行额外的管理操作。
　　归档机制：决定于归档设置，归档已填满的在线日志组的机制可由ORACLE后台进程ARCH自动归档或由用户进程发出语句手工地归档。当日志组变为不活动、日志开关指向下一组已完成时，ARCH可归档一组，可存取该组的任何或全部成员，完成归档组。在线日志文件归档之后才可为LGWR重用。当使用归档时，必须指定归档目标指向一存储设备，它不同于个有数据文件、在线日志文件和控制文件的设备，理想的是将归档日志文件永久地移到离线存储设备、如磁带。
　　数据库可运行在两种不同方式下：NOARCHIVELOG方式或ARCHIVELOG方式。数据库在NOARCHIVELOG方式下使用时，不能进行在线日志的归档。在该数据库控制文件指明填满的组不需要归档，所以一当填满的组成为活动，在日志开关的检查点完成，该组即可被LGWR重用。在该方式下仅能保护数据库实例故障，不能保护介质（磁盘）故障。利用存储在在线日志中的信息，可实现实例故障恢复。
　　如果数据库在ARCHIVELOG方式下,可实施在线日志的归档。在控制文件中指明填满的日志文件组在归档之前不能重用。一旦组成为不活动，执行归档的进程立即可使用该组。
　　在实例起动时，通过参数LOG-ARCHIVE-START设置，可启动ARCH进程，否则ARCH进程在实例启动时不能被启动。然而DBA在凭借时候可交互地启动或停止自动归档。 一旦在线日志文件组变为不活动时，ARCH进程自动对它归档。
如果数据库在ARCHIVELOG方式下运行，DBA可手工归档填满的不活动的日志文件组，不管自动归档是可以还是不可以。

4） 数据库后备


　　不管为ORACLE数据库设计成什么样的后备或恢复模式，数据库数据文件、日志文件和控制文件的操作系统后备是绝对需要的，它是保护介质故障的策略部分。操作系统后备有完全后备和部分后备
　　◎ 完全后备：一个完全后备将构成ORACLE数据库的全部数据库文件、在线日志文件和控制文件的一个操作系统后备。一个完全后备在数据库正常关闭之后进行，不能在实例故障后进行。在此时，所有构成数据库的全部文件是关闭的，并与当前点相一致。在数据库打开时不能进行完全后备。由完全后备得到的数据文件在任何类型的介质恢复模式中是有用的。
　　◎ 部分后备：部分后备为除完全后备外的任何操作系统后备，可在数据库打开或关闭下进行。如单个表空间中全部数据文件后备、单个数据文件后备和控制文件后备。部分后备仅对在ARCHIVELOG方式下运行数据库有用，因为存在的归档日志，数据文件可由部分后备恢复。在恢复过程中与数据库其它部分一致。

5） 数据库恢复


　　◎ 实例故障的恢复
　　当实例意外地（如掉电、后台进程故障等）或预料地（发出SHUTDOUM ABORT语句）中止时出现实例故障，此时需要实例恢复。实例恢复将数据库恢复一故障之前的事务一致状态。如果在在线后备发现实例故障，则需介质恢复。在其它情况ORACLE在下次数据库起动时（对新实例装配和打开），自动地执行实例恢复。如果需要，从装配状态变为打开状态，自动地激发实例恢复，由下列处理：
　　（1） 为了解恢复数据文件中没有记录的数据，进行向前滚。该数据记录在在线日志，包括对回滚段的内容恢复。
　　（2） 回滚未提交的事务，按步1重新生成回滚段所指定的操作。
　　（3） 释放在故障时正在处理事务所持有的资源。
　　（4） 解决在故障时正经历一阶段提交的任何悬而未决的分布事务。
　　◎ 介质故障的恢复
　　介质故障是当一个文件、一个文件的部分或一磁盘不能读或不能写时出现的故障。介质故障的恢复有两种形式，决定于数据库运行的归档方式。
　　◎ 如果数据库是可运行的，以致它的在线日志仅可重用但不能归档，此时介质恢复为使用最新的完全后备的简单恢复。在完全后备执行的工作必须手工地重作。
　　◎ 如果数据库可运行，其在线日志是被归档的，该介质故障的恢复是一个实际恢复过程，重构受损的数据库恢复到介质故障前的一个指定事务一致状态。
　　◎ 不管哪种形式，介质故障的恢复总是将整个数据库恢复到故障之前的一个事务一致状态。如果数据库是在ARCHIVELOG方式运行，可有不同类型的介质恢复：完全介质恢复和不完全介质恢复。
　　完全介质恢复可恢复全部丢失的修改。仅当所有必要的日志可用时才可能。有不同类型的完全介质恢复可使用，其决定于毁坏文件和数据库的可用性。例：
　　◎ 关闭数据库的恢复。当数据库可被装配却是关闭的，完全不能正常使用，此时可进行全部的或单个毁坏数据文件的完全介质恢复。
　　◎ 打开数据库的离线表空间的恢复。当数据库是打开的，完全介质恢复可以处理。未损的数据库表空间是在线的可以使用，而受损耗捕空间是离线的，其所有数据文件作为恢复的单位。
　　◎ 打开数据库的离线表间的单个数据文件的恢复。当数据库是打开的，完全介质恢复可以处理。未损的数据库表空间是在线的可以使用，而所损的表空间是离线的，该表空间的指定所损的数据文件可被恢复。
　　◎ 使用后备的控制文件的完全介质恢复。当控制文件所有拷贝由于磁盘故障而受损时，可进行介质恢复而不丢失数据。
　　不完全介质恢复是在完全介质恢复不可能或不要求时进行的介质恢复。重构受损的数据库，使其恢复介质故障前或用户出错之前的一个事务一致性状态。不完全介质恢复有不同类型的使用，决定于需要不完全介质恢复的情况，有下列类型：基于撤消、基于时间和基于修改的不完全恢复。
　　基于撤消恢复：在某种情况，不完全介质恢复必须被控制，DBA可撤消在指定点的操作。基于撤消的恢复地在一个或多个日志组（在线的或归档的）已被介质故障所破坏，不能用于恢复过程时使用，所以介质恢复必须控制，以致在使用最近的、未损的日志组于数据文件后中止恢复操作。
　　基于时间和基于修改的恢复：如果DBA希望恢复到过去的某个指定点，不完全介质恢复地理想的。可在下列情况下使用：
　　◎ 当用户意外地删除一表，并注意到错误提交的估计时间，DBA可立即关闭数据库，恢复它到用户错误之前时刻。
　　◎ 由于系统故障，一个在线日志文件的部分被破坏，所以活动的日志文件突然不可使用，实例被中止，此时需要介质恢复。在恢复中可使用当前在线日志文件的未损部分，DBA利用基于时间的恢复，一旦有将效的在线日志已应用于数据文件后停止恢复过程。
　　在这两种情况下，不完全介质恢复的终点可由时间点或系统修改号（SCN）来指定。