明天从以下角度聊一下 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
好了，明天就说这些吧。
心愿对大家有所帮忙，如果有须要进行更深理解的同学，能够加我的 Wechat（chxh19791208）。