数据库漫谈（七）
编者按：
本文作者系Scott（中文名陈晓辉），现任大连华信资深分析师 ，ORACLE数据库专家，曾就职于甲骨文中国。个人主页：segmentfault.com/u/db_perf ，经其本人授权发布。
【免责声明】本公众号文章仅代表个人观点，与任何公司无关。
今天从以下角度聊一下ORACLE数据库的发展。
1. OWI的设计
2. Diagnostics
对ORACLE数据库有所了解的人一看上面的Agenda就知道我们今天聊得是面向数据库管理员（DBA）或数据库技术支持工程师的内容，而不是面向普通数据库用户的东西。的确是这样，今天的话题是普通数据库用户平时接触不到的，但多学一些东西总是有好处的，所以希望普通的数据库使用者也可以看看这篇文章。
先说OWI（Oracle Wait Interface）的设计。
好多写过代码的人都遇到过这样的麻烦，就是在开发之前，无论是我们自己在脑子里或写成文档的设计书，还是从客户那里了解的需求，描述的都是正常的处理流程或想的到的异常处理。但是等程序运行之后，就会出现各种各样的问题：I/O慢，CPU高，内存使用多等等。
但是由于程序已经Release,通常我们没有在线调试（Debug）和分析（Diagnostics）的条件，只能通过种种猜测来进行试错。活跃会话数过多？系统可能会有锁等待？硬解析过多？命中率太低？
这时你就会想到，如果在编写程序时，除了实现客户的应用之外，是不是也应该把系统的运行状况（待机，CPU，内存的使用情况之类）进行监测或测量，并且可以通过一些特定的方式Get到呢？
确实是这样的，并且这也应该是衡量一个程序或数据库成熟度的重要指标。
ORACLE数据库从Ver7.0.1开始引入了OWI（Oracle Wait Interface）。
对了，就是1992年ORACLE经历了差点儿破产又涅磐重生后发布的第七版。
那么OWI做了哪些设计呢？
首先，OWI是面对问题（Problem-oriented）的。意即OWI在设计初始就是为了解决问题而设计的。
OWI引入了待机事件（Wait Event）的概念，用来标识数据库正在进行的处理或等待的资源。
例如：db file sequential read 待机事件，就表示PROCESS在等待读取一个数据块完成。
每个待机事件还有P1,P2,P3三个参数，用来表示当前的待机资源。
例如：在上面的db file sequential read 待机事件中，三个参数分别为：P1=file#，P2=block#，P3=request block count。
根据这三个参数信息，我们就能知道一个Process在读取哪个数据文件的哪个数据块上进行了等待。
然后，OWI是可以进行定量统计的。意即每一个待机事件都可以进行待机回数和时间的统计。
例如：在上面的I/O待机“db file sequential read”事件中，每次待机结束都会输出待机时间"ela"。
WAIT #140267060339016: nam='db file sequential read' ela= 12 file#=12 block#=154 blocks=1 obj#=73082 tim=10922529252
通过上面的Trace输出，我们可以知道在读取file#=12 block#=154的I/O处理花费了12us。
再次，OWI是持续发展的。意即OWI只是一种设计思想，具体的实现方法是不断发展和变化的。
最初的Ver7.0.1中共设计了104个待机事件，Ver8.0增加到140个，9i增加到400个，10g达到了800个以上，以后更是随着版本一路飙升。
这其中有的是新增加处理和新功能所对应的待机事件，例如12c开始，LGWR PROCESS 不再是一个进程单打独斗，而是可以Fork出多个SLAVE PROCESS，来帮助多个前台进程同时写Redo Log。
伴随着这个变化，也增加了“LGWR intra group sync“和“LGWR worker group ordering“两个待机事件。
还有的是对既存的待机事件的细分，在10g和11.1.0.6之前，“shared server”的待机事件“virtual circuit status”在11.1.0.7 之后就被分割成了以下两个待机时间。
"shared server idle wait" - 用来表示“shared server”正在等待做一件事，是个“idle”待机，一般不需要关注。
"virtual circuit wait" - 用来表示“shared server”正在被一个其他处理阻塞，是个非“idle”，有实际意义的待机，如果因为这个待机造成了实际的障害，就需要进行详细的调查。
那么，OWI这个设计思想是如何发挥实际作用的呢？
答案是使用以下几个OWI工具。
动态视图
SQL Trace
Oradebug和Dump
AWR
动态视图
OWI定义了以下几个关于待机事件的动态视图。
V$EVENT_NAME 定义了所有的待机事件，可以分成以下类别。
SQL> select distinct WAIT_CLASS#,WAIT_CLASS from v$event_name order by WAIT_CLASS#;
WAIT_CLASS# WAIT_CLASS
----------- -------------------
0 Other
1 Application
2 Configuration
3 Administrative
4 Concurrency
5 Commit
6 Idle
7 Network
8 User I/O
9 System I/O
10 Scheduler
11 Cluster
12 Queueing
13行が選択されました。
V$SYSTEM_EVENT SYSTEM单位的统计信息。
V$SESSION_EVENT SESSION单位的统计信息。
V$SYSSTAT 以类别区分的SYSTEM单位的统计信息。
V$SESSTAT 以类别区分的SESSION单位的统计信息。
v$SESSION_WAIT SESSION单位的详细统计信息。
除了上面的待机事件为主的动态View之外，还有以下的发生待机的Object为主的动态视图。
V$SESSION ：SESSION信息
V$ACTIVE_SESSION_HISTORY ：活动SESSION历史信息
V$PROCESS ：PROCESS信息
V$TRANSACTION ：TRANSACTION信息
V$LATCH**** ：LATCH关联信息
V$LOCK**** ：LOCK关联信息
V$SQL**** ：SQL关联信息
V$LIBRARYCACHE，X$KGLLK，X$KGLPN ：LIBRARYCACHE Pool 关联信息
V$ROWCACHE，V$ROWCACHE_PARENT ：ROWCACHE 关联信息
V$SGA**** ：SGA关联信息
V$SEGMENT_STATISTICS ：SEGMENT关联信息
V$SESS_TIME_MOEL，V$SYS_TIME_MOEL ：Time Model统计信息
V$BH，X$BH ：Buffer Cache统计信息
SQL Trace
SQL Trace可以通过设置10046 Event来激活，有以下几个Level。
EVENT: 10046 "enable SQL statement tracing (including binds/waits)" (ドキュメントID 21154.1)
10046 EVENT levels: (the new sql_trace values are included in [..])
These are bit values so can be ORed together to get different mixes
1 - Enable standard SQL_TRACE functionality (Default)
4 - As Level 1 PLUS trace bind values [ bind=true ]
8 - As Level 1 PLUS trace waits [ wait=true ]
This is especially useful for spotting latch wait etc.
but can also be used to spot full table scans and index scans.
As of 11g these additional bit levels are available:
16 - Generate STAT line dumps for each execution [ plan_stat=all_executions ]
32 - Never dump execution statistics [ plan_stat=never ]
As of 11.2.0.2 this additional bit level is available:
64 - Adaptive dump of STAT lines. [ plan_stat=adaptive ]
This dumps the STAT information if a SQL took more than about 1 minute thereby
giving information for the more expensive SQLs and for different executions of such
SQLs.
eg: A common event level is 12 which includes standard SQL_TRACE output, binds, waits and
default STAT line tracing.
Oradebug和Dump
关于Oradebug和Dump，并没有和OWI有直接联系，只是分析和理解待机事件的工具，我会放在 Diagnostics的部分详细说明。
AWR
AWR（Automatic Workload Repository）从10g版本开始导入，提供了非常重要的Performance历史数据。
其实在AWR导入之前，从Ver8.1.6开始，就有一个和AWR功能类似的STATSPACK就存在了。
STATSPACK和AWR提供了相似的功能，但是两者之间存在以下区别。
1. STATSPACK是免费的，AWR是收费的。
所以STATSPACK的功能是有限的，也不支持登录Bug。
2. STATSPACK使用PL/SQL做成，和普通用户执行的SQL文一样，需要进行Parse，Execute，Fetch等阶段。
AWR是使用C语言做成，采用DMA（Direct Memory Access）方式直接访问内存，不经过SQL的Parse，Execute，Fetch等阶段。
3. STATSPACK的安装，Snapshot的取得，Level的指定以及保存期间的设定之类的maintenance都需要手动设定。
AWR的maintenance都是自动设定的，基本不需要手动干预。
另外，在AWR中还包含一个重要的功能，ASH（Active Session History）。
这个功能提供两种采样间隔（1秒和10秒）的活动会话历史信息，堪称最有价值的诊断信息，基本在10g之后的每一个版本都被大大的增强。
但是，遗憾的是，ASH和AWR一样，都是收费功能。
如果客户想用SQL定时采样来模拟ASH也是可以实现的，但是花费的CPU和Memory等资源要高得多，有些得不偿失了。
关于OWI，还有很多很多内容，在我们这个“漫谈”系列里进行详细说明有些不太合适，这次就写这麽多当作抛砖引玉吧，以后再找机会详述。
下面我们来简单聊一下ORACLE数据库的Diagnostics方法。
ORACLE数据库的Diagnostics方法有以下几种：
Alert.log
Trace file
Dump file
Event & Oradebug关于前两种，大家基本都很熟悉了，这里就不多说了。
关于Dump file，可以参照Oracle Dump File 大全。
关于Event & Oradebug，涉及很多未公开信息，我们在这里也不便多说，就介绍几种实用技巧吧。
1. 11g以上版本的Event设定方法。
例：
关于Oradebug，大家只需要记住以下几点就可以了。
- ORADEBUG可以通过SQL/PLUS实行，可以对其他的Process指定Event等操作。
- ORADEBUG必须通过“AS SYSDBA”进行接续。
- ORADEBUG命令可以通过"ORADEBUG HELP"查询
例：
SQL> oradebug help
HELP [command] Describe one or all commands
SETMYPID Debug current process
SETOSPID <ospid> Set OS pid of process to debug
SETORAPID <orapid> ['force'] Set Oracle pid of process to debug
SETORAPNAME <orapname> Set Oracle process name to debug
SHORT_STACK Get abridged OS stack
CURRENT_SQL Get current SQL
DUMP <dump_name> <lvl> [addr] Invoke named dump
PDUMP [interval=<interval>] Invoke named dump periodically
[ndumps=<count>] <dump_name> <lvl> [addr]
DUMPSGA [bytes] Dump fixed SGA
DUMPLIST Print a list of available dumps
EVENT <text> Set trace event in process
SESSION_EVENT <text> Set trace event in session
DUMPVAR <p|s|uga> <name> [level] Print/dump a fixed PGA/SGA/UGA variable
DUMPTYPE <address> <type> <count> Print/dump an address with type info
SETVAR <p|s|uga> <name> <value> Modify a fixed PGA/SGA/UGA variable
PEEK <addr> <len> [level] Print/Dump memory
POKE <addr> <len> <value> Modify memory
WAKEUP <orapid> Wake up Oracle process
SUSPEND Suspend execution
RESUME Resume execution
FLUSH Flush pending writes to trace file
CLOSE_TRACE Close trace file
TRACEFILE_NAME Get name of trace file
SETTRACEFILEID <identifier name> Set tracefile identifier
LKDEBUG Invoke global enqueue service debugger
NSDBX Invoke CGS name-service debugger
-G <Inst-List | def | all | cluster > Nodes involved
-R <Inst-List | def | all | cluster > Nodes involved (return output)
SETINST <instance# .. | all> Set instance list in double quotes
SGATOFILE <SGA dump dir> Dump SGA to file; dirname in double quotes
DMPCOWSGA <SGA dump dir> Dump & map SGA as COW; dirname in double quotes
MAPCOWSGA <SGA dump dir> Map SGA as COW; dirname in double quotes
HANGANALYZE [level] [syslevel] Analyze system hang
FFBEGIN Flash Freeze the Instance
FFDEREGISTER FF deregister instance from cluster
FFTERMINST Call exit and terminate instance
FFRESUMEINST Resume the flash frozen instance
FFSTATUS Flash freeze status of instance
SKDSTTPCS <ifname> <ofname> Helps translate PCs to names
WATCH <addr> <len> <self|exist|all|target> [hw [write|rw|exec]]
Watch a region of memory
DELETE <local|global|target> watchpoint <id> Delete a watchpoint
SHOW <local|global|target> watchpoints Show watchpoints
DIRECT_ACCESS <set/enable/disable command | select query> Fixed table access
IPC Dump ipc information
IPC_TRACE <module> <trace_flags> <trace_level>
Modify IPC trace flags
IPC_CHECKSUM <light/medium/full>
Enable/Disable IPC Checksumming
UNLIMIT Unlimit the size of the trace file
CALL [-t count] <func> [arg1]...[argn] Invoke function with arguments
TRANSLATE_ADDR <address> ... Translate addresses to symbol names
CORE Dump core without crashing process
PROCSTAT Dump process statistics
——End——