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_INFO |
UNDO基本数据 |
包括空间名称; 表空间能达到的最大值; 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_AUTOTUNE |
UNDO自动调整功能是否打开 |
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=>'[email protected]',
RECIPIENTS=>'[email protected]',
SUBJECT=>'space warning',
MESSAGE=>'Space is full');
COMMIT;
END;