11gOCP 1z0-052 :2013-09-10 ABOUT ALERTS

正确答案:AD

使用服务器生成的警报系统,从Oracle10g版本开始，Oracle数据库凭借警报系统一举实现了”自我管理”。在早期版本中，DBA必须耗费大量的精力来处理一些必需的但枯燥无味的单调工作，还必须设计多个方法，在出现异常条件时捕获这些条件。

１、警报条件监视和通知

一项典型的单调任务示例是空间管理:在其最基本的层面，需要监视表这空间了解它们何时会变满。可以使用如下脚本完成此任务:

[html]

gyj@OCM> set line 200 pagesize 9999

gyj@OCM> select b.tablespace_name,round(sum(b.bytes)/1024/1024,0) sum_MB, round(sum(nvl(a.bytes,0))/1024/1024,0)

2 free_MB,round((sum(b.bytes)-sum(nvl(a.bytes,0)))/sum(b.bytes),4)*100 use_precent

3 from (select tablespace_name,file_id,sum(bytes) bytes from dba_free_space group by tablespace_name,file_id ) a,dba_data_files b

4 where a.file_id(+)=b.file_id and a.tablespace_name(+)=b.tablespace_name

5 group by b.tablespace_name;

order by use_precent;

TABLESPACE_NAME SUM_MB FREE_MB USE_PRECENT

------------------------------ ---------- ---------- -----------

TP1 10 9 10

UNDOTBS1 110 81 26.59

SYSAUX 690 58 91.53

GYJ 150 147 1.92

USERS 5 1 81.25

SYSTEM 730 8 98.87

EXAMPLE 346 36 89.73

但这些脚本易于出错，到少易于引起误解。例如，在DBA_FREE_SPACE视图中，每个表空间的每个空闲空间位对应着一行。但如果表空间满了，就一行也没有了。此时需要OUTER JOIN，否则无法列出SMALL表空间，即使其处于严重状态，也是如此。很多编写了多套SQL代码来报告空间使用情况,并在错误条件发生前发出警告。但这样做DBA工作量有点大，经常要编写，更新脚本。

警报系统顶替了大量的单调工作。它将监视很多可能导致问题的条件，并通过多种方法来发送通知。在空间管理方面，默认的配置方法是:在考虑自动扩展和内容本质的情况下，当表空间达到全满85%时，将引发警告性警报；当表空间达到全满97%时发出严重警报。

警报有两种形式:

“有状态警报”基本持久保存且可以修复的条件。例如表空间的使用、挂起的会话的数量，或执行完SQL语句的需要的平均时间。

“无状态警报”基于事件，事件发生后又消失了，例如，查询因”快照过旧”而失败或两个形成死锁的事务。

１、设置阈值

可以为200多个指示设置阈值，这些记录在V$METRICANAME视图中，其中给出了指示名称和度量单位，以及用于识别它的Id号码.

左下角度量和策略设置进入--->

１、通知系统

有状态警报的默认通知机制仅仅是在Enterprise Manger的数据库主页上显示警报，并将它们写入DBA_OUSTANDING_ALTER视图中。在清除之前，警报一直可见，如果DBA修改了问题，或着在某些情况下，问题在事件的自然发展过程中消失，则可能将其清除。例如表空间的警报通常要求DBA采取操作(如添加另一个数据文件)，而与活动相关的警报(如重做生成率)可能在活动减少自动清除。

在清除某个警报时，在数据库中，将该警报从DBA_OUTSTANDING_ALTERS视图删除，并写入DBA_ALERT_HISTORY视图。而无状态警报则直接进入历史视图。

如果需要除默认通知外的其他通知，就必须在ENTERPRISE MANGER中进行设置。ENTERPRISE MANGER通知系统要求三个级别的配置。

(1) 必须配置通知方法

(2) 必须创建规则来捕获事件

(3) 管理员必须订阅读

右上角设置进入--->