ORACLE DBA技术学习笔记续1

十四、管理数据库性能

性能监视通过具有下列形式：反应式和前摄式。反应式意味着在出现某个问题的时候或之后执行某些动作；前摄式意味着在成为问题前标识未决的问题。最理想的方式是前摄式。但有些情况下也必须采用反应式监视。本课将阐述在出现问题后对问题的标识。

无效的对象：
大多数而并非全部过程对象都会引用数据对象。编译一个过程对象时，编译器会检查这个过程对象引用的数据对象，从而确定用于代码块的数据对象的定义是否正确及是否具有适当的权限。如果某个过程对象所引用的数据对旬在该过程对象编译后发生变化，则该过程会被标记为无效：INVALID。oracle会尝试自动编译无效的PL/SQL对象和视图，但是可能不会成功。虽然Oracle可能建议手动进行编译，但并非必须进行这个操作。

标识无效的对象：
DBA_OBJECTS视图及派生的ALL_OBJECTS和USER_OBJECTS视图，具有一个STATUS列，这个列在理想情况下应当始终是有效的。通过查看该列可以确定对象的状态是否被标识为无效。

修正无效的对象
为了编译过程对象，需使用ALTER ... COMPILE命令。例如：
Alter Procedure procedure_name compile;重新编译存储过程；
如果编译成功，就不会存在什么问题。如果编译失败，就需要找出失败的原因。如果某个过程没有被编译，那么可用SHOW ERRORS命令来查看原因，遗憾的是该命令不支持对视图的操作。如果希望确定编译错误的原因，通过需要首先使用DBA_DEPENDENCIES视图。
对于通过NAME进行标识的每个对象来说，视图中都存在说明对象依赖关系的记录。REFERENCED_NAME列显示NAME所标识的对象所依赖的对象名。如果需要重新编译数百个或数千个无效对象，可以使用补充的实用程序脚本。UNIX下运行@?/rdbms/admin/utlrp;WINDWOWS下运行
@?/rdbms/admin/utlrp。这个在作为SYSDBA进行连接时运行的脚本会试图编译所有无效的对象。如果运行之后仍存在无效的对象，则可以认定存在应当单独进行解决问题。

无用的索引
如果某个过程对象变为无效，则DBA不必执行任何操作。首次访问该对象时，ORACLE会尝试进行重新编译，而且完全可能编译成功。但如果某个索引由于种种原因变得无用，必须始终在能够使用该索引之前执行显示的修复操作。
一个索引由若干按照顺序排列的索引键组成，每个索引键值都具有相关联的rowid。rowid是索引键引用的记录的位置物理指针。如果某个表的rowid发生变化，则索引就会被标记为无用。最常见的是使用ALTER TABLE ... MOVE命令删除了指定的表。

标志无用的索引
SKIP_UNUSABLE_INDEXES实例参数控制如果索引无用是否跳过该无用索引即不使用被标志为无用的索引。设置为TRUE则表示跳过，设置为FALSE则会因为无用索引而返回错误消息。对于索引有必要实施约束的情况是个例外：如果主键列上的索引变得无用，则会为DML锁定指定的表，即SELECT语句可以通过扫描整个表而成功执行。大多数DML语句的执行都会失败，唯一的例外是不影响键列的UPDATE语句。
通过查询DBA_INDEXES视图，检测变得无用的索引。

修正无用的索引
如果rowid指针不再正确，索引就会标记为无用。使用ALTER INDEX ... REBUILD命令重新创建该索引。执行该命令会扫描指定的表，同时为每个索引键生成一个具有正确rowid指针的新索引。生成新的索引后，原有的无用索引会被删除。索引的重建过程需要额外的存储空间。REBUILD命令有很多选项，最重要的是TABLESPACE、ONLINE及NOLOGGING。在默认情况下，索引在其当前的表空间内重建，如果使用TABLESPACE关键字指定了表空间，则重建将在该表空间内进行。默认情况下，重建过程会为DML命令锁定指定的表，如果使用ONLINE关键字则可以避免这种状况。NOLOGGING关键字则指示ORACLE不为索引重建操作生成重做，这样可以快速完成重建，不过也意味着应当立即对包含指定索引的表空间进行备份，在备份表空间之前，因为需要使用还原和恢复，所以遭受介质损害的索引无法被修复。启用NOLOGGING选项只是为索引重建禁用重做生成。在索引重建后，针对该索引的所有DML命令都会像平时一样生成重做。重建索引时所需的磁盘空间可能两倍于使用这个索引时所需的磁盘空间。因为重建过程同时需要使用旧索引和新索引所需的磁盘空间。

优化器统计
对于性能来说，执行计划的选择十分重要。在ORACLE中，标准的做法是使用优化器来选择执行计划。优化器紧密依赖于一些统计量，统计量的正确性至关重要。统计量有许多类型，但主要是对象统计量。这种统计给出了SQL语句所涉及的表的详细信息。统计与PL/SQL无关，而只与SQL有关。因此统计量分析不能改善PL/SQL的性能。不过，大多数PL/SQL代码都包含对SQL语句的调用。对于这些语句来说，统计量同样非常重要。

对象统计量
对某个表进行分析可以收集优化器能够使用的，与该表相关的统计量。这些统计量显示在DBA_TABLES视图内 。列统计量显示在DBA_COLUMNS视图内。索引统计量显示在DBA_INDEXES视图内。分析了索引所基于的表后，同样会填充DBA_INDEXES视图。以上统计量都存储在数据字典内。如果统计量丢失或不正确，数据库的性能会显著退化。其他与索引相关的统计量显示在INDEX_STATS视图内。
除DBA_TABLES视图中的表统计量之外，分析某个表时还会收集DBA_INDEXES视图中的索引统计量及DBA_COLUMNS视图中的列统计量。

收集统计量：对象统计量不是实时的，而是静态的。统计量的收集操作可以是自动的，也可以手工完成。使用ANALYZE命令或DBMS_STATS程序包中的过程能够手动地收集统计量。
ANALYZE TABLE table_name COMPUTE STATISTICS：分析整个表。
DBMS_STATS.GATHER_TABLE_STATS(owner,table_name);
与原有的ANALYZE命令相比，能够接受许多实参的DBMS_STATS过程更能影响统计量分析的深入程度。
对象统计量不是实时的，并且在新分析对其进行刷新之前是静态的。如果没有足够频繁地进行对象统计，统计量将变得过时，从而会使优化器选择不当的执行计划。

性能指标：
统计量是一个原始数字，其本身可能无用。指标是一个经过转换变得有意义的统计量。

使用动态性能视图查看统计量
以V$作为前缀的视图。其实它根本不是视图，而是用于前缀为V_$的视图的同义词。
通过动态性能视图来访问与实例相关的以及与数据库特定区间相关的信息感知量。大多数动态性能视图填充来自实例的信息，剩余的动态性能视图则填充来自控制文件的信息。所有这些视图都能给出实时的信息。填充信息来自指定实例的动态性能视图(V$INSTANCE或V$SYSSTAT视图)在任何时候都可用，即使这个实例处于NOMOUNT模式下仍然如此。除非指定控制文件读取的数据库已加载，否则填充信息来自这个控制文件的动态性能视图(V$DATABASE或V$DATAFILE视图)，且不能被查询。数据字典视图(DBA,ALL,USER为前缀)只能在包含指定数据字典的数据库被打开后被查询。
动态性能视图填充了来自实例或控制文件的信息，前缀为DBA,ALL,USER的数据字典视图则填充了来自数据字典的信息。
动态性能视图在数据库启动阶段被创建，在指定实例的生存期内进行更新，在数据库关闭阶段被删除。这意味着动态性能视图包含了从数据库启动开始积累的值。如果数据库被连接打开半年时间，则动态性能视图就具有这一段时间内建立的所有数据。动态性能视图通常提供的是统计量而非指标。
V$SYSTEM_WAIT_CLASS视图概述了可能导致会话或整个数据库运行缓慢的各种问题。

在理想情况下，我们不需要对性能问题作出反应，而是应当在问题出现之前对其进行预期。EMDC的Performance标签下，显示了五个将时间与性能指标关联在一起的图形：
运行队列的长度：指示服务器CPU资源的紧张程度；
分页速度：在服务器内存不足的情况下会增加；
正在等待的数据库会话数及其原因
每秒的登录与事务数
物理读取数以及每秒生成的重做量。

