1.解读DSI——DSI301

1.解读DSI——DSI301

1     DSI3*的全部课程

DSI培训至少需要在RDBMS上工作了12个月以上。

DSI301：高级服务技术技能

DSI302：数据管理（主要回滚操作）

DSI303：数据库备份和恢复（REDO机制）

DSI304：查询管理（如何解释和修改执行计划）

DSI305：数据库调优

DSI306：大型数据库

DSI307：分布式和复制架构

DSI308：讨论oracle 7和oracle 8i的并行服务

2     DSI301

l  如何提供过事件来诊断ORACLE问题，

l  描述hang,loop,crash诊断进程。

l  理解，定位，诊断堆错误。

是DSI302~308的基础。

l  DUMP数据块

l  处理块崩溃

l  处理回滚段崩溃

l  如何使用DUL（Data Unloader Utility）

3     源码阅读

DSI301的第一部分是源码阅读。

之前ORACLE员工是可以得到源码进行阅读学习的，要求工作6月以上然后获得主管同意即可。现在貌似不行了。真是可惜了。

代码里面你可以得到你想要的任何东西。

这里就列下常用的文件转换

kt 表示kerneltransaction

kd kernel data

       kckernel cache

       kskernel services

       ktukernel transaction undo

       ksekernel service error

错误信息：

Oracle 错误：ORA-nnn

Oracle 内部错误：ORA-600

       ORA-600： internal error code

       例如：2845,193,20,5255等

4     使用事件

诊断dump和事件可以分为四类

l  Immediate dump

l  On-error dump

l  Change behavior

l  Trace

可以通过如下使用事件：

l  事件初始化参数

l  ALTER SESSION SET EVENTS或ALTER SYSTEM SET EVENTS

l  Sys.dbms_system.set_ev()

l  Oradebug工具

其中altersession set events ‘<event name> <action>’

事件是复杂问题的辅助，对于那些问题必须创建trace文件。

Trace真是的个大话题，这里展开会扰乱总体布局，就含泪飘过了。

4.1     Immediate dumps

是最常用的immediatedump事件

Alter session set events ‘immediate tracename <dump> level <level>’

Immediate dump 不能被参数文件激活。可以使用ORADEBUG或dbms_system.set_ev()

4.2     On-Error dumps

类似immediatedump，只不过只有在错误发生的时候才进行DUMP。

最常用的是ERRORSTACK，错误堆栈。可以DUMP发生错误时候的调用堆栈。

使用例如

Event=”<error> trace name errorstacklevel <level>”

Error可以使任何的ORA错误。

使用ORADEBUG如下

Oradebug event <error> trace nameerrorstack level <level>

DUMP ORA-60的话，设置如下：

Event=”60 trace name errorstack level 1”

4.3     Change Behavior

可以改变ORACLE动作，使能隐藏特性，指定优化。

4.4     Trace events

Trace events产生一个诊断的trace

Trace events收集附加的信息便于理解和解决

不同的event code表示不同的事情

例如10015表示undo segment recovery

10046等于设置sql_trace=true

总结如下图1：

4.5     Oracle Event事件工作原理

进程启动的时候有初始化的event参数，可以被alter session或alter ssytem命令进行修改。

有两组事件，会话事件和进程事件。

进程事件在进程启动时候通过初始化参数设定，会话事件可以动态进行设置。

先查询会话事件再查询进程事件。

如下图2

5     诊断

如果ORACLE实例异常终端，ORACLE会产生大量诊断信息。大多数情况下，TRACE文件足够定位问题了。当用户进程异常死掉后，RDBMS会产生一个TRACE文件，如：

ora_<process_id>.trc

也可以使用工具在进程正常的时候来产生trace文件。

当存在可用的trace文件（包含调用堆栈）的时候，core files不能提供更多的信息了。

当trace文件丢失后，可以通过core files来产生调用堆栈。

5.1     Alter.log

每个实例产生一个alert.log文件。

       包含：后台进程和前台进程的诊断数据；错误和指向trace文件的详细信息，数据库启动开始的信息。

       路径在background_dump_dest 指定的位置。

5.2     TRACE FILE

每个服务进程碰到异常后，会写诊断数据到TRACE文件

TRACE文件的头包含以下信息：

操作系统版本，数据块版本是安装选项，实例名字，进程ID。

在TRACE文件中，最重要的是堆栈的TRACE，堆栈TRACE是调用的顺序，结合代码可就可以理解问题。

5.3     应用日志文件

应用日志文件会记录异常，例如SQLPLUS会话的SPOOL文件，EXPORT/IMPORT的日志文件。

CORE FIEL是进程的内存DUMP，使用DEBUGGER工具例如ADB可以从中抽取堆栈TRACE。

5.4     系统日志文件

从OS层面捕获系统日志文件。如果发生硬件或OS问题会很有用。

以上四点虽然具体针对的是ORACLE数据库问题定位，但是展开来也是有“普世”意义的，先看ORACLE本身的ALERT，然后查看TRACE，不过都没问题那看是不是应用引起的，如果不是应用那是不是操作系统呢？这样一层一层，抓住问题的本质，就是方法论哦。

其他的大型应用也可以从这个角度出发。

6     关于hang

进程在等一个永远不会发生的事情，就会HANG住。

要发现这个事件，可以使用：

l  多个状态DUMP

l  v$session_wait,v$lock,v$latch,v$latchholder

可以发现HANG住的原因。

HANG住时候不会消耗CPU资源。

查看有用的列：

Sid,seq#,event,wait,seconds,state

7     Loop

进程循环不停止。

要发现这个事件，可以使用：

l  多个状态DUMP

l  v$session_wait,v$lock,v$latch,v$latchholder

如果一个进程没有HUNG也没有LOOP，那么就需要调优了。

分析BSTTAT/ESTAT和TKPROF输出时一个很好地起点。

8     状态对象

状态对象是SGA中的结构，例如：后台和前台进程，会话，LATCH和ENQUEUES等。

PMON会清除失败的资源。

9     数据字典对象

数据字典视图对诊断hang或loop很有用

V$session_wait,v$session_event,v$latch,v$latchholder,v$latchname,v$sysstat,v$lock

$process,v$session,v$transaction,x$kcbfwait(bufferwaits),x$ksqst(enqueues)

查看v$session_wait例子如下：

Select sid,seq#,eventwait_time,seconds_in_wait,state from v$session_wait;