OEM上有指导中心。里面有ADDM、MTTR顾问、内存顾问、SQL顾问、段顾问、还原顾问、SQL性能分析器(11G)、自动回滚管理(11G)、Stream性能顾问(11G)。

要使用SGA，首先需要关闭ASMM。旁边有“建议”按钮，可以禁用相应窗口进行分析。

MTTR顾问

就是平均恢复故障时间顾问。

减小MTTR实际是指减小恢复时的日志数量。

原理：

当发生检查点时，DBWR把BUFFER CHACHE中的脏数据写回数据文件，由CKPT杀心数据文件头、控制文件的检查点信息。

首先LGWR在联机日志中记录一个针对这个数据块的BWR记录(Block Write

Record)，BWR相当于一个标志，意味着日志文件中在这个BWR拆谁出钱的，所有针对这个数据块的日志条目，在下次Recovery中都不需要了；其次，这块内存空间被表示为FREE，可以被重用。

ORACLE有两种检查机制：FULL CHECKPOINT和INCREMENTAL CHECKPINT。

FULL CHECKPOINT在两种情况下用到。

1、用户明确发出检查点命令(ALTER SYSTEM CHECKPOINT)2

2、数据库实例正常关闭时(SHUTDOWN IMMEDIATE/NORMAL/TRANSACTIONAL)。

此时所有BUFFER CHACHE中的脏数据都写到磁盘上，数据是同步的。

INCREMENTAL

CHECKPOINT是DBWR把最早的脏数据块写到磁盘，而CKPT每3秒更新控制文件。日志切换也触发INCREMENTAL检查点，代替早期ORACLE版本的FULL检查点。

可以调整一个FAST_START_MTTR_TARGET参数，单位是秒，含义是希望数据库能在这段时间内完成恢复，并提供用户使用。定义后，ORACLE尝试控制REDO

LOG的长度和BUFER CACHE中的脏数据块的数量，还有读REDO LOG数据块时间和读写一个DATA BLOCK的时间来计算出来的。

如果要获得当前实例的MTTR下限，就设成1.

SQL>ALTER SYSTEM SET FAST_START_MTTR_TARGET=1;

SQL>SHUTDOWN IMMEDIATE;

SQL>STARTUP;

SQL>SELECT TARGET_MTTR, ESTIMATED_MTTR FROM V$INSTANCE_RECOVERY;

其中TARGET_MTTR就当做CRASH RECOVERY的最小恢复时间就可以。

ESTIMATED_MTTR会在不同的时候查询，有不一样的值，因为不同时刻的BUFFER CACHE中脏数据块数量不同。

要获得当前实例的MTTR上限，就设成一个比较大的值，比如3600。

SQL>ALTER SYSTEM SET FAST_START_MTTR_TARGET=3600;

正常运行一段时间后，

SQL>SELECT TARGET_MTTR, ESTIMATED_MTTR FROM V$INSTANCE_RECOVERY;

这时的TARGET_MTTR就是上限值。

MTTR ADVISOR可以评估不同MTTR设置的影响。要启动MTTR ADVISOR需要：

1、STATISTICAL_LEVEL设置成TYPICAL或者ALL。

2、FAST_START_MTTR_TARGET设成非0。

评估结果从V$MTTR_TARGET_ADVICE中可以查看。

SQL>SELECT MTTR_TARGET_FOR_ESTIMATE, ADVICE_STATUS, ESTD_TOTAL_IOS,

ESTD_TOTAL_IO_FACTOR FROM V$MTTR_TARGET_ADVICE ORDER BY 1;

REDO LOG顾问：

REDO LOG顾问不在ADVISORY CENTRAL里，在MAINTAINANCE里。

使用它需要先开启FAST_START_MTTR_TARGET。

当日止切换时，都会有增量检查点，触发ARCn归档。LGWR能够切换日志成功的前提是日志完成了检查点，归档，否则表现为“CHECKPOINT NOT

COMPLETE”等待事件。

ORACLE建议在业务高峰时间切换频率应该在15~20分钟一次。

要查看日志切换时间，执行：

SQL> SELECT TO_CHAR(FIRST_TIME, 'YYYY-MM-DD HH24:MI:SS') FROM