十五、监视ORACLE
自动工作负荷仓库
ORACLE收集了大量与性能和动作相关的统计信息。这些信息在内存中累加，并有规律地写入磁盘(也就是写入构成AWR--Automatic Workload Repository,自动工作负荷仓库的表)。最终，这些信息会过期并会被重写。
收集统计量的级别由实例参数STATISTICS_LEVEL控制。该参数可能会被设置为BASIC，TYPICAL或ALL。TYPICAL级别允许收集正常调整所需的所有统计量，同时不会收集对性能有不良影响的统计量集合。BASIC级别事实上禁止收集统计量，并且不存在可评估的性能优势。ALL级别会收集与SQL执行相关的、极其详细的统计量。如果进行高级的SQL语句调整，那么就可以用ALL级别，不过在收集统计量时会导致性能稍有退化。在正常运行期间需要将STATISTICS_LEVEL参数保持为默认的TYPICAL级别。

统计量在内存中（也就是在SGA内的数据结构中）累积。因为统计量只反映实例所作的动作，所以并不影响实例的性能。在默认情况下，MMON进程每1小时将统计量作为一个快照保存至AWR。MMON进程直接访问构成SGA的内存结构，从而也可以访问这些内存结构中的统计量。这个进程可以在不需要通过会话的情况下从SGA内抽取数据。唯一的系统开销是将数据实际写入AWR。

AWR的位置和大小。AWR位于SYSAUX表空间内，并且不能被重新定位至其他位置，存在于SYSMAN模式中。ORACLE不支持使用除了DBMS程序包程序形式提供的各种API外的其他工具访问AWR。访问AWR最简单的形式是EMDC。写入AWR的统计量叫快照。快照默认保存在AWR中7天，这个周期是可配置的。如果每小时一次快照收集并且快照保留时间为7天，则AWR在SYSAXU表空间内可能需要200-300M的空间。这个数字总会发生变化，并根据会话数会被大幅提高。调整AWR设置从而能够更频繁地保存快照，这样可以更精确地诊断问题。但过于频繁地收集快照又会增加AWR的大小，并且可能会因为收集信息和保存所增加的工作负荷而影响性能。

快照会在特定时间周期后被清除。默认情况下时间周期为7天。创建长时间保存的快照意味着可随时比较当前的性能与过去任意时刻的性能，这对于固定趋势分析来说至关重要。ADDM报告自身默认保存30天。如果长时间保存快照，则总能够重新生成ADDM报告。

诊断与调整顾问程序
ADDM(Automatic Database Diagnostic Monitor,数据库自动诊断监视程序)：研究在保存AWR快照时自动生成的ADDM报告是DBA的一项日常事务。ADDM报告突出说明了数据库内的问题以及建议的解决方法。其他顾问程序必须被手动调用，与ADDM相比能够给出更准确的诊断信息与建议。
其他顾问程序：
SQL Tuning Advisor:SQL调整顾问程序
SQL Access Advisor:SQL访问顾问程序
Memory Advisor :内存顾问程序
Mean Time to Recover(MTTR)Advisor:平均恢复时间顾问程序
Segment Advisor:段顾问程序
Undo Advisor: 撤销顾问程序

只要生成快照，MMON进程就会自动运行ADDM。ADDM接受来自AWR的统计量及其他信息。自动生成的ADDM报告总会涉及当前快照与前一个快照之间的时间段。因此在默认情况下可以访问每小时的ADDM报告。如果希望ADDM报告跨越更长的时间范围，可以手动调用ADDM生成涉及任意两个快照之间时间段的报告。自动快照及手动收集快照都会触发ADDM。

SQL Tuning Advisor:将一条或多条SQL语句作为输入，并且研究这些语句的结构与执行方式。这些SQL语句被称为SQL Tuning Set。收集所涉及对象的优化器统计量，使用与语句执行相关的统计量生成SQL配置文件，修改代码从而更有效地使用SQL构造，重写代码，从而去除可能的设计错误。
SQL Access Advisor:也将SQL Tuning Set作为输入。研究通过添加索引或物化视图是否能够改善性能及某些索引与物化视图实际上是否会妨碍改善性能及是否应当被删除。评估通过创建其他索引与物化视图是否能够改善性能，建议删除虽然存在但未被使用的索引与物化视图。
Memory Advisor:高速缓存区的大小减少至40MB以下会带来惨重损失。如果为SGA结构或PGA分配更多的内存，则性能会得到进一步改善，不守效益会递减。如果可能因为交换系统而需要减少内存的使用，则就能够节省内存，但如果节省的内存过多，性能就将会退化。
MTTR Advisor：恢复进程能够确保数据库在发生任何情况下都不会由于实例的崩溃而导致讹误。MTTR通常被构建在服务级别协议内。以秒为单位进行设置的实例参数FAST_START_RECOVERY_TARGET能够控制MTTR。该参数设置的时间越短，在实例崩溃后就越能更快地打开数据库，不过联机性能会更差。为了最小化恢复时间，ORACLE必须向磁盘写入更多的数据，但是这样会对性能产生更不利的影响。
Segment Advisor：ORACLE中，段会自动地增长，但不会自动地缩短。该顾问会查看段，并且能够确定为未被使用的段所分配的空间大小是否足够用于执行SHRINK SPACE操作。

Undo Advisor：决定撤销表空间大小的算法基于下列方面：每秒钟生成撤销的速度，存储满足查询运行时间最长需求的数据的秒数，并且可能使用闪回查询。

创建AWR快照：exec dbms_workload_repository.create_snapshot;

服务器生成的告警：
告警系统的安装与启用是自动的。
告警系统体系结构：
MMON后台进程是一个易管理的监视器，该进程可以观察实例与数据库。如果某种指标过于偏离期望值，则MMON进程就会生成一个告警。MMON进程生成的所有告警都被置入SYS模式中的队列ALERT_QUE。为了查看告警消息，就必须订阅告警队列。可以使用高级队列API(DBMS_AQ程序包)编写自己的，用于查看告警的例程。通过自动订阅告警队列的EMDC来查看告警是最简单的方式。
告警具有两种形式：阈值(有状态的)或无阈值(无状态的)。配置阈值告警时，必须设置某些要监视的指标值。当越过阈值时，就会引发一个告警，并且该告警在采用使用指标值低于触发值的某些动作之前一直持续。无阈值告警由某个发生后并不持久的事件触发，如ORA-1555:snapshot too old(快照过旧)错误。告警通过MMON后台进程发送，并通过EMDC显示。

十六、管理撤销
撤销的原因与实质
回滚某个事务意味意味阒使用撤销段中的数据来构造一个与事务发生前相同的数据映像。通过查询DBA_SEGMENTS视图可以确定回滚与撤销的不同。撤销段只能存在于一个撤销表空间内，而这只是撤销段的一个特性。在数据库创建阶段可能不存在撤销表空间。除了数据字典外，ORACLE还会在SYSTEM表空间内创建一个过时的回滚段。该回滚段在数据库创建期间使用，决不会在正常运行期间使用。所有用户都会使用撤销段，这些撤销段在DBA_SEGMENTS的segmgent_type中显示TYPE2 UNDO，回滚段显示为rollback，也称为TYPE1 UNDO。如果数据库已被转换使用撤销段，并且自动进行撤销管理，则任何现有的回滚段都必须处于脱机模式中，且不能被设置为联机，因此完全有理由去除这些回滚段。撤销段的使用与回滚段的使用相矛盾：根据UNDO_MANAGEMENT参数的不同设置，ORACLE数据库要么使用撤销段，要么使用回滚段。

撤销段只能存在于专门针对撤销目的创建的某个表空间内，而回滚段则可以被创建在任何表空间内。如果创建了多个撤销表空间则在任意给定时刻都只能使用其中一个撤销表空间，但RAC情况下除外。在RAC环境中，打开该数据库的每个实例都会使用自己的撤销表空间。
撤销表空间必须被创建为持久的，本地管理的并且能够自动扩展分配空间的表空间。在创建之后，管理命令通常被限制为物理操作。
dba_rollback_segs视图可以查看数据库中所有撤销段或回滚段的记录。

