ADR简介

1.1 trace file
每个服务器进程和后台进程，都会将侦测到的内部错误的相关信息写进对应的trace文件。
可以使用MAX_DUMP_FILE_SIZE参数指定所有的trace文件（不包括alert日志）的最大尺寸
可以通过设置SQL_TRACE参数为TRUE开启SQL追踪功能，开启后所有的SQL语句就会形成性能统计信息存储在ADR的trace文件中；也可以使用
语句alter session set SQL_TRACE true开启指定会话的SQL追踪功能。同时可以使用DBMS_SESSION或DBMS_MONITOR包控制一个会话的SQL追踪。
1.2 alert log
告警日志主要包含以下信息和错误日志：
（1）所有的内部错误(ORA-600), 块中断错误(ORA-1578)以及死锁 (ORA-60)
（2）管理操作, 例如 CREATE、ALTER、DROP 语句和STARTUP、SHUTDOWN、ARCHIVELOG语句
（3）有关共享服务和调度进程的信息和错误
（4）物化视图自动refresh过程中发生的错误
（5）数据库实例启动时所有有非默认值的初始化参数的值
告警日志同时维护XML格式文件和text格式文件。可以通过text编辑器查看两种格式的文件，也可以使用ADRCI组件查看XML文件。
Alert日志文件盒所有的trace文件都写在Automatic Diagnostic Repository（ADR）中，ADR目录由DIAGNOSTIC_DEST初始化参数指定；trace文件名由操作系统指定，不过名称通常包含进程名

1>ADR错误可分为两个概念：问题（problem）和事故（incident）

problem：问题是数据库中的危险错误，其可以是内部错误，例如ORA-00600，也可以是其它服务器错误，例如ORA-07445、ORA-04031等；每个problem都
有问题键值（key），并附含字符串描述
incident：事故是问题的单一事件；每个事故都由唯一的事故ID确定，当事故发生时，数据库完成以下行为：
■ 在alert log中记录信息
■ 发送事故告警至OEM页面
■ 收集首次事故的诊断数据至incident dumps中
■ 在incident dumps之上附件事故ID标签
■ 在ADR中存储对应的incident dumps
2>事故洪流控制
鉴于同一个problem在短时间内会出现多次incident，对应的诊断数据的收集会对空间和性能带来一定的影响，所以引入事故洪流控制；当同一个问题下的事故出现次数达到指定阈值后，会引发洪流控制，变为受控事故。受控事故只形成alert log信息，并不形成incident dumps。
洪流控制的阈值是预定义且无法修改的，具体如下：
■ 相同problem key在一个小时内出现5次incident后，该问题下后续出现的事故变为受控事故；下一个小时将会恢复正常
■ 相同problem key在一天内出现25次incident后，该问题下后续出现的事故也会变为受控事故；下一天将会恢复正常
此外，如果同problem key一小时内出现50次incident，或一天内出现250次，则该problem key随后的incident将完全不在ADR中记录；对于这种情况，
oracle只在alert log中提示将不会再记录incident信息，并每十分钟提示一次，直至1个小时或1天到期恢复正常。




2.3 错误诊断的组成结构
2.3.1 ADR(automatic diagnostic repository,自动诊断信息库)
    这是一个存储数据库诊断数据的基于文件的信息库，ADR包括跟踪文件、预警日志、健康监控报告以及意外事件报告等；每个数据库都有自己的ADR主目录，但目录结构可以跨实例和产品的，即oracle support 能关联和分析来自多个产品和实例的诊断数据
    ADR基目录的设定如下：1）由初始化参数diagnostic_dest指定；2）如果未指定diagnostic_dest，则默认使用$ORACLE_BASE为ADR的基目录；如果ORACLE_BASE也未指定，则ADR基目录默认为$ORACLE_HOME/log
    一个ADR基目录可以包含多个ADR主目录，每个主目录对应一个不同的数据库实例或oracle产品；一个实例的ADR主目录的通用结构为：ADR基目录/diag/product_type/product_id/instance_id
可以使用v$diag_info查看ADR的一些信息，主要包含以下信息：
ADR Base->ADR的基目录的目录路径
ADR Home->实例的ADR主目录
Diag Trace->包含基于文本的预警日志
Diag Alert->包含基于XML格式的预警日志
Diag Incident->存储你所创建的意外事件包的目录
others--其它的目录，存储incident package、health 监控报告等信息
2.3.2 Alert Log
告警日志存储在ADR中，其中主要包含以下信息：
■ Critical errors (incidents)
■ 诸如启停数据库、恢复数据库、创建或删除表空间等的管理操作
■ 自动refresh物化视图过程中出现的错误
■ 其它数据库事件
建议使用XML格式的告警日志进行各种分析，因为text格式的文件结构化较弱，不利于查看


