ORACLE培训教程(2)-数据库的安全性、完整性、并发控制和恢复

　　为了保证数据库数据的安全可靠性和正确有效，DBMS必须提供统一的数据保护功能。数据保护也为数据控制，主要包括数据库的安全性、完整性、并发控制和恢复。
　　
　　一、 数据库的安全性
　　数据库的安全性是指保护数据库以防止不合法的使用所造成的数据泄露、更改或破坏。计算机系统都有这个问题，在数据库系统中大量数据集中存放，为许多用户共享，使安全问题更为突出。
　　在一般的计算机系统中，安全措施是一级一级设置的。
　　在DB存储这一级可采用密码技术，当物理存储设备失窃后，它起到保密作用。在数据库系统这一级中提供两种控制：用户标识和鉴定，数据存取控制。
　　在ORACLE多用户数据库系统中，安全机制作下列工作：
　　l 防止非授权的数据库存取；
　　l 防止非授权的对模式对象的存取；
　　l 控制磁盘使用；
　　l 控制系统资源使用；
　　l 审计用户动作。
　　
　　数据库安全可分为二类：系统安全性和数据安全性。
　　系统安全性是指在系统级控制数据库的存取和使用的机制，包含：
　　l 有效的用户名/口令的组合；
　　l 一个用户是否授权可连接数据库；
　　l 用户对象可用的磁盘空间的数量；
　　l 用户的资源限制；
　　l 数据库审计是否是有效的；
　　l 用户可执行哪些系统操作。
　　
　　数据安全性是指在对象级控制数据库的存取和使用的机制，包含：
　　l 哪些用户可存取一指定的模式对象及在对象上允许作哪些操作类型。
　　在ORACLE服务器上提供了一种任意存取控制，是一种基于特权限制信息存取的方法。用户要存取一对象必须有相应的特权授给该用户。已授权的用户可任意地可将它授权给其它用户，由于这个原因，这种安全性类型叫做任意型。
　　
　　ORACLE利用下列机制管理数据库安全性：
　　l 数据库用户和模式；
　　l 特权；
　　l 角色；
　　l 存储设置和空间份额；
　　l 资源限制；
　　l 审计。
　　
　　1． 数据库的存取控制
　　ORACLE保护信息的方法采用任意存取控制来控制全部用户对命名对象的存取。用户对对象的存取受特权控制。一种特权是存取一命名对象的许可，为一种规定格式。
　　ORACLE使用多种不同的机制管理数据库安全性，其中有两种机制：模式和用户。模式为模式对象的集合，模式对象如表、视图、过程和包等。第一数据库有一组模式。
　　每一ORACLE数据库有一组合法的用户，可存取一数据库，可运行一数据库应用和使用该用户各连接到定义该用户的数据库。当建立一数据库用户时，对该用户建立一个相应的模式，模式名与用户名相同。一旦用户连接一数据库，该用户就可存取相应模式中的全部对象，一个用户仅与同名的模式相联系，所以用户和模式是类似的。
　　
　　用户的存取权利受用户安全域的设置所控制，在建立一个数据库的新用户或更改一已有用户时，安全管理员对用户安全域有下列决策：
　　l 是由数据库系统还是由操作系统维护用户授权信息。
　　l 设置用户的缺省表空间和临时表空间。
　　l 列出用户可存的表空间和在表空间中可使用空间份额。
　　l 设置用户资源限制的环境文件，该限制规定了用户可用的系统资源的总量。
　　l 规定用户具有的特权和角色，可存取相应的对象。
　　
　　每一个用户有一个安全域，它是一组特性，可决定下列内容：
　　l 用户可用的特权和角色；
　　l 用户可用的表空间的份额；
　　l 用户的系统资源限制。
　　
　　1） 用户鉴别：
　　为了防止非授权的数据库用户的使用，ORACLE提供二种确认方法
　　操作系统确认和相应的ORACLE数据库确认。
　　如果操作系统允许，ORACLE可使用操作系统所维护的信息来鉴定用户。由操作系统鉴定用户的优点是：
　　l 用户可更方便地连接到ORACLE，不需要指定用户名和口令。
　　l 对用户授权的控制集中在操作系统，ORACLE不需要存储和管理用户口令。然而用户名在数据库中仍然要维护。
　　l 在数据库中的用户名项和操作系统审计跟踪相对应。
　　
　　ORACLE数据库方式的用户确认：ORACLE利用存储在数据库中的信息可鉴定试图接到数据库的一用户，这种鉴别方法仅当操作系统不能用于数据库用户鉴别时才使用。当用户使用一ORACLE数据库时执行用户鉴别。每个用户在建立时有一个口令，用户口令在建立对数据库连接时使用，以防止对数据库非授权的使用。用户的口令以密码的格式存储在数据库数据字典中，用户可随时修改其口令。
　　
　　2） 用户的表空间设置和定额
　　关于表空间的使用有几种设置选择：
　　l 用户的缺省表空间；
　　l 用户的临时表空间；
　　l 数据库表空间的空间使用定额。
　　
　　3） 用户资源限制和环境文件
　　用户可用的各种系统资源总量的限制是用户安全域的部分。利用显式地设置资源限制；安全管理员可防止用户无控制地消耗宝贵的系统资源。资源限制是由环境文件管理。一个环境文件是命名的一组赋给用户的资源限制。另外ORACLE为安全管理员在数据库级提供使能或使不能实施环境文件资源限制的选择。
　　ORACLE可限制几种类型的系统资源的使用，每种资源可在会话级、调用级或两者上控制。在会话级：每一次用户连接到一数据库，建立一会话。每一个会话在执行SQL语句的计算机上耗费CPU时间和内存量进行限制。对ORACLE的几种资源限制可在会话级上设置。如果会话级资源限制被超过，当前语句被中止（回滚），并返回指明会话限制已达到的信息。此时，当前事务中所有之前执行的语句不受影响，此时仅可作COMMIT、ROLLBACK或删除对数据库的连接等操作，进行其它操作都将出错。
　　在调用级：在SQL语句执行时，处理该语句有好几步，为了防止过多地调用系统，ORACLE在调用级可设置几种资源限制。如果调用级的资源限制被超过，语句处理被停止，该 语句被回滚，并返回一错误。然而当前事务的已执行所用语句不受影响，用户会话继续连接。
　　
　　有下列资源限制：
　　l 为了防止无控制地使用CPU时间，ORACLE可限制每次ORACLE调用的CPU时间和在一次会话期间ORACLE调用所使用的CPU的时间，以0.01秒为单位。
　　l 为了防止过多的I/O，ORACLE可限制每次调用和每次会话的逻辑数据块读的数目。
　　l ORACLE在会话级还提供其它几种资源限制。
　　
　　每个用户的并行会话数的限制；
　　会话空闲时间的限制，如果一次会话的ORACLE调用之间时间达到该空闲时间，当前事务被回滚，会话被中止，会话资源返回给系统；
　　每次会话可消逝时间的限制，如果一次会话期间超过可消逝时间的限制，当前事务被回滚，会话被删除，该会话的资源被释放；
　　每次会话的专用SGA空间量的限制。
　　用户环境文件：
　　用户环境文件是指定资源限制的命名集，可赋给ORACLE数据库的有效的用户。利用用户环境文件可容易地管理资源限制。要使用用户环境文件，首先应将数据库中的用户分类，决定在数据库中全部用户类型需要多少种用户环境文件。在建立环境文件之前，要决定每一种资源限制的值。例如一类用户通常不执行大量逻辑数据块读，那就可将LOGICAL-READS-PER-SESSION和LOGICAL-READS-PER-CALL设置相应的值。在许多情况中决定一用户的环境文件的合适资源限制的最好的方法是收集每种资源使用的历史信息。
　　
　　2． 特权和角色
　　1） 特权：特权是执行一种特殊类型的SQL语句或存取另一用户的对象的权力。有两类特权：系统特权和对象特权。
　　系统特权：是执行一处特殊动作或者在对象类型上执行一种特殊动作的权利。ORACLE有60多种不同系统特权,每一种系统允许用户执行一种特殊的数据库操作或一类数据库操作.
　　系统特权可授权给用户或角色,一般,系统特权全管理人员和应用开发人员,终端用户不需要这些相关功能.授权给一用户的系统特权并具有该 系统特权授权给其他用户或角色.反之,可从那些被授权的用户或角色回收系统特权.
　　对象特权：在指定的表、视图、序列、过程、函数或包上执行特殊动作的权利。对于不同类型的对象,有不同类型的对象特权。对于有些模式对象，如聚集、索引、触发器、数据库链没有相关的对象特权，它们由系统特权控制。
　　对于包含在某用户名的模式中的对象，该用户对这些对象自动地具有全部对象特权，即模式的持有者对模式中的对象具有全部对象特权。这些对象的持有者可将这些对象上的任何对象特权可授权给其他用户。如果被授者包含有GRANT OPTION 授权，那么该被授者也可将其权利再授权给其他用户。
　　
　　2） 角色：为相关特权的命名组，可授权给用户和角色。ORACEL利用角色更容易地进行特权管理。有下列优点：
　　l 减少特权管理，不要显式地将同一特权组授权给几个用户，只需将这特权组授给角色，然后将角色授权给每一用户。
　　l 动态特权管理，如果一组特权需要改变，只需修改角色的特权，所有授给该角色的全部用户的安全域将自动地反映对角色所作的修改。
　　l 特权的选择可用性，授权给用户的角色可选择地使其使能（可用）或使不能（不可用）。
　　l 应用可知性，当一用户经一用户名执行应用时，该数据库应用可查询字典，将自动地选择使角色使能或不能。
　　l 专门的应用安全性，角色使用可由口令保护，应用可提供正确的口令使用权角色使能，达到专用的应用安全性。因用户不知其口令，不能使角色使能。
　　一般，建立角色服务于两个目的：为数据库应用管理特权和为用户组管理特权。相应的角色称为应用角色和用户角色。
　　应用角色是授予的运行一数据库应用所需的全部特权。一个应用角色可授给其它角色或指定用户。一个应用可有几种不同角色，具有不同特权组的每一个角色在使用应用时可进行不同的数据存取。
　　用户角色是为具有公开特权需求的一组数据库用户而建立的。用户特权管理是受应用角色或特权授权给用户角色所控制，然后将用户角色授权给相应的用户。
　　数据库角色包含下列功能：
　　l 一个角色可授予系统特权或对象特权。
　　l 一个角色可授权给其它角色，但不能循环授权。
　　l 任何角色可授权给任何数据库用户。
　　l 授权给一用户的每一角色可以是使能的或者使不能的。一个用户的安全域仅包含当前对该用户使能的全部角色的特权。
　　l 一个间接授权角色（授权给另一角色的角色）对一用户可显式地使其能或使不能。
　　在一个数据库中，每一个角色名必须唯一。角色名与用户不同，角色不包含在任何模式中，所以建立一角色的用户被删除时不影响该角色。
　　ORACLE为了提供与以前版本的兼容性，预定义下列角色：CONNENT、RESOURCE、DBA、EXP-FULL-DATABASE和IMP-FULL-DATABASE。
　　
　　3． 审计
　　审计是对选定的用户动作的监控和记录，通常用于：
　　l 审查可疑的活动。例如：数据被非授权用户所删除，此时安全管理员可决定对该 数据库的所有连接进行审计，以及对数据库的所有表的成功地或不成功地删除进行审计。
　　l 监视和收集关于指定数据库活动的数据。例如：DBA可收集哪些被修改、执行了多少次逻辑的I/O等统计数据。
　　ORACLE支持三种审计类型：
　　l 语句审计，对某种类型的SQL语句审计，不指定结构或对象。
　　l 特权审计，对执行相应动作的系统特权的使用审计。
　　l 对象审计，对一特殊模式对象上的指定语句的审计。
　　ORACLE所允许的审计选择限于下列方面：
　　l 审计语句的成功执行、不成功执行，或者其两者。
　　l 对每一用户会话审计语句执行一次或者对语句每次执行审计一次。
　　l 对全部用户或指定用户的活动的审计。
　　当数据库的审计是使能的，在语句执行阶段产生审计记录。审计记录包含有审计的操作、用户执行的操作、操作的日期和时间等信息。审计记录可存在数据字典表（称为审计记录）或操作系统审计记录中。数据库审计记录是在SYS模式的AUD$表中。
　　
　　
　　二、 数据完整性
　　 它是指数据的正确性和相容性。数据的完整性是为了防止数据库存在不符合主义的数据，防止错误信息输入和输出，即数据要遵守由DBA或应用开发者所决定的一组预定义的规则。ORACLE应用于关系数据库的表的数据完整性有下列类型：
　　l 在插入或修改表的行时允许不允许包含有空值的列，称为空与非空规则。
　　l 唯一列值规则，允许插入或修改的表行在该列上的值唯一。
　　l 引用完整性规则，同关系模型定义
　　l 用户对定义的规则，为复杂性完整性检查。
　　ORACLE允许定义和实施上述每一种类型的数据完整性规则，这些规则可用完整性约束和数据库触发器定义。
　　完整性约束，是对表的列定义一规则的说明性方法。
　　数据库触发器，是使用非说明方法实施完整性规则，利用数据库触发器（存储的数据库过程）可定义和实施任何类型的完整性规则。
　　
　　1． 完整性约束
　　ORACLE利用完整性约束机制防止无效的数据进入数据库的基表，如果任何DML执行结果破坏完整性约束，该语句被回滚并返回一上个错误。ORACLE实现的完整性约束完全遵守ANSI X3。135-1989和ISO9075-1989标准。
　　利用完整性约束实施数据完整性规则有下列优点：
　　l 定义或更改表时，不需要程序设计，便很容易地编写程序并可消除程序性错误，其功能是由ORACLE控制。所以说明性完整性约束优于应用代码和数据库触发器。
　　l 对表所定义的完整性约束是存储在数据字典中，所以由任何应用进入的数据都必须遵守与表相关联的完整性约束。
　　l 具有最大的开发能力。当由完整性约束所实施的事务规则改变时，管理员只需改变完整性约束的定义，所有应用自动地遵守所修改的约束。
　　l 由于完整性约束存储在数据字典中，数据库应用可利用这些信息，在SQL语句执行之前或由ORACLE检查之前，就可立即反馈信息。
　　l 由于完整性约束说明的语义是清楚地定义，对于每一指定说明规则可实现性能优化。
　　l 由于完整性约束可临时地使不能，以致在装入大量数据时可避免约束检索的开销。当数据库装入完成时，完整性约束可容易地使其能，任何破坏完整性约束的任何新行在例外表中列出。
　　ORACLE的DBA和应用开始者对列的值输入可使用的完整性约束有下列类型：
　　l NOT NULL约束:如果在表的一列的值不允许为空，则需在该列指定NOT NULL约束。
　　l UNIQUE码约束：在表指定的列或组列上不允许两行是具有重复值时，则需要该列或组列上指定UNIQUE码完整性约束。在UNIQUE码约束定义中的列或组列称为唯一码。所有唯一完整性约束是用索引方法实施。
　　l PRIMARY KEY约束：在数据库中每一个表可有一个PRIMARY KEY约束。包含在PRIMARY KEY完整性约束的列或组列称为主码，每个表可有一个主码。ORACLE使用索引实施PRIMARY KEY约束。
　　l FOREIGN KEY约束（可称引用约束）：在关系数据库中表可通过公共列相关联，该 规则控制必须维护的列之间的关系。包含在引用完整性约束定义的列或组列称为外来码。由外来码所引用的表中的唯一码或方码，称为引用码。包含有外来码的表称为子表或从属表。由子表的外来码所引用的表称为双亲表或引用表。如果对表的每一行，其外来码的值必须与主码中一值相匹配，则需指定引用完整性约束。
　　l CHECK约束：表的每行对一指定的条件必须是TRUE或未知，则需在一列或列组上指定CHECK完整性约束。如果在发出一个DML语句时，CHECK约束的条件计算得FALSE时，该语句被回滚。
　　
　　2． 数据库触发器
　　ORACLE允许定义过程，当对相关的表作INSERT、UPDATE或DELETE语句时，这些过程被隐式地执行。这些过程称为数据库触发器。触发器类似于存储的过程，可包含SQL语句和PL/SQL语句，可调用其它的存储过程。过程与触发器差别在于调用方法：过程由用户或应用显式执行；而触发器是为一激发语句 （INSERT、UPDATE、DELETE）发出进由ORACLE隐式地触发。一个数据库应用可隐式地触发存储在数据库中多个触发器。
　　在许多情况中触发器补充ORACLE的标准功能，提供高度专用的数据库管理系统。一般触发器用于：
　　l 自动地生成导出列值。
　　l 防止无效事务。
　　l 实施复杂的安全审核。
　　l 在分布式数据库中实施跨结点的引用完整性。
　　l 实施复杂的事务规则。
　　l 提供透明的事件记录。
　　l 提供高级的审计。
　　l 维护同步的表副本。
　　l 收集表存取的统计信息。
　　注意：在ORACLE环境中利用ORACLE工具SQL*FORMS也可定义、存储和执行触发器，它作为由SQL*FORMS所开发有应用的一部分，它与在表上定义的数据库触发器有差别。数据库触发器在表上定义，存储在相关的数据库中，在对该表发出IMSERT、UPDATE、DELETE语句时将引起数据库触发器的执行，不管是哪些用户或应用发出这些语句。而SQL*FORMS的触发器是SQL*FORMS应用的组成，仅当在指定SQL*FORMS应用中执行指定触发器点时才激发该触发器。
　　一个触发器由三部分组成：触发事件或语句、触发限制和触发器动作。触发事件或语句是指引起激发触发器的SQL语句，可为对一指定表的INSERT、UNPDATE或DELETE语句。触发限制是指定一个布尔表达式，当触发器激以时该布尔表达式是必须为真。触发器作为过程，是PL/SQL块，当触发语句发出、触发限制计算为真时该过程被执行。
　　
　　3． 并发控制
　　数据库是一个共享资源，可为多个应用程序所共享。这些程序可串行运行，但在许多情况下，由于应用程序涉及的数据量可能很大，常常会涉及输入/输出的交换。为了有效地利用数据库资源，可能多个程序或一个程序的多个进程并行地运行，这就是数据库的并行操作。在多用户数据库环境中，多个用户程序可并行地存取数据库，如果不对并发操作进行控制，会存取不正确的数据，或破坏数据库数据的一致性。
　　例：在飞机票售票中，有两个订票员（T1，T2）对某航线（A）的机动性票作事务处理，操作过程如图所示：
　　数据库中的A 1 1 1 1 0 0
　　T1 READ A A：=A-1 WRITE A
　　T2 READ A A：=A-1 WRITE A
　　T1工作区中的A 1 1 0 0 0 0
　　T2工作区中的A 1 1 0 0 0
　　首先T1读A，接着T2也读A。然后T1将其工作区中的A减1，T2也采取同样动作，它们都得0值，最后分别将0值写回数据库。在这过程中没有任何非法操作，但实际上多出一张机票。这种情况称为数据库的不一致性，这种不一致性是由于并行操作而产生的。所谓不一致，实际上是由于处理程序工作区中的数据与数据库中的数据不一致所造成的。如果处理程序不对数据库中的数据进行修改，则决不会造成任何不一致。另一方面，如果没有并行操作发生，则这种临时的不一致也不会造成什么问题。数据不一致总是是由两个因素造成：一是对数据的修改，二是并行操作的发生。因此为了保持数据库的一致性，必须对并行操作进行控制。最常用的措施是对数据进行封锁。
　　
　　1） 数据库不一致的类型
　　l 不一致性
　　在一事务期间，其它提交的或未提交事务的修改是显然的，以致由查询所返回的数据集不与任何点相一致。
　　l 不可重复读
　　在一个事务范围内，两个相同查询将返回不同数据，由于查询注意到其它提交事务的修改而引起。
　　l 读脏数据
　　如果事务T1将一值（A）修改，然后事务T2读该值，在这之后T1由于某种原因撤销对该值的修改，这样造成T2读取的值是脏的。
　　l 丢失更改
　　在一事务中一修改重写另一事务的修改，如上述飞机票售票例子。
　　l 破坏性的DDL操作
　　在一用户修改一表的数据时，另一用户同时更改或删除该表。
　　
　　1) 封锁
　　在多用户数据库中一般采用某些数据封锁来解决并发操作中的数据一致性和完整性问题。封锁是防止存取同一资源的用户之间破坏性的干扰的机制，该干扰是指不正确地修改数据或不正确地更改数据结构。
　　在多用户数据库中使用两种封锁：排它（专用）封锁和共享封锁。排它封锁禁止相关资源的共享，如果一事务以排它方式封锁一资源，仅仅该事务可更改该资源，直至释放排它封锁。共享封锁允许相关资源可以共享，几个用户可同时读同一数据，几个事务可在同一资源上获取共享封锁。共享封锁比排它封锁具有更高的数据并行性。
　　在多用户系统中使用封锁后会出现死锁，引起一些事务不能继续工作。当两个或多个用户彼此等待所封锁数据时可发生死锁。
　　
　　2) ORACLE多种一致性模型。
　　ORACLE利用事务和封锁机制提供数据并发存取和数据完整性。在一事务内由语句获取的全部封锁在事务期间被保持，防止其它并行事务的破坏性干扰。一个事务的SQL语句所作的修改在它提交之后所启动的事务中才是可见的。在一事务中由语句所获取的全部封锁在该事务提交或回滚时被释放。
　　ORACLE在两个不同级上提供读一致性：语句级读一致性和事务级一致性。ORCLE总是实施语句级读一致性，保证单个查询所返回的数据与该查询开始时刻相一致。所以一个查询从不会看到在查询执行过程中提交的其它事务所作的任何修改。为了实现语句级读一致性，在查询进入执行阶段时，在注视SCN的时候为止所提交的数据是有效的，而在语句执行开始之后其它事务提交的任何修改，查询将是看不到的。
　　ORACLE允许选择实施事务级读一致性，它保证在同一事务内所有查询的数据
　　
　　 4) 封锁机制
　　ORACLE自动地使用不同封锁类型来控制数据的并行存取，防止用户之间的破坏性干扰。ORACLE为一事务自动地封锁一资源以防止其它事务对同一资源的排它封锁。在某种事件出现或事务不再需要该资源时自动地释放。
　　ORACLE将封锁分为下列类：
　　l 数据封锁：数据封锁保护表数据，在多个用户并行存取数据时保证数据的完整性。数据封锁防止相冲突的DML和DDL操作的破坏性干扰。DML操作可在两个级获取数据封锁：指定行封锁和整个表封锁，在防止冲突的DDL操作时也需表封锁。当行要被修改时，事务在该行获取排它数据封锁。表封锁可以有下列方式：行共享、行排它、共享封锁、共享行排它和排它封锁。
　　l DDL封锁（字典封锁）
　　DDL封锁保护模式对象（如表）的定义，DDL操作将影响对象，一个DDL语句隐式地提交一个事务。当任何DDL事务需要时由ORACLE自动获取字典封锁，用户不能显式地请求DDL封锁。在DDL操作期间，被修改或引用的模式对象被封锁。
　　l 内部封锁：保护内部数据库和内存结构，这些结构对用户是不可见的。
　　
　　 5) 手工的数据封锁
　　下列情况允许使用选择代替ORACLE缺省的封锁机制：
　　l 应用需要事务级读一致或可重复读。
　　l 应用需要一事务对一资源可排它存取，为了继续它的语句，具有对资源排它存取的事务不必等待其它事务完成。
　　ORACLE自动封锁可在二级被替代：事务级各系统级。
　　l 事务级：包含下列SQL语句的事务替代ORACLE缺省封锁：LOCK TABLE命令、SELECT…FOR UPDATE命令、具有READ ONLY选项的SET TRANSACTIN命令。由这些语句所获得的封锁在事务提交或回滚后所释放。
　　l 系统级：通过调整初始化参数SERIALIZABLE和REO-LOCKING，实例可用非缺省封锁启动。该两参数据的缺省值为：
　　SERIALIZABLE=FALSE
　　ORW-LOCKING=ALWAYS
　　
　　4． 数据库后备和恢复
　　当我们使用一个数据库时，总希望数据库的内容是可靠的、正确的，但由于计算机系统的故障（硬件故障、软件故障、网络故障、进程故障和系统故障）影响数据库系统的操作，影响数据库中数据的正确性，甚至破坏数据库，使数据库中全部或部分数据丢失。因此当发生上述故障后，希望能重新建立一个完整的数据库，该处理称为数据库恢复。恢复子系统是数据库管理系统的一个重要组成部分。恢复处理随所发生的故障类型所影响的结构而变化。
　　
　　1） 恢复数据库所使用的结构
　　ORACLE数据库使用几种结构对可能故障来保护数据：数据库后备、日志、回滚段和控制文件。
　　数据库后备是由构成ORACLE数据库的物理文件的操作系统后备所组成。当介质故障时进行数据库恢复，利用后备文件恢复毁坏的数据文件或控制文件。
　　日志，每一个ORACLE数据库实例都提供，记录数据库中所作的全部修改。一个实例的日志至少由两个日志文件组成，当实例故障或介质故障时进行数据库部分恢复，利用数据库日志中的改变应用于数据文件，修改数据库数据到故障出现的时刻。数据库日志由两部分组成：在线日志和归档日志。
　　每一个运行的ORACLE数据库实例相应地有一个在线日志，它与ORACLE后台进程LGWR一起工作，立即记录该实例所作的全部修改。在线日志由两个或多个预期分配的文件组成，以循环方式使用。
　　归档日志是可选择的，一个ORACLE数据库实例一旦在线日志填满后，可形成在线日志的归档文件。归档的在线日志文件被唯一标识并合成归档日志。
　　回滚段用于存储正在进行的事务（为未提交的事务）所修改值的老值，该信息在数据库恢复过程中用于撤消任何非提交的修改。
　　控制文件，一般用于存储数据库的物理结构的状态。控制文件中某些状态信息在实例恢复和介质恢复期间用于引导ORACLE。
　　
　　2） 在线日志
　　一个ORACLE数据库的每一实例有一个相关联的在线日志。一个在线日志由多个在线日志文件组成。在线日志文件填入日志项，日志项记录的数据用于重构对数据库所作的全部修改。后台进程LGWR以循环方式写入在线日志文件。当当前的在线日志文件写满后，LGWR写入到下一可用在线日志文件当最后一个可用的在线日志文件的检查点已完成时即可使用。如果归档不实施，一个已填满的在线日志文件一当包含该在线日志文件的检查点完成，该文件已被归档后即可使用。在任何时候，仅有一个在线日志文件被写入存储日志项，它被称为活动的或当前在线日志文件，其它的在线日志文件为不活动的在线日志文件。
　　ORCLE结束写入一在线日志文件并开始写入到另一个在线日志文件的点称为日志开关。日志开关在当前在线日志文件完全填满，必须继续写入到下一个在线日志文件时总出现，也可由DBA强制日志开关。每一日志开关出现时，每一在线日志文件赋给一个新的日志序列号。如果在线日志文件被归档，在归档日志文件中包含有它的日志序列号。
　　ORACLE后台进程DBWR（数据库写）将SGA中所有被修改的数据库缓冲区（包含提交和未提交的）写入到数据文件，这样的事件称为出现一个检查点。因下列原因实现检查点：
　　l 检查点确保将内存中经常改变的数据段块每隔一定时间写入到数据文件。由于DBWR使用最近最少使用算法，经常修改的数据段块从不会作为最近最少使用块，如果检查点不出现，它从不会写入磁盘。
　　l 由于直至检查点时所有的数据库修改已记录到数据文件，先于检查点的日志项在实例恢复时不再需要应用于数据文件，所以检查点可加快实例恢复。
　　虽然检查点有一些开销，但ORACLE既不停止活动又不影响当前事务。由于DBWR不断地将数据库缓冲区写入到磁盘，所以一个检查点一次不必写许多数据块。一个检查点保证自前一个检查点以来的全部修改数据块写入到磁盘。检查点不管填满的在线日志文件是否正在归档，它总是出现。如果实施归档，在LGWR重用在线日志文件之前，检查点必须完成并且所填满的在线日志文件必须被归档。
　　检查点可对数据库的全部数据文件出现（称为数据库检查点），也可对指定的数据文件出现。下面说明一下什么时候出现检查点及出现什么情况：
　　l 在每一个日志开关处自动地出现一数据库检查点。如果前一个数据库检查点正在处理，由日志开关实施的检查点优于当前检查点。
　　l 初始化参数据LOG-CHECKPOINT-INTERVAL设置所实施的数据库检查点，当预定的日志块数被填满后（自最后一个数据库检查点以来），实施一数据库检查点。另一个参数LOG-CHECKPOINT-TIMEOUT可设置自上一个数据库检查点开始之后指定秒数后实施一数据库检查点。这种选择对使用非常大的日志文件时有用，它在日志开头之间增加检查点。由初始化参数所启动的数据库检查点只有在前一个检查点完成后才能启动。
　　l 当一在线表空间开始后备时，仅对构成该空间的数据文件实施一检查点，该检查点压倒仍在进行中的任何检查点。
　　l 当DBA使一表空间离线时，仅对构成该表空间的在线文件实施一检查点。
　　l 当DBA以正常或立即方式关闭一实例时，ORACLE在实例关闭之前实施一数据库检查点，该检查点压倒任何运行检查点。
　　l DBA可要求实施一数据库检查点，该检查点压倒任何运行检查点。
　　
　　检查点机制：当检查点出现时，检查点后台进程记住写入在线文件的下一日志行的位置，并通知数据库写后台进程将SGA中修改的数据库缓冲区写入到磁盘上的数据文件。然后由CKPT修改全部控制文件和数据文件的标头，反映该最后检查点。当检查点不发生，DBWR当需要时仅将最近最少使用的数据库缓冲区写入磁盘，为新数据准备缓冲区。
　　镜象在线日志文件：为了安全将实例的在线日志文件镜象到它的在线日志文件ORACLE提供镜象功能。当具有镜象在线日志文件时，LGWR同时将同一日志信息写入到多个同样的在线日志文件。日志文件分成组，每个组中的日志文件称为成员，每个组中的全部成员同时活动，由LGWR赋给相同的日志序列号。如果使用镜象在线日志，则可建立在线日志文件组，在组中的每一成员要求是同一大小。
　　镜象在线日志的机制：LGWR总是寻找组的全部成员，对一组的全部成员并行地写，然后转换到下一组的全部成员，并行地写。
　　每个数据库实例有自己的在线日志组，这些在线日志组可以是镜象的或不是，称为实例的在线日志线索。在典型配置中，一个数据库实例存取一个ORACLE数据库，于是仅一个线索存在。然而在运行ORACLE并行服务器中，两个或多个实例并行地存取单个数据库，在这种情况下，每个实例有自己的线索。
　　
　　3） 归档日志
　　ORACLE要将填满的在线日志文件组归档时，则要建立归档日志，或称离线日志。其对数据库后备和恢复有下列用处：
　　l 数据库后备以及在线和归档日志文件，在操作系统或磁盘故障中可保证全部提交的事务可被恢复。
　　l 在数据库打开时和正常系统使用下，如果归档日志是永久保持，在线后备可以进行和使用。
　　如果用户数据库要求在任何磁盘故障的事件中不丢失任何数据，那么归档日志必须要存在。归档已填满的在线日志文件可能需要DBA执行额外的管理操作。
　　归档机制：决定于归档设置，归档已填满的在线日志组的机制可由ORACLE后台进程ARCH自动归档或由用户进程发出语句手工地归档。当日志组变为不活动、日志开关指向下一组已完成时，ARCH可归档一组，可存取该组的任何或全部成员，完成归档组。在线日志文件归档之后才可为LGWR重用。当使用归档时，必须指定归档目标指向一存储设备，它不同于个有数据文件、在线日志文件和控制文件的设备，理想的是将归档日志文件永久地移到离线存储设备、如磁带。
　　数据库可运行在两种不同方式下：NOARCHIVELOG方式或ARCHIVELOG方式。数据库在NOARCHIVELOG方式下使用时，不能进行在线日志的归档。在该数据库控制文件指明填满的组不需要归档，所以一当填满的组成为活动，在日志开关的检查点完成，该组即可被LGWR重用。在该方式下仅能保护数据库实例故障，不能保护介质（磁盘）故障。利用存储在在线日志中的信息，可实现实例故障恢复。
　　如果数据库在ARCHIVELOG方式下,可实施在线日志的归档。在控制文件中指明填满的日志文件组在归档之前不能重用。一旦组成为不活动，执行归档的进程立即可使用该组。
　　在实例起动时，通过参数LOG-ARCHIVE-START设置，可启动ARCH进程，否则ARCH进程在实例启动时不能被启动。然而DBA在凭借时候可交互地启动或停止自动归档。 一旦在线日志文件组变为不活动时，ARCH进程自动对它归档。
　　如果数据库在ARCHIVELOG方式下运行，DBA可手工归档填满的不活动的日志文件组，不管自动归档是可以还是不可以。
　　
　　4） 数据库后备
　　不管为ORACLE数据库设计成什么样的后备或恢复模式，数据库数据文件、日志文件和控制文件的操作系统后备是绝对需要的，它是保护介质故障的策略部分。操作系统后备有完全后备和部分后备
　　l 完全后备：一个完全后备将构成ORACLE数据库的全部数据库文件、在线日志文件和控制文件的一个操作系统后备。一个完全后备在数据库正常关闭之后进行，不能在实例故障后进行。在此时，所有构成数据库的全部文件是关闭的，并与当前点相一致。在数据库打开时不能进行完全后备。由完全后备得到的数据文件在任何类型的介质恢复模式中是有用的。
　　l 部分后备
　　部分后备为除完全后备外的任何操作系统后备，可在数据库打开或关闭下进行。如单个表空间中全部数据文件后备、单个数据文件后备和控制文件后备。部分后备仅对在ARCHIVELOG方式下运行数据库有用，因为存在的归档日志，数据文件可由部分后备恢复。在恢复过程中与数据库其它部分一致。
　　
　　5） 数据库恢复
　　l 实例故障的恢复
　　当实例意外地（如掉电、后台进程故障等）或预料地（发出SHUTDOUM ABORT语句）中止时出现实例故障，此时需要实例恢复。实例恢复将数据库恢复一故障之前的事务一致状态。如果在在线后备发现实例故障，则需介质恢复。在其它情况ORACLE在下次数据库起动时（对新实例装配和打开），自动地执行实例恢复。如果需要，从装配状态变为打开状态，自动地激发实例恢复，由下列处理：
　　（1） 为了解恢复数据文件中没有记录的数据，进行向前滚。该数据记录在在线日志，包括对回滚段的内容恢复。
　　（2） 回滚未提交的事务，按步1重新生成回滚段所指定的操作。
　　（3） 释放在故障时正在处理事务所持有的资源。
　　（4） 解决在故障时正经历一阶段提交的任何悬而未决的分布事务。
　　l 介质故障的恢复
　　介质故障是当一个文件、一个文件的部分或一磁盘不能读或不能写时出现的故障。介质故障的恢复有两种形式，决定于数据库运行的归档方式。
　　l 如果数据库是可运行的，以致它的在线日志仅可重用但不能归档，此时介质恢复为使用最新的完全后备的简单恢复。在完全后备执行的工作必须手工地重作。
　　l 如果数据库可运行，其在线日志是被归档的，该介质故障的恢复是一个实际恢复过程，重构受损的数据库恢复到介质故障前的一个指定事务一致状态。
　　不管哪种形式，介质故障的恢复总是将整个数据库恢复到故障之前的一个事务一致状态。如果数据库是在ARCHIVELOG方式运行，可有不同类型的介质恢复：完全介质恢复和不完全介质恢复。
　　完全介质恢复可恢复全部丢失的修改。仅当所有必要的日志可用时才可能。有不同类型的完全介质恢复可使用，其决定于毁坏文件和数据库的可用性。例：
　　l 关闭数据库的恢复。当数据库可被装配却是关闭的，完全不能正常使用，此时可进行全部的或单个毁坏数据文件的完全介质恢复。
　　l 打开数据库的离线表空间的恢复。当数据库是打开的，完全介质恢复可以处理。未损的数据库表空间是在线的可以使用，而受损耗捕空间是离线的，其所有数据文件作为恢复的单位。
　　l 打开数据库的离线表间的单个数据文件的恢复。当数据库是打开的，完全介质恢复可以处理。未损的数据库表空间是在线的可以使用，而所损的表空间是离线的，该表空间的指定所损的数据文件可被恢复。
　　l 使用后备的控制文件的完全介质恢复。当控制文件所有拷贝由于磁盘故障而受损时，可进行介质恢复而不丢失数据。
　　不完全介质恢复是在完全介质恢复不可能或不要求时进行的介质恢复。重构受损的数据库，使其恢复介质故障前或用户出错之前的一个事务一致性状态。不完全介质恢复有不同类型的使用，决定于需要不完全介质恢复的情况，有下列类型：基于撤消、基于时间和基于修改的不完全恢复。
　　基于撤消恢复：在某种情况，不完全介质恢复必须被控制，DBA可撤消在指定点的操作。基于撤消的恢复地在一个或多个日志组（在线的或归档的）已被介质故障所破坏，不能用于恢复过程时使用，所以介质恢复必须控制，以致在使用最近的、未损的日志组于数据文件后中止恢复操作。
　　基于时间和基于修改的恢复：如果DBA希望恢复到过去的某个指定点，不完全介质恢复地理想的。可在下列情况下使用：
　　l 当用户意外地删除一表，并注意到错误提交的估计时间，DBA可立即关闭数据库，恢复它到用户错误之前时刻。
　　l 由于系统故障，一个在线日志文件的部分被破坏，所以活动的日志文件突然不可使用，实例被中止，此时需要介质恢复。在恢复中可使用当前在线日志文件的未损部分，DBA利用基于时间的恢复，一旦有将效的在线日志已应用于数据文件后停止恢复过程。
　　在这两种情况下，不完全介质恢复的终点可由时间点或系统修改号（SCN）来指定。
　　
　　
　　

原文转自：http://www.ltesting.net