事务与撤销段
在某个事务启动时，ORACLE会为其指派一个(并且只能指派一个)撤销段。任何事务生成的撤销数据都无法被分配到多个撤销段中。如果某个事务生成的撤销数据填满了自己使用的撤销段，则ORACLE会自动为该撤销段添加另一个区间，从而使这个事务能够继续进行。虽然多个事务可以共享一个撤销段，但在数据库正常运行时就不会发生这种情况。
撤销管理的一个特性是ORACLE会根据需要自动生成新的撤销段，从而能够尽可能地确保多个事务不必共享撤销段。同样也会自动缩小或删除撤销段。
在某个事务更新表和索引数据块时，回滚该变化所需的信息会被写入指定撤销表空间的数据块。所有撤销数据一直会被保持至事务被提交。在默认情况下，ORACLE不会保证ACID测试的一致性，只能在一定的程度上保证一致性：某个查询成功，则查询结果会与这个查询开始时的数据库的状态一致。但能绝对保证ACID测试的原子性。撤销数据被分为两部分：Active撤销是回滚当前事务可能需要的撤销数据，在事务结束之前，这些数据不会被重写；Expired撤销是指事务被提交后ORACLE不再需要保存的撤销数据，如果ORACLE需要为当前的其他事务提供空间，则可以重写这些数据。
撤销数据在提交后过期意味着可以采用循环方式使用撤销段。最终，撤销数据会填满整个撤销表空间。可以通过查询V$TRANSACTION视图(该视图将V$SESSION与DBA_ROLLBACK_SEGS的列连接在一起)来查看为每个事务所指派的段。

管理撤销
管理撤销的原则：应该始终存在允许所有事务继续进行的足够撤销空间，要求撤销表空间大到足以应付撤销需求的最坏情况；
应该始终存在保证查询成功的足够撤销数据，要求撤销表空间内存在额外的空间，这些空间能够存储读一致性可能需要的过期撤销数据，从而长时间运行的查询不会因为出现快照过旧ORA-1555错误而失败。
如果某个事务耗尽了撤销空间，则该事务就会由于ORA-30036无法扩展撤销表空间内的撤销段而失败。导致该错误的语句会回滚，但指定事务的剩余部分会保持不变并不被提交。当且仅当撤销表空间被过期的撤销数据完全填满时才会引发这个错误条件。如果某个查询由于快照过旧而导致一致读失败，就意味着该查询会涉及一个在查询开始后发生变化的数据块，但当进入该撤销段查找原有数据时，撤销数据已被重写。

UNDO_MANAGEMENT:默认值为manual，表示ORACLE根本不会使用撤销段。应用该设置必须完成大量创建和调整回滚段的工作；auto表示启用使用撤销段的自动撤销管理。该参数是静态的，意味着参数发生变化只有在重新启动实例后才能生效。
UNDO_TABLESPACE:启用UNDO_MANAGEMENT=auto后，就必须指定该参数。该参数指定了一个作为有效撤销表空间的表空间，且该表空间必须已被创建为一个撤销表空间，同时其内部的所有撤销段都会被自动联机即，使撤销段可用；
UNDO_RETENTION:以秒为单位进行设置的可选参数。该参数指定了保留过期撤销数据的时间，以保证数据库不出现ORA-1555错误。如果没有设置这个参数或将其设置为0，则ORACLE仍会尽可能长时间地保留撤销数据。UNDO_RETENTION参数的最大值总与撤销表空间的大小一致。
如果配置了保证撤销保留（见后），则UNDO_RETENTION参数就不是可选的。针对撤销的默认操作模式是：对于事务与查询来说，ORACLE更倾向于维护事务。如果在查询可能出现ORA-1555失败与事务必定出现ORA-30036失败之间选择撤销表空间的大小，则ORACLE会通过重写查询所需的已提交撤销数据使指定事务继续进行。UNDO_RETENTION是 ORACLE试图达到的唯一目标。
ORACLE10G版本中存在保证撤销保留的选项。经过UNDO_RETENTION参数所设定的时间之前，撤销数据决不会被重写。在表空间层次上通过Retention Guarantee子句就能够启用撤销保留保证。可以在创建撤销表空间或修改撤销表空间时启用该特性。一旦激活某个已被指定保留保证的撤销表空间，如果所有查询都能够在撤销保留时间内结束，则这些查询都将成功完成，而且也不会再次接收到快照过旧的错误。由于ORACLE在经过保留时间前不会重写已提交的撤销数据，故不利的方面是事务可能由于缺乏撤销表空间而导致失败。我们可以通过SQL*PLUS中更改某个表空间的撤销保留保证，但无法通过EMDC来完成。

调整与监视撤销表空间
撤销表空间应该足够大，这样才能存储并发事务生成的所有撤销数据的最坏情况，这些数据是有效的撤销数据及长时间运行查询所需的过期撤销数据。在更高级的环境中，最好还应该添加允许闪回查询的空间。算法是：首先计算在最高工作负荷时生成撤销的速度，然后再乘以最长的查询的时间长度。
查询V$UNDOSTAT视图可以得到需要知道的所有信息。

删除与缩小撤销段
创建一个撤销表空间时，ORACLE会在这个表空间内创建一个撤销段池。如果并发事务数超过了这个池中的撤销段数，则ORACLE会创建更多的撤销段。如果某个事务的撤销数据超过了其撤销段的大小，则这个撤销段也会被扩展。在正常运行期间，如果撤销表空间受到与空间相关的压力，则ORACLE就会在必要时自动将过期撤销数据的区间从一个撤销段转移至另一个撤销段，从而确保撤销段的空间足够保存当前运行事务所产生的有效撤销数据。用于重新分配撤销表大小甚至删除撤销表的额外机制由SMON驱动。每隔24小时，SMON进程都会查看撤销表空间，并且删除用于满足最高工作负荷要求但已不再需要的撤销段，则时还会缩小过大的撤销段。
如果撤销段被填满，则这个撤销段的大小会根据这个事务的撤销数据量按需要增加；
执行一条DML语句时磁盘上的数据与撤销块都会被更新，并且相应的变化会被写至日志缓冲区；
即使使用了自动的撤销管理段，但仍遇到快照过旧错误，则应该首先调整查询，再加撤销表空间，启用撤销保留保证。
针对一连串SET transaction read only设置要求广泛地使用撤销数据，故会导致快照过旧错误。

十七、处理锁定
借助于记录和表锁定机制，可以实现并行访问的串行化。ORACLE中，锁定是完全自动的。

共享锁和排他锁：在指定记录上请求排他锁的第一个会话将得到这个锁定，其他请求对该记录进行写访问的会话则必须等待。即每次只能有一个会话可以获得排他锁。指定记录上的排他锁只有在COMMIT或ROLLBACK后才会被解除。共享表被设置于整个表上，多个会话可以获得同一个表上的共享锁。设置共享所的目的是为了防止另一会话获得这个表上的排他锁。在表上放置排他锁时需要执行DDL语句。执行DML语句，当前会话必须获取待更改记录上的排他锁及包含这些记录表上的共享锁。
DML语句至少需要受影响记录上的排他锁及包含这些记录表上的共享锁。排他锁能够防止其他会话干预指定记录，共享锁则能阻止其他会话使用DDL语句修改表的定义。这两种锁定会被自动请求。如果某DML语句在指定记录上无法获得所需的排他锁，则该语句将被挂起直至获得所需的排他锁。
DDL语句需要使用所涉及对象上的排他锁。只有在针对指定表的所有DML事务结束，且记录上的排他锁及表上的共享锁都被解除后，才能获得执行DDL命令所需的排他锁。任何DDL语句所需的排他锁都是自动请求的，但如果无法获取需要的排他锁，则DDL语句会立即终止。

请求锁定需要排队。如果不希望某个会话在无法获取锁定时进行排队，唯一的方法就是使用SELECT FOR UPDATE命令的WAIT或NOWAIT子句。由于SELECT不需要任何锁定故普通的SELECT语句总是能够成功的执行，但DML语句会挂起。SELECT FOR UPDATE命令采用专有的模式来选择和锁定记录。如果某条记录被锁定，则在锁定释放之前，SELECT FOR UPDATE语句就会像DML一样进行排队并挂起会话。使用SELECT FOR UPDATE NOWAIT和SELECT FOR UPDATE WAIT n就可以避免挂起会话，n是以秒为单位的数值。使用SELECT FOR UPDATE的任一子句获得锁定后，就可以在不必挂起的情况下执行DML命令。如果使用NOWAIT子句则会在无法获得锁定的情况下立即终止语句。使用WAIT n子句会在无法获得锁定的情况下等待n秒，如果n秒后还无法获得锁定则立即终止语句。

