在监控、诊断、处理数据库性能问题的时候，时间信息往往是非常重要的判断依据。有时候可能我们会使用一些比例来判断性能，但是使用比例而不使用时间往往会将我们带向错误的方向。在oracle9i的第一版中关于时间的信息被进行了增强，提供了更多更有益的时间信息。除了9i的外貌发生了变化，在一些并没有被我们注意或者不为人知得一些v$视图的相关字段也发生了变化。这里提到的主要是他们发生了那些改变以及对dba有什么帮助。这里也列出了零星的一些oracle内部的未公开的信息。
| 全面介绍：oracle数据库日期处理 |
在监控、诊断、处理数据库性能问题的时候，时间信息往往是非常重要的判断依据。有时候可能我们会使用一些比例来判断性能，但是使用比例而不使用时间往往会将我们带向错误的方向。在oracle9i的第一版中关于时间的信息被进行了增强，提供了更多更有益的时间信息。除了9i的外貌发生了变化，在一些并没有被我们注意或者不为人知得一些v$视图的相关字段也发生了变化。这里提到的主要是他们发生了那些改变以及对dba有什么帮助。这里也列出了零星的一些oracle内部的未公开的信息。
second 1 秒
centi-second 1/100 百分之一秒 厘秒
milli second 1/1000 千分之一秒 毫秒
micro second 1/1.000.000 微妙
nano second 1/1.000.000.000 纳秒
在以前的版本中，oracle的时间计量单位是厘秒，使用厘秒最显而易见的问题就是可能有些操作是小于厘秒的。看上去这似乎不太常见，但是实际上在操作系统上很多操作都是以微妙作为单位的，这意味着操作的起始和终止在不到厘秒就完成了，从厘秒级看就好像没有发生一样，因为持续时间近似为0。而有时候操作的持续时间不到厘秒，但是起始和终止发生在两个相连的厘秒，所以操作时间不到厘秒但是却被记录为厘秒，造成时间记录的不准确。
在oracle9i之前，最小的时间单位仍然是厘秒，这可以在跟踪文件、v$system_event和v$session_event中的超时字段看到。在9i之前，是不能在联机状态看到sql语句的执行(cpu消耗)时间和持续时间的，也不能看到一条sql语句在等待着什么，实际上只有一种方法可以得到这些信息，就是通过启用10046 trace level 12的跟踪事件。这样做也会带来下面的一些问题:
1. 生成进程跟踪文件带来很高的性能开销
2. 如果有太多用于帮助调优的sql语句执行，将会产生大量的磁盘/文件空间需求。
在oracle9i第一版中的持续时间以微妙作为时间单位，这能够显示出oracle真正花费的时间。超时仍然以微妙作为计时单位。一些视图被扩展以便记录微妙数据。所有的时间信息由初始化参数timed_statistics 决定。
一些视图的改变:
| v$sqlarea: |
两个字段被加入到v$sqlarea中，分别是cpu_time 和elapsed_time。两个字段都被设置为微妙级。然而，在这里可能会s看到一个有趣的现象:
| select cpu_time, elapsed_time from v$sqlarea order by 2 cpu_time elapsed_time ---------- ------------ 230000 174567 260000 258803 260000 271808 |
首先:三行中的第二行显示出了持续时间小于cpu执行时间，实际的情况是cpu字段记录单位是微妙级，但是数据被进位保留到了厘秒级。
sql语句的等待时间等于elapsed_time减去cpu_time，但是很难看到精确的等待时间。在v$system_event 视图中能够看到数据库实例级的等待时间(并不是每条sql语句的)，但是看不到发生在操作系统上(cpu等待、内存的等待)的等待时间s。
x$ksqst的改变 (对应视图v$enqueue_stat)
基础表x$ksqst主要显示关于系统中队列的信息。在9i之前只能提供队列类型的get和wait数。一个队列有两种特征和两个标识组成(id1 and id2)。例如一个叫做tx队列，表示一个事务队列。从oracle9i开始不但能够看到gets 和waits，而且等待的时间和得不到队列(中断或者超时)的失败次数都可以看到。
| x$ksqst |
ksqstwtim number 以微妙作为单位
然而这里仍不能将队列等待与sql语句关联，也不能够得到等待队列的sql语句到底等待了多久。下面的一个新的视图v$enqueue_stat 将提供关于队列得更多信息:
| v$enqueue_stat inst_id number eq_type varchar2 total_req# number total_wait# number succ_req# number failed_req# number cum_wait_time number |
v$sysstat的改变
实际这个视图并没有什么改变，关于时间的信息仍然在厘秒级。
v$sysstat
cpu used by this session 厘秒
parse time cpu 厘秒
parse time 厘秒
recursive cpu usage 厘秒
当从不同资源中比较数据时应该注意。
v$waitstat的改变
这个视图显示了发生在块级的buffer busy waits的细目描述，等待时间的单位在微妙级。
v$waitstat
time number 厘秒单位
这里无法通过视图中出现的等待找到对应的sql语句。
v$filestat的改变
在这个视图中现在分成了单次块读取和累计块读取，这种分法更合理。
v$filestat
maxiortm number 厘秒级的最大读取时间
maxiowtm number 厘秒级的最大写入时间
singleblkrds number 单次块读取块数
singleblkrdtim number 厘秒级的累计单次块读取时间
这个视图也不能找到相关的sql语句，使用dbms_system.kcfrms()过程可以重设最大读、写时间，设置更准确的取样间隔。
v$session_event的改变
这个视图现在已经可以捕捉到微妙级的等待事件的持续时间了。它可以以微妙或者厘秒方式显示等待时间，因为这些改变，等待事件变得更加精确(等待时间以微妙方式捕捉，然后转换为厘秒方式)
v$session_event
time_waited_micro number 以微妙级等待的时间
time_waited number 微妙级的等待时间 / 10000
max_wait number 厘秒级的最大等待时间
当然，这个视图也不能找到相关的sql语句。
一个被大多数dba所感兴趣的字段是max_wait 字段，这个字段显示了一个事件的最大等待时间。这个信息只要会话一登陆就生效，将显示一个会话整个生命期中的最大等待时间。使用dbms_system.kcfrms() 过程可以重置最大的值，以便让这个字段显示与测量周期更紧密的值。
v$system_event的改变
这个视图最主要的变化是增加了time_waited_micro字段，它以微妙为单位显示了持续的时间。.另外time_waited 也更加精确，,因为它来自于time_waited_micro的值。
| parsing in cursor #1 len=29 dep=0 uid=5 oct=3 lid=5 tim=1006862415399006 hv=4384 51932 ad='84b05c04' select count(*) from tab, tab end of stmt parse #1:c=10000,e=11334,p=0,cr=4,cu=0,mis=1,r=0,dep=0,og=4,tim=1006862415398976 binds #1: exec #1:c=0,e=587,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=1006862415399931 wait #1: nam='sql*net message to client' ela= 10 p1=1650815232 p2=1 p3=0 fetch #1:c=2500000,e=2526458,p=0,cr=149542,cu=0,mis=0,r=1,dep=0,og=4,tim=1006862 417926777 wait #1: nam='sql*net message from client' ela= 1004 p1=1650815232 p2=1 p3=0 fetch #1:c=0,e=6,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1006862417928426 wait #1: nam='sql*net message to client' ela= 7 p1=1650815232 p2=1 p3=0 wait #1: nam='sql*net message from client' ela= 3636276 p1=1650815232 p2=1 p3=0 |
注意:时间都是微妙级的，但是这里仍然有一些很有意思的地方:
1. tim= 明显是微妙级的，这个tim 域给出了一个时间快照
2. e= 和 ela= 也是微妙级的，这两个域表示持续的事件
3. 比较有趣的是c=. 看上去好像是微妙级的，但是实际上是厘秒级的数据乘上了10000， 域c 表示cpu的消耗
v$latch, / v$latch_parent / v$latch_children 的改变:
在oracle9i主要的改变是增加了wait_time字段。因此现在锁存器竞争更容易检测了，而在oracle9i以前，只能通过察看sleeps次数来判断。在v$latch中主要相关的字段包括:
v$latch
name varchar(64) 锁存器名称.
sleeps number 锁存器由于忙而产生的sleep次数
sleep1..11 number 显示了sleep的分布情况
wait_time number 微妙级的等待时间
在orace9i以前与v$latch的 ‘latch free’等待事件的sleeps字段对应的是v$system_event的total_waits字段:
|
select event, total_waits, time_waited select name, trunc(sleeps*100/ total, 2) "perc of sleeps" |
有很多sleeps的锁存器会显示为v$system_event的大量等待时间。在oracle9i由于在v$latch中有了wait_time字段，所以提供了更准确的信息:
| select name, trunc(wait_time*100/time_waited, 2) "perc. of time waited" from v$latch, (select time_waited from v$system_event where event = 'latch free') where wait_time != 0 order by 2 |
还有那些没有改变?
其他与时间相关的信息都没有改变。在v$sysstat中象 ‘cpu used by this session’, ‘parse cpu time’ and ‘recursive cpu usage’等事件仍然表示为厘秒。
oracle没有改变这些统计信息的单位是因为这些信息可能会影响着一些依赖于他们的应用或者脚本。
oracle的precise/indepth
在oracle9i中由于使用了微妙做为单位，所以持续时间已经变得更加准确，但是仍然不能看到在一个特定的时间范围内的每个sql语句的资源消耗。了解每个sql语句的资源消耗能够帮助你确定那个sql语句是你首先应该调优的。 使用oracle的precise/indepth，通过不断的监视oracle的环境，收集用于性能分析的数据，就能够看到每条sql语句的资源消耗情况。这些资源消耗情况最终被细分为:
| using cpu cpu wait i/o wait memory wait other host wait table lock wait row lock wait shared pool wait buffer wait rollback segment wait redo log buffer wait log switch and clear wait internal lock wait background process wait parallel query sync. wait parallel query server wait other wait |
闽公网安备 35060202000074号