V$ARCHIVED_LOG ORDER BY SEQUENCE#;

查看结果，多次调整。

另外，从V$INSTANCE_RECOVERY视图的OPTIMAL_LOGFILE_SIZE来查看推荐日志大小，单位是MB。如果当前小于它，应该调整到与建议值相当。

SQL>SELECT OPTIMAL_LOGFILE_SIZE FROM V$INSTANCE_RECOVERY;

这个值是从FAST_START_MTTR_TARGET影响而来的。

FAST_START_MTTR_TARGET和切换时间是一对矛盾。

FAST_START_MTTR_TARGET是越小越好，也就是LOG越小越好。而日志切换时间最好是在15~20分钟一次，所以是大一些比较好。需要经过计算来变成一个相对中庸的值。

UNDO顾问

如果使用

UNDO_RETENTION(缺省是900秒)

SQL>ALTER TABLESPACE UNDOTBS1 RETENTION GUARANTEE;

这样就是强制保留UNDO_RETENTION时间。

取消命令如下：

SQL>ALTER TABLEPSPACE UNDOTBS1 RETENTION NOGUARANTEE;

图上有一个保留时间(分钟)，一个所需空间大小(MB)。

从DBMS_UNDO_ADV方法中获得相同的信息。方法说明输出

UNDO_INFOUNDO基本数据包括空间名称；

表空间能达到的最大值；

UNDO_RETENTION参数当前配置；

UNDO表空间是否配置成自动扩展；

是否开启了强制UNDO保留策略。

LONGEST_QUERY运行时间最长的查询时间长度

REQUIRED_RETENTION最优的UNDO_RETENTION参数值；是根据上一个最长的查询做出的估计，目的是避免ORA-15555初始化参数UNDO_RETENTION

BEST_POSSIBLE_RETENTION根据UNDO空间大小和使用情况，给出最优的UNDO_RETENTION参数建议初始化参数UNDO_RETENTION

REQUIRED_UNDO_SIZE根据当前的系统负载以及UNDO_RETENTION参数值，计算需要的UNDO表空间UNDO表空间大小

UNDO_HEALTH根据当前系统负载特点和UNDO_RETENTION参数设置，总和评定UNDO表空间健康状况发现问题及解决方法描述

UNDO_ADVISOR利用ADVISOR框架，对当前UNDO配置做评价问题解决办法描述

UNDO_AUTOTUNEUNDO自动调整功能是否打开TRUE/FALSE

RBU_MIGRATION从9I开始使用AUTOMATIC UNDO MANAGEMENT (AUM)，可以估算需要的UNDO表空间大小需要的表空间大小

这些方法使用比较复杂。通常建议直接使用OEM。

SEGMENT顾问

9i中引入了Resumable Space Allocation特性，就是表空间耗尽的时候事务不会回滚，而是挂起，分配更多空间后，事务会继续进行。

10G允许DBA提前设置阈值，一个表空间两个。

一个是WARNING阈值，默认为85%，一个是CRITICAL阈值，默认97%。

MMON每10分钟检查表空间，当空间使用超过阈值和恢复到阈值以下时，都会在Alert.log日志记录。

如果表空间是允许自动扩展的，则表空间最大容量不是根据当前数据文件来计算，而是根据文件最大值(创建数据文件时的MAXSIZE和OS允许文件大小两者的最小值)。

数据字典方式管理的表空间不支持这种方式。

表空间预警通过两种方式设置，一种是OEM，一种是手动。

手动：

1、查看当前USER表空间配置

SQL>SELECT WARNING_VALUE, METRICS_NAME, OBJECT_NAME, CRITICAL_VALUE,

STATUS FROM DBA_THRESHOLDS

WHERE METRICS_NAME = 'Tablespace Space Usage';

2、查看系统产生的报警信息

SQL> SELECT REASON, MESSAGE_LEVEL,

DECODE(MESSAGE_LEVEL, 5, 'WARNING', 1, 'CRITICAL') as ALERT_LEVEL

FROM DBA_OUTSTANDING_ALERTS

WHERE object_name='USERS';

3、取消预警

BEGIN