锁定争用机制：当某个会话请求一条记录或一个对象上的锁定时，由于其他会话已经获取了该记录或对象上的排他锁而无法获取锁定时，这个会话将挂起，这种现象称为锁定争用。死锁是锁定争用的一种特殊情况，通常由数据库本身自动解决。
SET TRANSACTION READ ONLY语句能够保证在不带来任何锁定的前提下，该会话不会看到任何表上被提交或未被提交的任何DML语句，直至使用COMMIT或ROLLBACK命令终止这个只读事务。
在紧急情况下，DBA能够通过终止长时间拥有过多锁定的会话来解决锁定争用的问题。强制终止某个会话时，该会话拥有的任何锁定都会在回滚其作用的事务时同时被释放。此时被锁定的会话将被释放并继续执行。可以通过EMDC功ALTER SYSTEM KILL SESSION 'session_id,session serial Number'来终止指定会话。
死锁不是DBA的问题并且数据库自身能够自动解决死锁。与死锁相关的信息会被写入告警日志，并且被详细记录至某个跟踪文件。除了报告死锁的发生之外，DBA不需要完成针对死锁的操作。死锁问题由ORACLE数据库自动解决的。死锁是一种程序设计错误。告警日志位于BACKGROUND_DUMP_DEST实例参数指定的目录内，并且名为alert_<instance_name>.log。告警日志最后一个条目会告诉跟踪文件的位置。跟踪文件位于USER_DUMP_DEST实例参数指定的目录内。ORACLE会通过回滚导致死锁的某条语句来解决死锁问题。
锁定是由排队机制实现的，队列跟踪了已被请求的锁定，并且队列中的锁定排列顺序与锁定被请求的顺序一致。在等待排队时，会话将被挂起。针对表和记录的锁定是完全自动的。

十八、配置数据库的备份与恢复
重做与撤销机制都能保证数据库绝对不会出现讹误。
服务级别与备份和恢复相关的三个方面：MTBF(mean time between failures,平均失败时间)，MTTR(mean time to recover,平均恢复时间)和数据损失量。DBA的目标就是减少MTTR和数据损失量的同时增加MTBF。MTBF是指数据库出现失败的频繁度。ORACLE提供了两种有助于百分之百可用性的高级选项：RAC和Streams。RAC数据库由位于多台计算机上的多个实例所打开的一个物理数据库组成。RAC使硬件，操作系统与软件免遭失败。Streams环境由位于不同计算机上的两个或多个数据库组成。Streams能够根据需要保持两个数据库实时同步。Streams选项使磁盘和网络免遭失败及硬件，操作系统与软件免遭失败，与RAC相比，其容错能力更强。MTTR是指数据库出现失败后的停机时间。Data Guard实现使数据库在任何情况下都不会损失数据。在Data Guard系统中，实际运行的数据库(被称为主数据库)受到一个或多个备用数据库的保护。RAC、Streams和Data Guard选项都不会对性能造成影响。任何容错系统都特别依赖于硬件冗余。DBA需要与系统管理员一起实现容错功能。

失败类别：
1.语句失败：无效数据是语句失败的常见原因。应用程序中的逻辑错误、空间管理问题和缺少权限也是语句失败的一个原因。如果执行alter session enable resumable，指定会话就不会告知任何与空间相关的问题，而是将问题挂起直至解决。使用RESUMABLE_TIMEOUT参数可以为整个实例启用可恢复的空间分配。
2.用户进程失败：用户并非登出的异常退出，终端的重启；导致地址违规的程序。PMON后台进程通过定时轮询所有的服务器进程来确定会话的状态。如果某个服务器进程报告失去了与其用户进程的联系，此时PMON进程会解决这个问题。如果指定的会话位于某个事务的中部，PMON会首先回滚这个事务并释放所有锁定，然后终止该服务器进程，同时将PGA释放回操作系统。
3.网络失败：DBA应当能够通过配置ORACLE NET来杜绝网络失败。此时需要考虑三个方面：侦听器，网络接口卡及路由。侦听器能够完成的工作量是有限的。一个侦听器每次只能为一个连接请求服务，并且需要在适当的时间内启动一个服务器进程及将庐服务器进程连接到某个用户进程。可通过配置多个侦听器及使用连接时的负载均衡，在所有侦听器之间分散这些工作量。
4.用户错误：解决用户错误的理想方式是防止该类错误的出现。闪回查询，闪回删除，Log Miner、不完全恢复及闪回数据库可以解决用户错误。闪回查询针对过去某时存在的数据库所运行的查询。通过使用撤销数据，就可只为当前会话构造读一致的数据库。闪回删除倒退了DROP TABLE命令的结果。在旧的ORACLE中，DROP命令能够从数据字典中删除对指定表的所有引用，使该命令无法倒退，甚至闪回查询也将失败，因为闪回查询机制需要数据字典对象定义。在10G中，DROP命令，如果没有特别的要求，则该命令不再进行任何删除操作，而仅仅重命名对象。Log Miner是一种从联机和归档的重做日志中抽取信息的工具。重做包含数据块发生的所有变化。与闪回查询相同的是，都是根据撤销数据构造倒退变化所需的信息。与闪回查询不同的是，闪回查询使用当前存在于撤销段内的撤销数据，而Log Miner则从重做日志中抽取数据。闪回查询只能返回至撤销表空间所允许的时刻，而Log Miner在有相关日志的副本的情况下，能够返回至先前的任意时刻。不完全恢复与闪回数据库使整个数据库会返回至发生错误前的时刻。即会损失从返回时刻开始的所有工作，而不仅仅只损失错误的事务。
5.介质失败：控制文件和联机重做日志应当始终通过复用技术进行保护。数据文件无法被复用，一旦某个数据文件被破坏，唯一的选择就是从备份中还原这个数据文件，同时通过从联机和归档的重做日志中抽取的变化将数据文件返回至受损之前的状态。归档的重做日志文件是在每次日志切换后生成的联机重做日志的副本。为了应对介质失败，必须生成控制文件，联机重做日志文件及归档的重做日志文件的多个副本，必须对控制文件，数据文件及归档日志文件进行备份，不必备份重做日志，重做日志在被复制至归档日志时会进行备份。复用并不能保护数据文件，数据文件必须通过硬件冗余保护。
6.实例失败：实例的无序关闭，通常称为崩溃。断电，关闭或重启服务器及许多至关重要的硬件问题都会导致实例失败。实例失败的结果与执行SHUTDOWN ABORT命令的结果相同。

实例恢复：如果数据库出现讹误 ，ORACLE会自动检测到这种状况，并且通过执行实例恢复去除讹误。实例恢复是完全自动的。如果实例恢复失败，唯一的可能是在实例失败的同时还存在介质失败。实例恢复分为前滚和回滚两个阶段，均是自动完成的。前滚是使用联机日志文件的内容将数据库高速缓存区重新构建至崩溃之前的状态。完成前滚后，就能打开数据库。该阶段将恢复所有变化(针对已提交和未提交事务的数据块变化与撤销块变化)。此时数据库仍存在讹误，因为数据库中存在未提交的事务，这些事务必须回滚。ORACLE在实例恢复的回滚阶段自动完成未提交事务的回滚。通过执行STARTUP命令可以自动调用实例恢复。执行SHUTDOWN ABORT命令会造成数据库崩溃，但不可能造成数据库讹误。

调整实例恢复：MTTR是各种事件出现后的平均恢复时间。这个时间取决于两个因素：需要读取的重做数及应用重做时需要在数据文件上完成的读写操作数。这两个因素都受到检查点的控制。检查点保证了在某个特定的时间，DBWn进程将构成一个特定系统更改号(System Change Number,SCN)的所有数据变化都已写入数据文件。在一个实例崩溃事件中，只有SMON进程需要重演从上一个检查点位置开始生成的重做。无论是否被提交，在这个检查点之前所做的全部变化都已被写入数据文件。因此，不需要使用重做来重新构造在该检查点这前已提交的事务。对于该检查点之前未提交的事务所做的变化也会被写入数据文件，也不需要重新构造该检查点这前的撤销数据，回滚需要使用的这些数据已经存在于磁盘上的撤销段内。检查点越近实例恢复就会越快。FAST_START_MTTR_TARGET参数使得对实例恢复时间的控制变得十分容易。以秒为单位指定该参数，ORACLE随后将确认DBWn进程在实例崩溃后能够以足够快的速度将数据块写至磁盘，从而不会超过指定的秒数。设置的FAST_START_MTTR_TARGET参数值越小，DBWn进程将会更努力地尝试最小化检查点位置与实际时间之间的间隔。可以从V$INSTANCE_RECOVERY视图中获得详细的信息。

