4.数据库审计的命令
使用AUDIT命令可以指定审计选项，由SYS用户所建立的会话不生成审计记录。
权限或语句审计的语法如下：
AUDIT{语句|系统权限|SESSION|USER}
[，{语句|系统权限|SESSION|USER}]……
[BY 用户[，用户]……]
[BY{SESSION|ACCESS}]
[WHENEVER[NOT]SUCCESSFUL]
对象审计的语法如下：
AUDIT 语句[，语句]……
ON{[用户名，]对象|DEFAULT}
[BY{SESSION|ACCESS}]
[WHENEVER[NOT]SUCCESSFUL]
其中：系统权限用于指定需要审计的系统权限；语句表示指定审计的SQL语句类型或者对象；对象表示审计所选择的对象；DEFAULT表示为后续建立的对象进行审计；用户表示只审计列出的这些用户的活动（假如缺少该从句，表示对所有用户的活动进行审计）；BY SESSION表示不管相同的SQL语句提交了多少次，对每一个会话中的每一条语句或每一个数据库对象只往审计表中插入一条记录；BY ACCESS表示每一条审计语句被提交时，Oracle往审计表中插入一条记录；WHENEVER用于指定只有在SQL语句成功执行或不成功执行时才审计。
审计命令举例如下。
例8-32 审计与数据库的连接和断开的信息。
SQL＞AUDIT SESSION；
例8-33 审计成功登录时的信息。
SQL＞AUDIT SESSION WHENEVER SUCCESSFUL；
例8-34 审计登录失败时的信息。
SQL＞AUDIT SESSION WHENEVER NOT SUCCESSFUL；
例8-35 审计用户john和scott成功登录时的信息。
SQL＞AUDIT SESSION BY john，scott WHENEVER SUCCESSFUL；
例8-36 审计对john用户的CUSTOMER表成功更新和删除的操作。
SQL＞AUDIT UPDATE，DELETE ON john.CUSTOMER BY ACCESS WHENEVER SUCCESSFUL；
（1）权限审计
权限审计就是审计所使用的系统权限。
例8-37 当scott用户使用SELECT ANY TABLE系统权限时，生成一条审计记录。
SQL＞AUDIT SELECT ANY TABLE BY scott BY ACCESS；
（2）语句审计
通过使用一种类型的SQL语句或一种对象类型进行审计。
例8-38 审计所有用户的所有CREATE USER、ALTER USER和DROP USER语句。
SQL＞AUDIT USER；
语句审计选项特别宽，可以审计每一个选项的各种类型的相关动作。
例8-39 跟踪各种DDL（如：CREATE TABLE、DROP TABLE、TRUNCATE TABLE）语句，不管该语句在哪张表上执行。
SQL＞AUDIT TABLE；
（3）对象审计
对象审计语句审计在一个特定用户对象上执行的语句。
例8-40 当一个用户在scott用户的emp表上成功地执行LOCK命令时生成一条审计记录。
SQL＞AUDIT LOCK ON scott.emp BY ACCESS WHENEVER SUCCESSFUL；
ALL可以作为一个对象的审计选项，可以审计对象类型上能执行的所有选项。
5.停止审计
（1）停止审计的语法
使用NOAUDIT命令可以停止在AUDIT命令中选择的审计，NOAUDIT命令停止语句审计和系统权限审计的语法如下：
NOAUDIT{语句|系统权限|SESSION|USER}
[，{语句|系统权限|SESSION|USER}]……
[BY 用户[，用户]……]
[WHENEVER[NOT]SUCCESSFUL]
NOAUDIT命令停止对象审计的语法如下：
NOAUDIT 语句[，语句]……
ON{[用户名，]对象|DEFAULT}
[WHENEVER[NOT]SUCCESSFUL]
注意：即使审计是不允许的，特权操作的审计总是进行的；一个NOAUDIT语句将以前AUDIT语句的功能颠倒过来，要求NOAUDIT语句必须与以前AUDIT语句的语法一样，并且只颠倒了该AUDIT语句的功能，其他AUDIT语句继续审计。
（2）停止审计命令举例
例8-41 停止对所有用户成功操作的语句审计。
SQL＞NOAUDIT USER WHENEVER SUCCESSFUL；
例8-42 停止对scott用户的CREATE TABLE 权限审计。
SQL＞NOAUDIT CREATE TABLE BY scott；
例8-43 停止对emp表上锁操作的对象审计。
SQL＞NOAUDIT LOCK ON emp；
例8-44 停止对JOHN用户的CUSTOMER表上的对象审计。
SQL＞NOAUDIT UPDATE，DELETE ON JOHN.CUSTOMER；
NOAUDIT命令可以关闭除了BY SESSION和BY ACCESS选项之外的所有在AUDIT语句中指定的选项。
6.查询审计信息
审计记录存储由语句、权限及对象审计所产生的记录。数据库管理员可以查询与审计相关的数据字典视图获得在审计过程中生成的审计信息。这些信息用于查看数据库中有疑问的活动或监视数据库活动。
8.2 数据库的恢复
虽然目前计算机软硬件技术已经发展到相当高的水平，但硬件的故障、系统软件和应用软件的错误、操作员的失误及恶意的破坏仍然是不可避免的。这些故障轻则造成运行事务的非正常中断，影响数据库中数据的正确性；重则破坏数据库，使数据库中数据部分或全部丢失。为了保障各种故障发生后，数据库中的数据都能从错误状态恢复到某种逻辑一致的状态，数据库管理系统中恢复子系统是必不可少的。各种现有数据库系统运行情况表明，数据库所采用恢复技术它是否行之有效，不仅对系统的可靠程度起着决定性作用，而且对系统的运行效率也有很大影响，是衡量系统性能好坏的重要指标。
8.2.1 数据库恢复的原理、方法和策略
8.2.1.1 事务的概念和性质
为了便于理解数据库恢复技术，在讨论恢复技术之前，先讲解事务的概念和性质。
1.事务的概念
事务是用户定义的一个数据库操作序列。这些操作要么全做，要么全不做，是一个不可分割的工作单位。一个事务可以是一条SQL语句、多条SQL语句或整个程序。事务与程序的区别在于，一个程序可以包含多个事务。
事务通常以SET TRANSACTION开始，以COMMIT或ROLLBACK语句结束。
COMMIT表示提交，系统会将事务内的所有操作都写入数据库物理文件中，事务成功地结束。此时数据库处于一致性的状态。
ROLLBACK表示回退，系统会将事务内所有已完成的操作全部撤销，回退到事务开始的状态，事务成功地结束。此时数据库处于一致性的状态。
当COMMIT或ROLLBACK后自动又开始一个新的事务。
如果在事务运行过程中发生了故障，事务不能继续进行，事务不成功地结束。此时数据库处于不一致性的状态。
2.事务的性质
事务具有四个特性：原子性、一致性、隔离性和持续性。
（1）原子性
事务是一个不可分割的工作单位，事务中的所有操作要么全部执行，要么全部不执行。原子性由DBMS的事务管理子系统保证。
（2）一致性
事务执行的结果必须是使数据库从一个一致性状态变成另一个一致性状态。如果数据库中只包含事务成功提交后或成功回退后的结果，此数据库状态就称为“一致状态”。
如果数据库运行发生故障，有些事务尚未完成就被迫中断。这些未完成事务对数据库所做的修改有一部分已写入数据库物理文件，有一部分还没有写入数据库物理文件。这时数据库就处于一种不正确状态，或者说是不一致的状态。需要DBMS的恢复子系统根据故障类型采取相应的措施，将数据库恢复到某种一致状态。
一致性可由程序员编写程序来保证，或由DBMS完整性约束子系统自动保证。
例如：某公司在银行的A、B两个账号中，希望从A账号中取出1万元，存入到B账号。那么就可以定义一个事务，该事务有两个操作：第一个操作是从A账号中减1万元，第二个操作是B账号中加1万元。这两个操作如果全做，或全不做，此时数据库都处于一致性状态。如果这两个操作只做任一个，则逻辑上发生了错误，此时数据库处于不一致性状态。
（3）隔离性
在并发事务被执行时，系统应保证与这些事务先后单独（串行）执行时的结果一样，此时称事务达到了隔离性要求。即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间互不干扰。隔离性由DBMS的并发控制子系统来保证。
（4）持续性
持续性也称永久性，即一个事务一旦提交，它对数据库的所有更新永久地反映在数据库中。即使以后系统发生故障，也不影响这个事务执行的结果。持续性由DBMS的恢复管理子系统来保证。
8.2.1.2 故障的种类和相应的恢复操作
数据库运行过程中可能发生的故障和相应的恢复操作有以下几类。
1.事务故障及恢复
事务在运行过程中由于种种原因，如输入数据的错误、运算溢出、违反了某些完整性限制、某些应用程序的错误，以及并行事务发生死锁等，使事务未运行至正常终点之前就被撤销，这种情况称为“事务故障”。
当发生事务故障后，那些未运行至正常终点的事务可能已将对数据库的部分修改写回磁盘。恢复程序要在不影响其他事务运行的前提下，清除该事务对数据库的所有修改（回退该事务），使得这个事务像从未启动过一样，这种恢复操作称为“事务撤销”。
2.系统故障与恢复
系统故障是指系统在运行过程中，由于某种原因，如操作系统或DBMS代码错误，操作员操作失误、特定类型的硬件错误（如CPU故障），突然停电等造成系统运行停止，致使事务在执行过程中以非正常方式终止，这时内存中的信息丢失，而存储在外部存储设备上的数据未受影响，这种情况称为“系统故障”。
系统故障时，有些尚未完成的事务的结果已写入磁盘的物理文件中，从而造成数据库可能处于一个不正确的状态。系统重新启动后，恢复子系统要把这些事务回退（ROLLBACK），清除对数据库的所有修改，使这些事务像从来没有运行过一样。即撤销（UNDO）全部未完成的事务，使数据库恢复到一致状态。
系统故障时，有些已完成事务提交的结果可能还有一部分甚至全部留在缓冲区而未写回磁盘的物理文件中。系统故障使得这些事务对数据库的修改部分或全部丢失，造成数据库中的数据不一致状态。在系统重新启动后应将这些事务已提交的结果重新写入数据库，即重做（REDO）这些已提交的事务，将数据库恢复到一致状态。
3.介质故障及恢复
系统在运行过程中，由于某种硬件故障，如磁盘坏损、磁头碰撞或由于操作系统的某种潜在的错误、瞬时强磁场干扰，使存储在外存上的数据部分损失或全部损失，称为“介质故障”。
此类故障比前两种故障的可能性虽然小得多，但破坏性却最大。介质故障发生后，存储在磁盘上的数据被破坏。如果在数据库被破坏之前，对数据库已做了完全备份，则重新启动后，可以利用恢复程序装入数据库发生介质故障前某个时期的备份，并将此时所有成功事务全部重做（REDO），也就是将这些事务已提交的结果重新写入数据库。如果在数据库被破坏之前没有备份，则有可能所有事务必须手工恢复。
4.计算机病毒
计算机病毒是一种人为破坏计算机正常工作的特殊程序。通过读写染有病毒的计算机系统的程序与数据，这些病毒可以迅速繁殖和传播，危害计算机系统和数据库。计算机病毒已成为对计算机系统安全性的重要威胁，为此已研制了不少检查、诊断、消灭计算机病毒的软件，但新的病毒软件仍在不断出现，对数据库的威胁仍然存在，因此一旦数据库被破坏，仍要用恢复技术把数据库恢复到一致的状态。
前面已简要介绍了数据库系统中可能发生的故障以及需要进行的恢复操作。数据库系统可能发生的各类故障对数据库的影响有两种可能性：一是数据库本身被破坏，如发生介质故障，或被计算机病毒所破坏；二是数据库本身并没有被破坏，但数据可能不正确。
对于不同类型的故障，有不同的恢复技术。恢复技术从原理上讲都是利用存储在系统其他地方的冗余数据来重建数据库中已经被破坏或已经不正确的那部分数据。恢复技术原理虽然简单，但实现却相当复杂。一般一个大型数据库产品，恢复子系统的代码占DBMS全部代码的10%以上。下面介绍恢复的实现方法。
8.2.1.3 恢复的实现方法
恢复从原理上讲就是利用存储在系统其他地方的冗余数据来重建被破坏的数据库中的数据。在数据库中用于恢复的数据有两种：一种是备份副本，另一种是日志文件。下面分别介绍备份副本和日志文件，以及如何利用它们来实现相应的恢复操作。
1.数据备份（数据转储）
备份副本是指在故障发生前某一时刻数据库事务一致性的副本。因此它是数据库的一个备用的数据文本，被称为备份副本或后援副本。
制作备份副本的过程称为备份或“转储”，就是DBA定期地将数据库复制到磁带或磁盘上保存起来。当数据库受到破坏时就可以将备份副本重新装入，把数据库恢复到备份时的状态。如果有备份副本和日志文件可以将数据库恢复到某一时刻的正确状态。
数据备份根据备份过程中用户能否对数据库操作，可分为静态备份和动态备份。
静态备份（在Oracle系统中称为冷备份）是备份过程中不允许用户对数据库进行任何存取和修改操作。
动态备份（在Oracle系统中称为热备份）是备份过程中允许用户对数据库进行存取和修改操作，即备份操作与用户事务可以并发执行。
数据备份根据备份时的备份内容，又可分为海量备份和增量备份。
海量备份（在Oracle系统中称为完全备份）是指每次备份整个数据库全部数据。
增量备份（在Oracle系统中也称为增量备份）是指每次只备份上一次备份后更新过的数据。
2.日志文件（LOGFILE）
日志文件是用来记录对数据的每一次更新操作的文件。日志文件一般由DBMS自动产生并根据数据库中的操作自动写日志记录。
（1）日志文件的内容
事务在运行过程中，系统将事务中每个更新操作登记在日志文件中。对每个事务，日志文件需要登记的内容包括：事务开始（SET TRANSACTION）标记、事务结束（COMMIT 或ROLL BACK）标记、事务的所有更新操作。这些信息均是作为一个日志记录（LOG RECORD）存放在日志文件中。每个日志记录包括：事务标志（标明是哪个事务），操作的类型（插入、修改或删除），操作对象，更新前数据的旧值（对插入操作而言，此项为空值），更新后数据的新值（对删除操作而言，此项为空值）。
（2）日志文件的作用
DBMS可以根据日志文件进行事务故障恢复和系统故障恢复，并结合备份副本进行介质故障恢复。日志文件的具体作用如下。
事务故障恢复和系统故障恢复时必须用日志文件。
在动态备份时必须建立日志文件，利用备份副本和日志文件可以进行介质恢复，恢复到失败发生前的数据库状态。
在静态备份时也可以建立日志文件。利用备份文件可以恢复到备份时的数据库状态，利用日志文件可以将备份后发生的事务重做（REDO）或撤销（UNDO）。故障发生时已经完成的事务进行重做，故障发生时未完成的事务进行撤销。
（3）日志文件的登记原则
为保证数据库可恢复，向日志文件中写日志记录时必须遵循以下两条原则。
严格按并发事务执行的时间次序进行登记。
必须先写日志记录，日志记录写入成功后，才能往数据库中写数据。只有事务的所有日志记录都写入日志文件后，才允许事务结束。