2.3.3 Trace Files, Dumps, and Core Files
Trace Files
每个服务器进程和后台进程都会对应有trace文件；trace文件由对应的进程定期更新，主要包含进程环境、状态、活动情况以及错误等信息。此外，
SQL trace功能也会创建对应的trace文件。
trace文件名一般由实例名、进程名以及操作系统进程号组成，文件类型为trc；有时会附加类型为trm的trace map文件，其包含有关trace文件的结构
信息，可用于搜索和导航。
To find the trace file for your current session: SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Default Trace File';
To find all trace files for the current instance: SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';
To determine the trace file for each Oracle Database process: SELECT PID, PROGRAM, TRACEFILE FROM V$PROCESS;
Dumps 
dump是一种特殊的trace文件类型；当一个incident发生时，oracle会在incident目录下写一个或多个dump，其文件名中包含对应的incident号
Core Files 
core文件包含内存转储，其只对Oracle Support工程师有用


2.3.4 Other ADR Contents
诸如HM报告、SQL Repair记录、SQL test case、incident package等
1>HM报告
 HM的运行方式与模式
HM检查检测文件损坏、物理和逻辑块损坏、undo和redo损坏以及数据文件损坏等，HM检查能以下两种方式运行：
（1）Reactive---错误诊断架构可以在关键性错误（critical error）发生时自动运行HM检查
（2）Manual---DBA可以在EM中或使用DBMS_HM包手动执行HM检查
HM检查之后，将相关的结果、建议和其它信息存储在ADR中；HM的运行模式分为两种：1>DB-online，即在数据库mount或open时运行；2>DB-offline，即在数据库nomount时运行。所有的HM检查可以在DB-online模式下进行，只有Redo Integrity Check和DB Structure Integrity Check可以在DB-offline下进行


 HM检查支持的类型
（1）DB Structure Integrity Check—--判定数据库文件的完整性，当文件丢失、损坏或不一致时会给出失败报告；如果在DB-online下进行，则会检查在
控制文件中列出的所有日志文件数据文件；如果在DB-offline下进行，则只会检查控制文件。
（2）Data Block Integrity Check—--侦测块内诸如checksum failures、head/tail mismatch和logical inconsistencies的磁盘块损坏；注意此检查不检测
inter-block或inter-segment损坏。大多数的块损坏都可以使用Block Media Recovery修复，损坏块的信息也可以被V$DATABASE_BLOCK_CORRUPTION视图捕获
（3）Redo Integrity Check—--扫描redo log和archive log的内容，以侦测其可用性和损坏情况
（4）Undo Segment Integrity Check—--查找逻辑上的undo损坏。当定位损坏以后，该检查会使用PMON和SMON进程视图恢复损坏的事务；如果恢复失败，则HM
在V$CORRUPT_XID_LIST视图中存储相关信息
（5）Transaction Integrity Check—--和Undo Segment Integrity Check基本一致，不同的是它仅检查特定的事务
（6）Dictionary Integrity Check—--检查核心字典对象，例如tab$和col$；判定字典记录的内容；执行逐行检查，核实在字典行上执行的逻辑约束；执行对象的关联检查，判定对象之间的父子关系；该检查在以下数据字典对象上操作：tab$, clu$, fet$, uet$, seg$, undo$, ts$, file$, obj$, ind$, icol$, col$,user$, con$, cdef$, ccol$, bootstrap$, objauth$, ugroup$, tsq$, syn$,view$, typed_view$, superobj$, seq$, lob$, coltype$, subcoltype$,ntab$, refcon$, opqtype$, dependency$, access$, viewcon$, icoldep$,dual$, sysauth$, objpriv$, defrole$, and ecol$.


 手动使用HM
（1）使用DBMS_HM程序包
可以使用v$hm_check查看HM支持的检查类型及详情；使用v$hm_check_param查看检查使用程序包时各个参数详情。
（2）使用EM
依次访问Home->Related Links->Advisor Central->checkers->运行各种类型的HM检查


 查看HM报告
（1）使用EM查看，依次访问Home->Related Links->Advisor Central->checkers，选择对应的HM检查，查看结果和报告。
（2）使用get_run_report函数查看，例如SELECT DBMS_HM.GET_RUN_REPORT('HM_RUN_1061') FROM DUAL;
（3）使用ADRCI命令行查看：
show hm_run命令->查看所有已运行的报告，结果与V$hm_run中的一致
create report hm_run run_name命令->选取对应的HM检查，生成ADRCI报告
show hm_run report run_name命令->查看指定HM检查对应的报告


2>SQL Repair
当SQL语句遇到关键性错误时，可以调用SQL Repair Advisor修复；多数情况下，SQL Repair Advisor都会建议一个补丁（patch）；如果接受其建议，
执行建议的补丁，则意味着查询优化器会使用替换的执行计划。可以在EM的问题（critical error）详情页调用SQL Repair Advisor
有时需要确认、使无效以及删除已经执行的patch，可以在EM中依次访问Home->Server->Query Optimizer->SQL Plan Control->SQL Patch，然后完成
相关操作。
3>SQL test case
可以使用SQL test case builder快速创建一个测试案例提交给oracle support。
For many SQL-related problems, obtaining a reproducible test case makes it easier to resolve the problem. Starting with the 11g Release 2 (11.2), Oracle Database contains the SQL Test Case Builder