配置数据库的可恢复性
为了保证数据库具有最大程度的可恢复性，必须复用控制文件与联机重做日志，必须在archivelog模式中运行数据库，同时必须复用归档日志文件，还必须定期备份数据库。
控制文件用于加载数据库，并且在数据库打开时被频繁地读写。控制文件最多具有8个被复用的副本，并且应该放置在不同的物理设备上。ORACLE确保控制文件的副本完全相同。一个控制文件的损坏会导致停机，一旦ORACLE检测到某个控制文件被损坏或丢失，实例就会由于实例失败而终止。为了移动或添加一个控制文件，首先需要关闭数据库。在数据库打开时，不能进行任何控制文件操作。接着使用操作系统命令移动或复制控制文件。随后编辑指向新位置的CONTROL_FILES参数。如果使用静态参数文件，直接可用文本编辑器进行编辑。如果使用动态参数文件，则需要在NOMOUNT模式中启动数据库，并且执行alter system set control_files= 命令。最后正常地打开数据库。
保护联机重做日志文件
ORACLE数据库运行时至少需要两个联机重做日志文件组，每个文件组至少需要一个成员。为安全起见，每个联机重做日志文件组至少都应当具有两个成员。
如果出现丢失当前联机日志文件组的所有备份，则数据就会丢失。因为实例崩溃后，SMON进程会使用当前联机日志文件组的内容进行前滚恢复，从而修复数据库中的任何讹误。如果当前联机日志文件组由于未被复用及一个成员因介质损坏破坏而变得不可用，则SMON进程就无法进行前滚恢复。如果不能通过前滚修正数据库的讹误，则无法打开数据库。尽量不将任何数据文件放置在与重做日志文件相同的设备中。如果一个LGWR进程不得不与DBWn进程及许多服务器进程竞争磁盘I/O资源，则数据库的性能可能退化。如果重做日志文件组的一个成员被损坏或丢失，则数据库在存在幸存成员的情况下仍然会保持打开状态。只要存在至少两个重做日志文件组且每个组至少具有一个有效的成员，数据库打开时也可以添加或删除重做日志文件组及组中的成员。V$LOG视图查看日志文件组信息和V$LOGFILE查看日志文件信息。V$LOG的STATUS列显示重做日志文件组的状态，CURRENT表示该日志组为当前日志组，ACTIVE表示如果实例失败，SMON将用该组进行实例恢复。在最近一次切换前，只有ACTIVE日志文件组正被使用。如果执行alter system checkpoint命令会使检查点位置是最近的。同一时刻只能具有一组活动的日志文件组；MEMBERS列显示该日志文件组具有的成员数量；SEQUENCE#列说明从数据库被创建开始总共发生过的日志切换，随着每次日志切换的发生，这个数字会被累加。执行alter system switch logfile;命令可以实施一次日志切换。如果在当前组已满时仍然存在正在执行的DML语句，则就会自动发生日志切换。无论是手动的还是自动的，日志切换都会使LGWR进程开始在下一个联机日志文件组中写入撤销数据。
每个重做日志文件组的成员都受到控制文件中若干设置的限制，并且是在数据库创建阶段确定的。MAXLOGMEMERS指令限制了每个组可以具有的最大成员数。MAXLOGFILES指令限制了数据库可以具有的重做日志文件组数。DBCA默认这两个数值分别为3和16。

archivelog模式与归档器进程：为了保证在介质失败后不丢失任何数据，就必须具有一条针对从数据库最近一次备份开始应用于数据库的所有变化的记录，在默认情况下，这种功能并未被激活。在切换日志时，会重写联机重做日志文件。将数据库移至archivelog模式能够确保如果联机重做日志文件没有首先被复制为归档日志，就不能被重写。这样将存在一系列归档日志文件，这些文件描述了应用于数据库的所有变化的完整历史。默认情况下，数据库是在archivelog模式中创建的，这就意味着日志切换在没有先进行复制的情况下会重写联机重做日志文件。（为什么？？？）此时数据库不会产生讹误 ，但如果数据文件因为介质失败被损坏，就会丢失数据。在数据库移至archivelog模式时，如果从最近一次数据库备份开始的所有归档日志文件可用，就不可能丢失数据。一旦数据库被转换至archivelog模式，就会自动启动一个新的后台进程ARCn。在默认情况下，ORACLE会启动两个ARCn，最多可启动10个归档器进程。如果数据库位于archivelog模式，实例会自动启动归档器进程。归档器进程在每次日志切换后将联机重做日志文件复制到一个归档日志文件，从而生成一串连续的且能用于恢复一个备份的日志文件。归档日志文件可以像联机日志文件一样被复用，但应当被迁移至脱机的存储设备中。ORACLE实例使用ARCn进程维护归档日志的创建过程，但DBA必须通过操作系统命令，RMAN或者第三方备份软件程序包控制归档日志文件至磁带的迁移过程。
数据库只有在关闭后位于加载模式中时才能被转换至archivelog模式，并且必须建立了SYSDBA连接的用户完成。还必须设置若干控制的所生成的归档日志名称和位置的初始化参数。这些名称必须唯一，否则会重写归档日志。
为确保从一个还原的备份中进行恢复，就需要最小化归档。也就是设置一个归档目的地。为安全起见，通常需要通过指定两个或多个目的地来复用归档日志文件。

实例恢复机制保证了ORACLE数据库绝对不会出现讹误，归档机制保证了在没有丢失当前未归档的连接重做日志文件组并具有足够备份的情况下绝对不会丢失数据。与控制文件不同的事，始终只能在数据库打开时管理联机重做日志文件。一次日志切换会实施归档操作。在数据库打开时，无法操纵的只有控制文件。

十九、备份ORACLE数据库
直接使用操作系统的实用程序就可以进行备份操作。但ORACLE强烈建议使用RMAN。RMAN的一个特别功能是集成了第三方磁带库。RMAN能够备份数据文件，控制文件，归档日志及服务器参数文件。

全部备份：所有数据文件，控制文件及服务器参数文件的备份，并不需要备份联机重做日志。联机重做日志文件通过复用与可选的归档受到保护。由于控制文件的所有复用副本都完全相同，备份时只要备份一个控制文件副本就可以了。只有用于永久表空间的数据文件才会被备份。RMAN不能备份用于临时表空间的临时文件，这些临时文件也不能被置入用于操作系统备份的备份模式。
部分备份：一个或多个数据文件以及控制文件的备份。部分备份与数据库的剩余部分肯定不会同步。部分备份只能在特定时刻数据库某部分的副本。如果必要从部分备份中还原一个文件，则这个文件在能够使用之前必须与数据库的其余部分同步，这意味着需要通过应用归档和联机重做日志文件中的变化使恢复的文件是最新的。只有在数据库位于archivelog模式中是，部分备份才有效。如果数据库没有在archivelog模式中运行，应当进行全部备份。
完整备份：是一个或多个数据文件的一个完整副本，这个副本可以是全部备份也可以是部分备份。
增量备份：是数据文件的某些数据块的一个备份，该备份只包含从最近一次完整备份以来被修改或添加的数据块。只有使用RMAN才能实现增量备份。增量备份远小于完整备份，其备份速度显著地快于完整备份的速度。无论数据库位于archivelog模式还是noarchivelog模式，增量备份都可以在数据库打开或关闭时进行。
脱机备份：在数据库关闭时生成的备份，也称为冷备份，关闭备份或一致备份。通常只有使用IMMEDIATE、TRANSACTIONAL或NORMAL关闭选项干净地关闭数据库时才能保证数据文件的一致性。
联机备份：在数据库正被使用时生成的备份，也称为开启备份，热备份或非一致备份。联机备份可以是全部备份也可以是部分备份，并且能够通过使用RMAN或操作系统命令来完成。不过只能在archivelog模式下才能进行。联机备份可以是完整备份也可以是部分增量备份。联机备份的一个数据文件不仅不会与任何特定的SCN同步，而且也不会与其他数据文件或控制文件同步。被还的联机备份总是需要通过使用联机和归档日志文件才能与数据库的其余部分同步。
映像副本：映像副本是某个文件的备份，并且每个字节都与源文件相同。映像副本不可能是增量备份，也不可能在磁带设备上生成。在使用操作系统命令进行备份时，如果没有压缩数据或将数据直接流入磁带，输入文件就是映像副本。数据库打开或关闭时可以由数据文件，控制文件及归档日志生成映像副本，仍然不能备份联机日志。
备份集：由RMAN生成的一种专有结构。是由一个或多个被称为片的物理文件组成的逻辑结构。备份片中包含了一个或多个数据库文件，这些数据库文件可以是数据文件、控制文件或归档日志文件。上述3种文件类型可以被任意组合在一个备份集内。只有RMAN才能译解备份集格式。RMAN还可以生成映像副本，且与操作系统命令生成的映像副本无法进行区分。备份集可以拥有增量备份。即使对于完整备份来说，组成备份集的备份片通常会显著地小于映像副本。因为备份集不会包含空的数据块。可根据自己的意愿在备份集中启用数据压缩。如果为磁带库安装了RMAN驱动程序，则RMAN可以将备份集直接流入磁带。映像副本只能在磁盘上生成，备份集则可以在磁盘或磁带上生成。数据文件，控制文件和归档日志文件的映像副本和备份集都可以是联机或脱机备份，全部或部分备份及完整备份。映像副本不可能是增量备份，在archivelog模式和noarchivelog模式中都可以进行。备份集只能由RMAN生成或还原。

