OS与Oracle

本文要分析的是下面这个SQL，执行了半个多钟头还没返回结果。
Wait events 是了解Oracle运行状态的一个重要途径。对于某个具体的SQL，SQL Monitor Report提供了drill down的方式得到这个具体SQL在运行中的wait events的分布情况，下面是SQL Monitor Report的相应图形。
这里最突出的等待事件是enq: TS – contention，这是关于临时segment的等待事件，这可能是一般的表空间的争用(例如并行直接路径加载数据)，也可能是临时表空间的争用(例如为了hash join或者sort)。那么这时临时表空间的增长状态是怎么样子的呢？SQL Monitor Report提供了这方面的信息……

随着业务的发展，IT部门的服务器数量会越来越庞大，另一方面，这些服务器的利用率却得不到充分利用，于是，服务器的资源整合就被提上了议事日程，这方面的相应的解决方案一般有
Hardware Partitions,
O/S Workload Managers,
Virtualization
等等。
在11gR2中，Oracle也提供了一种简单有效的方法实现对服务器资源的整合，这就是Instance Caging技术……

有一次跟一个QQ上的朋友一起探讨了另一个对系统CPU进行度量的指标: CPU used by this session。
他刚好有一份AWR报告，在这份报告里，出现了严重的CPU used by this session和DB CPU不一致的现象……

构建DSS系统的第一步离不开数据加载，通过文本文件加载是最常见的方式，Oracle提供了外部表加载的方法，即把一个文本文件当成一个正常的表来进行操作，通过类似insert /*+ append */ into table select from external_table的方式进行加载。
数据加载是一个CPU-Bound的过程，不过是通过什么工具，external table也好，sqlldr也好，imp也好，impdp也好。
这个过程的AWR报告会是怎么样子的呢……

如何得到系统大致的MBPS呢？
MBPS= (Physical reads + Physical writes) * Block_Size = (196,271.4+2.0)*8*1024/1024/1024 = 1533 MB/s
更准确的MBPS可以从Instance Activity Stats部分获得……

写了Linux上的监控与分析工具之后，写写Oracle上相应的监控与分析工具还是挺有意思的，一方面可以更加完整，一方面可以进行横向对比。

Linux上的性能数据一般都来自于/proc文件系统，而Oracle则是来自于V$视图。因此，所有的Oracle监控工具的实现都万变不离V$ 视图。而这些个视图里面，最重要的应推v$sysstat。里面记录着Instance一级的各个统计数据的当前值，例如CPU利用情况，逻辑读，Redo Size等等。10g后有了另一个重要的视图，叫v$active_session_history,通过它可以容易地得知当前Instance的活动状态，主要是各个时刻系统都在等待哪些事件，通过对这些等待事件和相应等待次数的处理，就可以清晰地了解系统的历史工作负载特征和压力。如果想获取当前正在执行的SQL，则可查询v$sql视图。如果想获取当前SQL的执行计划，则可调用dbms_xplan.display_cursor。从这方面讲，一个DBA都具备着写一个Oracle的监控工具的能力。它应该比写一个Linux的监控工具来得容易简单得多……

如何去表征一个系统的繁忙程度呢？除了利用CPU进行计算外，数据库还会利用其它计算资源，如网络，硬盘，内存等等，这些对资源的利用同样可以利用时间进行度量。假设系统有M个session在运行，同一时刻，有的session可能在利用CPU，有的session可能在访问硬盘，那么，在一秒钟内，所有session的时间加起来就可以表征系统在这一秒内的繁忙程度，一般的，这个和的最大值应该为M。这其实就是Oracle提供的另一个重要指标：DB time，它用以衡量前端进程所消耗的总时间。

对除CPU以后的计算资源的访问，Oracle用等待事件进行描述。同样地，和CPU可分为前台消耗CPU和后台消耗CPU一样，等待事件也可以分为前台等待事件和后台等待事件。

DB Time一般的应该等于DB CPU + 前台等待事件所消耗时间的总和。等待时间通过v$system_event视图进行统计，CPU Time和DB CPU则是通过同一个视图，即v$sys_time_model进行统计……

如果关注数据库的性能，那么当拿到一份AWR报告的时候，最想知道的第一件事情可能就是系统资源的利用情况了，而首当其冲的，就是CPU。

而细分起来，CPU可能指的是

OS级的User%, Sys%, Idle%
DB所占OS CPU资源的Busy%
DB CPU又可以分为前台所消耗的CPU和后台所消耗的CPU
如果数据库的版本是11g，那么很幸运的，这些信息在AWR报告中一目了然…

Automatic Workload Repository是10g引入的一个重要组件。在里面存贮着近期一段时间内，默认是7天，数据库活动状态的详细信息。
通过AWR和AWR报告，DBA可以容易地获知最近数据库的活动状态，数据库的各种性能指标的变化趋势曲线，最近数据库可能存在的异常，分析数据库可能存在的性能瓶颈从而对数据库进行优化。

AWR报告所有的数据来源于AWR视图，即以DBA_HIST_开头的所有系统表，Database Reference有对所有这些系统表的描述，这应该是Oracle官方对AWR报告的官方注释了。

而对于如何有效地去分析AWR报告….

这是11g引入的一套新的自动化机制。Oracle的官方文档大而全，不过想理清楚里面的来龙去脉可不是一件容易的事情。

不过下面几点知识要点是应该记住的。
1. Oracle有三个已定义好的automated maintenance tasks.
2. 这些automated maintenace tasks在maintenance windows里得到执行。
3. 利用dbms_auto_task_admin进行配置。
4. 如何避免resource plan在进入maintenance windows时的切换……