DBMS_SERVER_ALERT.SET_THRESHOLD (

DBMS_SERVER_ALERT.TABLESPACE_PCT_FULL,

DBMS_SERVER_ALERT.OPERATOR_DO_NOT_CHECK, '0',

DBMS_SERVER_ALERT.OPERATOR_DO_NOT_CHECK, '0', 1, 1,

NULL,

DBMS_SERVER_ALERT.OBJECT_TYPE_TABLESPACE, 'USERS'

);

END;

4、使用SET改变两个阈值：

BEGIN

DBMS_SERVER_ALERT.SET_THRESHOLD (

DBMS_SERVER_ALERT.TABLESPACE_PCT_FULL,

DBMS_SERVER_ALERT.OPERATOR_DO_NOT_CHECK, '60',

DBMS_SERVER_ALERT.OPERATOR_DO_NOT_CHECK, '85', 1, 1,

NULL,

DBMS_SERVER_ALERT.OBJECT_TYPE_TABLESPACE, 'USERS'

);

END;

DBMS_SERVER_ALERT提供对异常的自动报警，有两种报警。

一种是发生了特殊事件，比如Snapshot Too Old或者Resumable Session Suspended，这种属于定性指标；

一种是指标发生波动，比如超过阈值，这种属于定量指标。

SEGMENT可以进行SHRINK处理，可以通过SEGMENT ADVISOR来或者收缩后的收益。

Resumable Space Allocation

如果有一个大处理，耗尽了存储空间或者遇到“maximum number of extents

reached”错误，首先应该终止进程，然后重新执行，而提交的事务要回滚。

而有了RESUMABLE SPACE ALLOCATION功能，ORACLE会暂时挂起，等到分配空间后继续执行事务。

表空间必须使用LMT(Local Managed Tablespace)和AUM(Automatic Undo Management)管理方式。

查询、DML、DDL、SQL*LOADER的IMPORT可以使用这个特性。

SQL*LOADER有RESUMABLE/RESUMABLE_TIMEOUT/RESUMABLE_NAME三个参数。后两个参数必须设置了RESUMABLE才奏效。

使用Resumable Space Allocation需要赋予USER一个GRANT RESUMABLE TO USER权限。

SQL>GRANT CONNECT, RESOUCE, RESUMABLE TO TEST;

当存储超限后，LAERT日志有：

ORA-01653：unable to extend table xxxx by xxx in ablespace xxx

还有ORA-01653，ORA-01628、ORA-01536错误。

启用RESUMABLE还需要修改参数

方法一，参数RESUMABLE_TIMEOUT，可以在SESSION和SYSTEM上设置。

方法二，直接ALTER SESSION ENABLE RESUMABLE TIMEOUT XXX;默认是7200秒

还可以用

SQL>EXECUTE DBMS_RESUMABLE.SET_SESSION_TIMEOUT(S_ID,

18000);来设置别的SESSION。

挂起时刻，从ALERT中查到：

ORA-01653: ….. SUSPENDED

Suspended说明是挂起，还没有回滚。如果超过设置的超时时间就会抛出错误，并且终止。这时，前台出现：

ORA-30032：the suspended (resumable) statement has timed out

ORA-01653：unable to extend table xxx by xxx in tablespace xxxx

ALERT日志出现：

Statement in resumable session ‘xxxx’ was timed out.

强行取消的情况下，不是timed out而是aborted

在视图中可以查到这种事件

SQL>SELECT REASON, TO_CHAR(TIME_SUGGESTED, 'YYYY-MM-DD HH24:MI:SS') TIME,

SUGGESTED_ACTION

FROM DBA_ALERT_HISTORY;

SQL>SELECT STATUS, TIMEOUT, NAME, SQL_TEST, ERROR_MSG FROM

DBA_RESUMABLE;

触发器通知：

CREATE OR REPLACE TRIGGER SPACE_RESUMABLE

AFTER SUSPEND ON DATABASE

DECLARE PRAGMA AUTONOMOUS_TRANSACTION;

BEGIN

UTL_MAIL.SEND(SENDER=>'XXX@XXX.COM',

RECIPIENTS=>'XX@XXX.COM',

SUBJECT=>'space warning',

MESSAGE=>'Space is full');

COMMIT;

END;