RMAN设置
RMAN可以在不进行任何配置的情况下运行。

设备的设置：并行度，目标目录，生成备份集还是映像副本是用于磁盘备份的选项。并行度默认为1，意味着RMAN进程只会产生1个被称为通道的服务器进程来实际创建备份。对于脱机备份而言，希望尽快完成备份，对于联机备份而言，为了限制耗用的资源量，最好减缓备份的速度。磁盘备份位置可以是任意目录，如果未进行设置，默认是DB_RECOVERY_DEST参数的设置，而该参数默认为ORACLE_HOME目录中的flash_recovery_area目录。如果选择生成备份集还需要确定是否压缩数据。磁带设备的数量，磁带库专用的选项及是否压缩备份集是用于磁带备份的选项。在磁带上不可以生成映像备份。指定磁带设备的数量相当于磁盘备份指定并行度。确定执行磁带备份或磁盘备份时，必须在Host Credentials部分指定登入驻留数据库的机器的操作系统。因为RMAN通道需要采用一个操作系统身份，从而能够读写备份目的地。

备份集的设置：默认情况下，备份片的大小没有限制：整个备份集被物理存储于一个片或文件中。备份片大小的值设定需要与系统管理员协商沟通，最大值需要被设定为易于管理的值。可以通过指定多个副本来复用备份集。如果没有通过RAID或磁带镜像来保护备份目的地，就会带来额外的安全级别。

策略的设置：确定在生成备份(不包括控制文件和服务器参数文件)时是否备份控制文件和服务器参数文件；
确定是否通过排除最近一次备份以来未发生变化的文件来最优化备份：任何脱机的或标记为只读的数据文件只被备份一次 从而能够节省后续备份操作的时间与容量。
确定是否为加快增量备份启用数据块变化跟踪：ORACLE 10G的新特性。能够显著地影响增量备份所需的时间。如果选择该 选项，会启动变化跟踪写入器(Change Tracking Writer,CTWR)后台进程。CTWR进程会在一个块变化跟踪文件中写下被更新 的数据块的地址。在SQL*PLUS环境下通过执行ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'file_name'；
确定完整备份操作期间不需要备份的一个或多个表空间：Tablespaces Excluded From Database Backup选项。
Retention Policy:根据备份保留策略，RMAN可以删除被认为不再需要的备份。默认的备份保留策略是RMAN会保证所有数据 文件与每个归档日志只具有一个副本。更复杂的保留策略是恢复窗口策略，RMAN需要保证具有足够的完整备份、增量备份 及归档日志备份，从而能够还原数据库并将其恢复至先前的任意时刻(默认是31天前)；

控制文件备份:是一种用于跟踪的备份。如果控制文件的所有副本都受损，那么有时候不必还原控制文件一个备份就能够更容易地重新创建控制文件。如果需要修改控制文件内部的任何设置，也可以通过某种方式重新创建控制文件。用于跟踪的备份会使用CREATE CONTROLFILE命令生成一个控制文件的创建脚本，该脚本可以在编写完成后运行，也可以在需要调整任何设置的情况下进行编辑。在SQL*PLUS中执行ALTER DATABASE BACKUP CONTROLFILE TO TRACE命令或选择相应的DC选项，就可以在USER_DUMP_DEST参数指定的目录中创建一个文件。我们应该将该文件重命名为有意义的名称，同时将其复制至安全的位置。理想情况下，在数据库每次出现结构化变化后，都应当生成和保存一个新的跟踪文件。

管理RMAN备份
DC不会在一个备份集中混合各种文件类型，但从命令行中则可以实现。

默认的备份目的地：闪回恢复区基于磁盘的存储结构。在ORACLE10g中，闪回恢复区被用作存储与恢复相关的数据的默认位置。这些数据包括：控制文件和联机重做日志文件的复用副本；归档日志目的地；RMAN备份集与映像副本；闪回日志。闪回恢复区受到DB_RECOVERY_FILE_DEST和DB_RECOVERY_FILE_SIZE参数的控制。这两个参数都不具有默认值。但在用DBCA创建数据库是，DBCA将DB_RECOVERY_FILE_DEST设置为ORACLE_HOME主目录中的flash_recovery_area目录，将DB_RECOVERY_SIZE设置为2MB。这两个参数都是静态的。一旦写至闪回恢复区的大量数据到达所指定的大小，就可能出现问题。因此对闪回恢复区的监视十分重要。通过查询V$RECOVERY_FILE_DESC视图可以得到闪回恢复区的相关信息。如果闪回恢复区中的文件变为多余的，则它们在需要时会被替换为更新的文件。RMAN与归档器进程都能够智能地发现闪回恢复区中某个文件何时不需要以及何时被重写。

如果数据库位于noarchivelog模式中，备份被限制为脱机的全部备份和RMAN进行增量备份。
可以限制备份片的大小，但无法预知备份集的大小，不能在一个备份集中同时存储完整备份和增量备份。我们可以通过ALTER DATABASE BACKUP CONTROLFILE来备份控制文件。
ORACLE Suggested策略遵循默认的设置：在每个周末进行一次全部备份，然后从每个周日夜间开始不断生成增量备份。
交叉检查期间，RMAN会读取所有磁带目录，从而确认备份片的存在。对于磁盘备份而言，RMAN会读取文件头，这两种情况下RMAN都不会通过扫描文件本身来确认这些文件确实有效。交叉检查发现某个备份丢失，则该备份就会被标记为过期备份。即交叉检查失败的备份是过期备份。

二十、恢复数据库
恢复结构与进程
对于受损的控制文件来说，既可以将其替换为某个复用副本，也可用CREATE CONTROLFILE命令重新创建。在极端情况下，可从备份中还原控制文件。
受损的联机重做日志文件可以被重新生成。ORACLE提供了一个ALTER DATABASE CLEAR LOGFILE GROUP#(#为受损成员的日志文件组号)命令，使用这个命令可以删除与重建某个日志文件组的成员。如果数据库在archivelog模式中运行并且应该在这个模式中运行，则日志文件组必须在ORACLE允许执行清除日志文件命令之前已被归档。因为清除未归档的日志文件组意味着归档日志流会丢失一个日志文件，从而不可能完成恢复。ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP#命令可以删除和重建一个即使已被成功归档的日志文件，但执行该命令后必须对整个数据库进行备份。
恢复受损的数据文件需要使用备份与归档日志。在导致某个数据文件受损的介质失败后，存在下列两种选项：完全恢复，不会丢失任何数据；不完全恢复，通过在完成前停止恢复进程来故意丢失一些数据。不完全恢复是一个高级过程。完全恢复是一个两阶段的过程：首先必须从备份中还原受损文件；随后，必须使用归档日志文件中的信息将数据库提前至被还原的文件与数据库其余部分同步的时刻，从而恢复这个文件。在ORACLE环境中，还原意味着使用备份替换受损的或丢失的文件，恢复意味着通过使用归档日志来同步受损文件与数据库其余部分。
因为RMAN从不备份联机重做日志，所以RMAN无法用于恢复受损的联机日志文件。使用SQL*PLUS或DC能够修复因介质失败而受损的联机重做日志文件。RMAN能够还原与恢复控制文件和数据文件。事实上，如果在备份集中备份了这些文件，使用RMAN是唯一的选择。
为了打开数据库，所有控制文件副本，每个联机日志文件组的至少一个成员及所有联机数据文件都必须存在且同步。如果SMON进程在启动期间发现情况并非如此，启动就不会完成。如果某个控制文件副本受损或丢失，启动会停止在NOMOUNT模式中，告警日志中会写下受损控制文件副本的详细信息。如果控制文件没有问题，SMON进程就将继续打开数据库。在这个阶段中，SMON进程会查看所有联机数据文件的头部。只要任何联机数据文件的头部受损或丢失，相应的错误消息都会被写入告警日志，并且数据库停留在加载模式中。如果所有联机文件都存在并且未受损，但某个或多个联机文件没有同步，SMON进程会尝试通过联机重做日志文件来同步这些文件。这是能够自动发生的实例恢复过程。如果所需的联机日志不可用，就无法打开数据库。如果一个或多个数据文件是通过备份还原的，则这些文件几乎肯定已过期较长时间，联机重做日志文件也无法返回至恢复上述文件的时间，此时，必须使用归档日志文件来进行恢复，这是一个必须手工启动的过程：如果使用操作系统命令进行备份，就需要在SQL*PLUS中启动这个过程，如果使用RMAN进行备份，就需要使用RMAN启动这个过程。
如果在数据库打开时出现介质损坏，其结果取决于受影响的文件。任何控制文件副本受损都会导致实例立即终止。作为SYSTEM表空间或活动的撤销表空间一部分的数据文件受损也会造成同样的结果。但是，在联机日志受损时，只要日志文件组中存在幸存成员，就不会造成实例的终止。事实上，实例会继续运行，终端用户甚至无法察觉联机日志文件受损的情况。不过，相应的错误消息会被写入告警日志，这种状况应当被立即修正，修正能够而且应当在用户可以继续工作的联机状态下完成。作为除了SYSTEM表空间或活动的撤销表空间之外的表空间一部分的数据文件受损也不会导致实例失败，但因为数据库的某部分丢失，所以终端用户可能遇到问题。如果受损数据文件不属于SYSTEM表空间或活动的撤销表空间，就能够联机完成这些数据文件的还原和恢复。
与备份一样，使用RMAN或操作系统实用程序也可以完成还原操作。但是RMAN备份操作生成的是备份集而非映像副本，就只能使用RMAN进行还原操作。可以使用RMAN或操作系统衫程序可以完成还原之后的恢复操作，但存在同样的限制：只有RMAN才能从备份集中抽取归档日志。

介质失败后的恢复
恢复受损的复用控制文件：只要存在幸存的复用控制文件副本，恢复工作只需要将受损或丢失的控制文件副本替换为幸存的控制文件副本就可以完成。从备份中还原受损或丢失的控制文件副本是无用的，还原的副本无法与幸存的副本保持同步也不能与数据库的其他部分同步。可以通过使用幸存的控制文件副本来替换受损或丢失的文件或者修改CONTORL_FILES初始化参数，将对受损文件的引用替换为对某个新文件的引用，并且将这个新文件复制为控制文件副本。恢复受损的控制文件时必须使数据库停机，该操作无法在联机状态下完成。

恢复受损的复用联机重做日志文件：在数据库打开时可以恢复复用的联机重做日志文件，因此不会造成数据库的停机。使用ALTER DATABASE CLEAR LOGFILE命令删除已有的日志文件(至少是仍然存在的日志文件)并且创建新的文件。这个操作只有在这些日志文件不活动时进行。如果试图清空当前的日志文件组，或者前一个日志文件组仍是活动的，就会收到出错的消息。如果数据库位于archivelog模式中，日志文件组必须已归档。

恢复受损的数据文件：必须先还原数据文件的一个备份，然后再应用归档日志同步数据文件与数据库的其余部分。根据数据库是否位于archivelog模式中，受损文件是运行ORACLE所需的重要文件还只包含用户数据的非重要文件，恢复数据文件时可以有多种可用的选项。

noarchivelog模式中数据文件的恢复：不存在恢复所需的归档日志文件，在该模式下中无执行恢复操作，只能完成还原操作。如果没有通过应用归档日志文件来同步一个被还原的数据文件与数据库其余部分，数据库就不能打开。noarchivelog模式中唯一选项是还原整个数据库(包括所有数据文件及控制文件)。但是会丢失这次备份之后的所有工作。因为RMAN不会备份联机重做日志文件，所以在执行完整的还原操作后，数据库仍然丢失这些文件，还原之后的启动操作会失败，数据库将停止在加载模式中。在加载模式中，可以通过执行ALTER DATABASE CLEAR LOGFILE GROUP#命令重建所有日志文件组，从而打开数据库。如果通过与RMAN接口的DC来执行还原操作，这个过程就是完全自动的。

archivelog模式中非重要数据文件的恢复：ORACLE数据库中，组成SYSTEM表空间及当前活动的撤销表空间(由UNDO_TABLESPACE参数决定)的数据文件被视为重要文件。任何重要的数据文件受损都会导致实例立即终止。在通过还原与恢复修复受损文件之前，数据库无法被再次打开。对于组成用于用户数据的表空间的数据文件来说，文件受损通常不会导致实例的崩溃。ORACLE会将这些受损的数据文件脱机并使其内容不可被访问，但数据库的其他部分应当保持为打开状态。如果备份是使用RMAN生成的，则受损数据文件的还原和恢复操作就是完全自动的。RMAN先智能地使用完整备份和增量备份，然后再应用必要的归档日志，从而尽可能地以最有效的方式完成还原操作。如果RMAN链接了某个磁带库，则会通过自动加载磁带来抽取所需的文件。只有在最近一次备份之后生成的所有归档日志文件都可用的情况下，才可以成功地完成数据文件的还原和完全恢复操作。为了在恢复操作期间进行还原，归档日志文件要么必须位于磁盘上的归档日志目的地目录中，要么已被迁移至磁带。RMAN能够自动地从备份集中抽取归档日志文件并将其还原至磁盘。如果归档日志文件出现丢失或讹误，则恢复操作就会失败。但是由于归档日志目的地与RMAN备份集能够并且应当被复用，因此绝对不会出现这样的情况。如果出现了恢复操作失败的情况，唯一的选项是通过完全还原以及不完全恢复得到丢失的归档日志文件，这意味着会丢失最近一次备份之后所进行的所有工作。

恢复受损的重要数据文件： 重要数据文件的受损或丢失会导致数据库无法打开。重要数据文件与非重要数据文件的恢复生还原完全相同，但重要数据文件应当在加载模式中完成还原和恢复。重要数据文件受损并不意味着会丢失数据，而是意味着会损失时间。

廿一、管理ORACLE数据库中的全球化特性
ORACLE的默认字符集为7比特的ASCII或7比特的EBCDIC。Unicode标准是一种用于字符编码的国际标准，并且包含了任何计算机系统需要的所有字符。目前，ASCII代码(American Standard Code for Information Interchange,美国信息交换标准代码)，EBCDIC(Extended Binary Coded Decimal Interchange Code,扩充的二进制编码的十进制交换码)，ISO(International Standards Organization,国际标准化组织)，ANSI(American National Standards Institute,美国国家标准化组织)。AL16UTF16:一种两字节的Unicode字符集，并且是ORACLE10g唯一支持的固定长度的Unicode字符集。可以通过查询V$NLS_VAILD_VALUES视图取得NLS的相关信息。

地区支持：选中某个地区可以默认设置许多NLS特性。选择地区还可以默认设置日期和周的编号，收支符号，日期格式，小数点分隔符与组分隔符及货币符号。

指定全球化级别（由低到高的优先级顺序）：
数据库，实例，客户机环境，会话，语句。在服务器端，实例设置优先于数据库设置，但是在服务器上的所有相关设置都会被客户端重写。
在创建数据库阶段必须正确完成的两个设置：DB_BLOCK_SIZE，该参数被用来指定SYSTEM表空间的块大小。如果没有重建数据库，就无法修改这个参数；数据库字符集，被用于存储VARCHAR2，CLOB，CHAR和LONG数据类型的所有数据。如果改变了字符集，可能销毁这些数据类型中已有的所有数据。
从9i开始，能够作为National Character Set被支持的两种Unicode字符集是AL16UTF16和UTF8。AL16UTF16是一个定长的两字节字符集，UTF8是一个长度可变的字符集。在两种字符集之间进行选择时，需要考虑与NVARCHAR2和NCLOB列中预计存储数据类型相关的空间效率及性能。要使用支持多种语言的数据库，可以使用Unicode字符集作为实际的数据库字符集，此时所支持的选项为UTF8和AL32UTF8，这两种字符集都是长度可变的多字节字符集。数据库字符集的唯一限制是必须将US7ASCII或EBCDIC作为一个子集，原因在于数据库字符集被用于存储SQL或PL/SQL源代码，而这些源代码采用上述类型字符编写的。默认的数据库字符集与National Character Set为US7ASCII与AL16UTF16。如果数据库是DBCA创建的，则DBCA会提供一个默认的数据库字符集，这个字符集与运行DBCA的操作系统的字符集相同。

改变数据库字符集：从9i开发虽然存在改变数据库字符集的方法，但是无法保证这种方法有效。DBA应当全面负责检查数据库字符集的改变不会损坏数据。ORACLE提供了下列两种有助于决定字符集修改的工具：数据库字符集扫描程序(Database Character Set Scanner)和语言与字符集文件扫描程序(Language and Character Set File Scanner)。在UNIX下分别为csscan和lcsscan，在WINDOWS下为csscan.exe和lcsscan.exe。为了使数据库能够运行数据库字符集扫描程序，必须首先运行csminst.sql脚本。语言与字符集文件扫描程序能够尝试标识用于文本文件的语言和字符集。判断能够无损地改变数据库字符集后，可以通过执行ALTER DATABASE CHARACTER SET命令来完成字符集的修改。改变National Character Set的等价命令为ALTER DATABASE NATIONAL CHARACTER SET。这条命令的唯一限制是目标字符集必须是原始字符集的一个超集，但是并不能保证不存在讹误。保证不出现讹误应当是DBA的责任。
数据库内的全球化：通过查看NLS_DATABASE_PARAMETERS视图可以查看NLS设置。
实例级别的全球化：在RAC环境中，不同的实例可以具有不同的设置。全球化实例参数是静态参数，在变化之前必须重启实例。NLS_INSTANCE_PARMAETERS视图给出了当前有效的设置，除与不应用于实例的字符集和RDBMS版本有关的3条记录外，该视图与NLS_DATABASE_PARAMETERS视图具有相同的记录；
客户端环境设置：NLS_LANG环境变量的3个元素：语言，地区和字符集都是可选的。NLS_LANG是一个关键的变量，其完整规范包括语言，地区和字符集。服务器与客户端全球化设置之间的转换由ORACLE NET完成，所有必要转换都是由ORACLE NET的双任务公共层实现的。
会话级别的全球化设置：ALTER SESSION命令来建立自己的全球化首选项。DBMS_SESSION程序包可以代替ALTER SESSION命令。会话级别的规范优先于服务器端数据库与实例级别的设置，而且还会重写用户使用环境变量配置其会话的各种尝试。V$NLS_PARAMETERS视图中显示了当前作用于会话的全球化设置。除字符集外，NLS_SESSION_PARAMETERS视图中也显示了相同的记录。
语句级别的全球化设置：是最优控制级别的全球化设置。

语言排序与选择：ORACLE默认使用二进制排序。

Locale Builder工具的使用：UNIX环境下：$ORACLE_HOME/nls/lbuilder/lbuilder，WINDOWS环境下：%ORACLE_HOME%/nls/lbuilder/lbuilder.bat。

时区：ORACLE环境能够知道所使用的时区。为了使用时区，需要指定数据库所动作的时区及使用TIMESTAMP WITH TIME ZONE与TIMESTAMP WITH LOCAL TIME_ZONE数据类型。前一种类型在被存储时不会被格式化至数据库时区，不过将具有一个时区指示标志，这个标志说明其引用的时区。后一种数据类型在被存储时会被格式化至数据库时区，随后在检索时被转换至客户机时区。普通的DATE和TIMESTAMP数据类型在被存储时始终会被格式化至数据库时区，并且在选中时被原样显示。可以使用CREATE DATABASE命令在创建数据库时设置时区，也可以在之后通过ALTER DATABASE SET TIME_ZONE=命令进行调整。如果没有进行设置，就会在创建数据库时将数据库时区默认为主机操作系统的时区。客户机时区默认为客户机操作系统的时区。使用ORA_STDZ环境变量也可以设置客户机时区。在会话内，使用ALTER SESSION SET TIME_ZONE也可以设置时区。使用完整的名字，简写的名字与格林威治标准时间的小时和分钟的固定偏移量都可以指定时区。指定偏移量的方法无法根据夏令时或冬令时进行相应的调整。V$TIMEZONE_NAMES视图中显示了被支持的所有时区。
全球化设置会影响消息的语言，排序顺序，日期格式，历法，日期和月份的名字或数值格式等。字符集的选择至关重要，并且涉及两上字符集的选择。数据库字符集被用于VARCHAR2，CLOB，CHAR和LONG列；National Character Set则用于NVARCHAR2，NCLOB和NCHAR列。
NLS_DATE_LANGUAGE与NLS_SORT由NLS_LANGUAGE控制的两个参数,NLS_DATE_FORMAT与NLS_NUMERIC_CHARACTERS参数由NLS_TERRITORY控制。
Character Set Scanner工具会报告改变字符集所导致的问题。视图V$NLS_VAILD_VALUES视图可以说明能够被支持的语言。

廿二、配置侦听器的安全性

保护侦听器的安全：为了显示常见的管理命令，可以在操作系统提示符下运行lsnrctl help命令。
侦听器的操作系统身份验证：侦听器管理命令默认的安全性基于操作系统用户ID。这种安全形式总会被启用，并且优先于口令安全性。即使不知道侦听器口令，但知道启动侦听器的用户的操作系统口令，仍然能够管理侦听器。
侦听器的口令身份验证可以为授予受保护命令的执行权限提供另外一种身份验证方法。通过NET MANAGER GUI,EMDC或手动编辑listener.ora文件都可启用和设置侦听器的口令。通过手工编辑listener.ora文件不会加密侦听器口令。
change_password:更改侦听器的口令；
save_config:将相关配置(如口令)保存到listener.ora。

控制对数据库的访问：默认的侦听器配置对能够连接数据库服务器的用户没有进行任何限制，必须在数据库或应用程序内管理所有的安全性。通过配置Oracle Net配置文件能够控制对侦听器的访问，配置文件事实上是服务器上sqlnet.ora文件的一组指令。这些指令包括：TCP.VALIDNODE_CHECKING,TCP.EXCLUDED_NODES,TCP.INVITED_NODES。一旦TCP.VALIDNODE_CHECKING从默认值NO变成YES，就会启用其他两条指令。事实上，只能设置其中一条指令。如果任何节点列在TCP.INVITED_NODES中，则其他所有的节点都将以隐性的方式排除在外；如果在TCP.EXCLUDED_NODES中列出了某个节点，则其他所有的节点都将以隐性的方式加入。如果以上两条都进行了设置并且存在冲突，会优先启用TCP.INVITED_NODES；被加入或被排除的节点可以按名称或IP列出，但不允许使用通配符，且只能应用于TCP。Connection Manager可以提供更大的访问控制能力，包括主机与IP中通配符的使用。
外部过程：外部过程必须以C语言编写，与OCI库链接的用户进程软件则可以以C或C++语言编写。在执行其中的代码之前，动态链接库必须完成动态的链接。侦听器会启动一个被称为外部过程代理程序的进程，该代码程序只具有一个函数，该函数通过动态地链接与运行外部过程来响应数据库用户的调用。向ORACLE通知共享对象库的存在，必须要执行CREATE LIBRARY 命令。如：
CREATE LIBRARY util_lib as 'file_name'；会创建逻辑指针util_lib,该指针会指向编程人员所交付的物理文件。

外部过程代理程序：是ORACLE_HOME/bin目录中的一个可执行文件。UNIX系统中，这个文件名为extproc;在WINDOWS中，这个文件名为extproc.exe。外部过程代理程序根据侦听器的要求启动。PL/SQL过程调用外部过程时，代理程序会将PL/SQL调用转为C调用，载入共享对象库，并且执行所请求的C语言函数。代理程序还能引发可能出现的任何异常，并且可以将异常或实参返回至PL/SQL环境。外部过程代理程序提供了
一些内置的安全性。在默认情况下，代理程序只从ORACLE_HOME/bin目录中载入共享对象库，这个目录应当受到严格的控制，否则恶意的用户就可以编写一个PL/SQL过程，而这个PL/SQL过程能够调用数据库服务器操作系统可用的任何标准共享库中的C过程。在实际应用中，比较好的作法是：在listener.ora文件中指定代理程序能够载入的共享库，从而进行一定的限制。

配置侦听器启动外部过程代理程序：代理程序根据需要启动，每个会话都有一个代理程序，并且这个代理程序在会话的生存期内保持活动状态。无论产生了多少个外部过程调用，每个会话都只会启动一次代理程序。配置外部过程服务时，可以选择键与SID名，甚至还可以指定要启动的进程。但是，必须使用IPC协议，且TNS别名必须为EXTPROC_CONNECTION_DATA。

侦听器默认启用操作系统身份验证，只有启动某个侦听器的操作系统用户才能停止这个侦听器。设置口令意味着只要知道口令则任何人都能够控制相应的侦听器。
在默认情况下，侦听器能够从任意节点链接用户与数据库，所有安全性必须由数据库服务器自身处理。编写一个节点列表说明被许可或丢弃的会话，从而能够在侦听器内建立访问控制。