费雷德-冷镦钢
v1.0
可编辑可修改
AWR
报告详细分析
AWR
是
Oracle
10g
版本
推出的新特性，
全称叫
Automatic
Workload
Repository-
< br>自动负载信息库
, AWR
是通过对比两次快，照
(snapshot)
收集到的统计信息，来生成报表
数据，生成的报表包括多个部分。
WORKLOAD REPOSITORY report for
ICCI
DB Id
Instance
96
ICCI1
Inst
num
Release
1
10.2.0.
RAC
YES
Host
HPGICCI1
Begin Snap:
End Snap:
Elapsed:
DB
Time:
Snap
Id
2678
2680
Snap
Time
25-Dec-08
14:04:50
25-Dec-08
15:23:37
(mins)
(mins)
Sessions
24
26
Cursors/Session
DB
Time
不包括
Oracle
后台进程消耗的时间。如果
DB
Time
远远小于
Elapsed
时间，说明数据库比较空闲。
db time= cpu time + wait
time
（不包含空闲等待）
（非后台进程）
说白了就是
db time
就是记录的
服务器花在数据库运算
(
非后台进程
)
和等待
(
非空闲等待
< br>)
上的时间
DB time
= cpu time + all of nonidle wait event
time
在
79
分钟里（其间收集了
3
次快照数据），数据库耗时
11
分钟，
RDA
数据
中
显示系统有
8
个逻辑
CPU
（
4
个物理
CPU
），平均每个
CPU
耗时分钟，
CPU
利用率
只有大约<
/p>
2%
（
79
）。
说明系统压力非常小。
列出下面这两个来做解释：
Report A:
1
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- --------
---------
Begin Snap: 4610 24-Jul-08
22:00:54 68
End Snap: 4612 24-Jul-08
23:00:25 17
Elapsed: (mins)
DB Time: (mins)
Report B:
Snap Id Snap Time
Sessions Curs/Sess
---------
------------------- -------- ---------
Begin Snap: 3098 13-Nov-07 21:00:37 39
End Snap: 3102 13-Nov-07 22:00:15 40
Elapsed: (mins)
DB Time:
(mins)
服务器是
AIX
的系统
，
4
个双核
cpu,
< br>共
8
个核
:
/sbin> bindprocessor -q
The available processors are: 0 1 2 3 4
5 6 7
先说
Report
A,
在
snapshot
< br>间隔中，
总共约
60
分钟，
cpu
就共有
60*8=480
分钟，
DB
time
为分钟，则：
cpu
花费了分钟在处理
Oralce
非空闲等待和运算上
(
比方逻辑读
< br>)
也就是说
cpu
有
480*100%
花费在处理
Oracle
的操作上，这还不包括后台进程
看
Report B
，总共约
60
分钟，
cpu
有<
/p>
480*100%
花费在处理
Ora
cle
的操作上
很显然，
2
中服务器的平均负载很低。
从
awr
report
的
Elapsed
time
和
DB Time
就能大概了
解
db
的负载。
可是对于批量系统，
数据库的工作负载总是集中在一段时间内。
如果快照周期
不在这一段时间内，
或者快照周期跨度太长而包含了大量的数据库空闲时间，
所
得出的分析结果是没有意义的。
这也说明选
择分析时间段很关键，
要选择能够代
表性能问题的时间段。
2
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
Report
Summary
Cache
Sizes
Buffer
Cache:
Shared Pool
Size:
Begin
3,344M
704M
End
8K
14,352K
3,344M
Std Block
Size:
704M
Log Buffer:
显示
SGA
中每个区域的大小
（在
AMM
改变它们之后）
，
可用
来与初始参数值比
较。
shared
pool
主要包括
library
cache
和
dictionary
cache
。
library cache
用来存储最近解析
（或编译）
后
S
QL
、
PL/SQL
和
Java
classes
等。
library
cache
用来存储最近引用的数据字典。发生在
library
cache
或
dictionary
cache
的
cache
miss
代价要比发生在
buffer
cache
的代价高得多。因此
shared pool
的
设置要确保最近使用的数据都能被
cach
e
。
Load Profile
Redo size:
Logical reads:
Block changes:
Physical reads:
Physical writes:
User calls:
Parses:
Hard
parses:
Sorts:
Per Second
918,
3,
1,
Per
Transaction
775,
2,
1,
3
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
Logons:
Executes:
Transactions:
%
Blocks changed per Read:
Rollback per transaction %:
Recursive Call
%:
Rows per
Sort:
########
显示数据库负载概况，
将之与基线数据比较才具有更多的意义，
如果每秒或每
事务的负载变化不大，
说明应用运行比较
稳定。
单个的报告数据只说明应用的负
载情况，绝大多数据并没
有一个所谓“正确”的值，然而
Logons
大于每秒
1~2
个、
Hard
parses
大于每秒
100
、
全部
parses
超过每秒
< br>300
表明可能有争用问题
。
Redo size
：
每秒产生的日志
大小
(
单位字节
)
，可标志数据变更频率
,
数据库任务的繁重与否。
Logical
reads
：
每秒
/
每事务逻辑读的块数
.
平决每秒产生的逻辑读的
block
数。
Logical
Reads= Consistent Gets + DB Block Gets
Block changes
：每秒
/
每事务修改的块数
Physical
reads
：每秒
/
每事务物理读的块
数
Physical writes
：每秒
/
每事务物理写的块数
User calls
：每秒
/
每事务用户
call
次数
Parses
：
SQL
解析的次数
.
每秒解析次数，包括
fast parse
，
soft
parse
和
hard
parse
三种数量的综合。
软解析每秒超过
300
次意味着你的
应用程序
效
率不高，调整
session_cursor_cache
。
在这里，
fast parse
指的是直接在
PGA
中命中的情况
（设置了
session_cached_cursors=n
）
；
soft
parse
是指在
shared
pool
中命中的情形；
hard
parse
则是指都不命中的情况。
Hard parses
：其中硬解析的次数，硬解析太多，说
明
SQL
重用率不高。
每秒
产生的硬解析次数
,
每秒超过
< br>100
次，
就可能说明你绑定使用的不好，
也可能是
共享池设置不合理。
这时候可以启用参数<
/p>
cursor_sharing=similar|force
，
该
参数默认值为
exact
。但该参数
设置为
similar
时，存在
bug
，可能导致执行计
划的不优。
4
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
Sorts
：每秒
/
每事
务的排序次数
Logons
：每秒<
/p>
/
每事务登录的次数
< br>Executes
：每秒
/
每事
务
SQL
执行次数
< br>Transactions
：每秒事务数
.
每秒产生的事务数，反映数据库任务繁重与否。
Blocks
changed
per
Read
：表示逻辑读用于修
改数据块的比例
.
在每一次逻辑
读中更
改的块的百分比。
Recursive Call
：递归调用占所有操作的比率
.
递归调用的百分比
，如果有很
多
PL/SQL
，那么这个
值就会比较高。
Rollback per transac
tion
：每事务的回滚率
.
看回滚率
是不是很高，因为回
滚很耗资源
,
如
果回滚率过高
,
可能说明你的数据库经历了太多的无效操作
,
过
多的回滚可能还会带来
Undo
Block
的竞争
该参数计算公式如下
: Round(User
rollbacks / (user commits + user
rollbacks) ,4)* 100%
。
Rows per
Sort
：每次排序的行数
注
:
Oracle
的硬解析和软解析
提到软解析
(soft
prase)
和硬解析
(hard prase)
，就不能不说一下
Oracle
对
< br>sql
的处理过程。
当你发出一条
sql
语句交付
Oracle
，在执
行和获取结果前，
Oracle
对此
s
ql
将进行几个步骤的处理过程：
1
、语法检查
(syntax
check)
< br>检查此
sql
的拼写是否语法。
2
、语义检查
(semantic
check)
< br>诸如检查
sql
语句中的访问对象是否存在及该用户是否
具备相应的权限。
3
、对
sql
语句进行解析
(prase)
利用内部算法对
sql
进行解析，生成解析树
(parse
tree)
及执行计划
(execution
plan)
。
4
、执行
s
ql
，返回结果
(execute and
return)
5
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
其中，软、硬解析就发生在第三个过程里。
Oracle
利用内部的
hash
算法来取得该
sql
的
hash
值，
然后在
library
cache
< br>里查找是否存在该
hash
值；
假设存在，则将此
sql
与
cache
中的进行
比较；
假设“相同”，就将利用已有的解析树与执行计划，而省略了优化器的相关
工作。这也就
是软解析的过程。
诚然，
如果上面的
2
个假设
中任有一个不成立，
那么优化器都将进行创建解
析树、生成执行
计划的动作。这个过程就叫硬解析。
创建解析树、生成执行计划对于
sq
l
的执行来说是开销昂贵的动作，所以，
应当极力避免硬解析，
尽量使用软解析。
Instance Efficiency
Percentages (Target 100%)
Buffer Nowait %:
Buffer Hit %:
Library Hit %:
Execute to Parse %:
Parse CPU to Parse Elapsd %:
Redo NoWait %:
In-memory Sort
%:
Soft Parse
%:
Latch Hit
%:
% Non-Parse
CPU:
本节包
含了
Oracle
关键指标的内存命中率及其它数据库实例操作
的效率。其
中
Buffer Hit Ratio
也称
Cache Hit
Ratio
，
Library Hit
ratio
也称
Library
Cache
Hit
ratio
。同
Load
Profile
一节相同，这一节也没有所谓“正确”的值，
而只能根据应用的特点判断是否合适。在一个使用直接读执行大型并行查询的
DSS
环境，
20%
的
Buffer Hit Ratio
是可以接受的，而这个值对于一个
OLTP
系
统是完全不能接受的。根据
Oracle
的经验，对于
OLTP
系统，
Buffer
Hit
< br>Ratio
理想应该在
90%
以
上。
Buffer Nowait
表
示在内存获得数据的未等待比例。在缓冲区中获取
Buffer
的未等待比率。
Buffer
Nowait
< br>的这个值一般需要大于
99%
。否则可能存在争用，
可以在后面的等待事件中进一步确认。
6
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
buffer hit
表示进程从内存中找到数据块的比率，监
视这个值是否发生重大
变化比这个值本身更重要。对于一般的
O
LTP
系统，如果此值低于
80%
，应
该给
数据库分配更多的内存。
数据块在数据缓冲区中的命中率，
通常应在
95%
以上。
否则，小于
95%
，需要调整重要的参数，小于
90%
可能是要加
db_cache_size
。
一个高的命中率，
不一定代表这个系统的性能是最优的，<
/p>
比如大量的非选择性的
索引被频繁访问，就会造成命中率很高的假
相（
大量的
db file sequential
read
），但是一个比较低的命中率，一般就会对这个系统的性能产生
影响，需要
调整。命中率的突变，往往是一个不好的信息。
如果
命中率突然增大，可以检查
top
buffer
get
SQL
，查看导致大量逻辑读
的语句和索引，如果命中率突然减小，
可以检查
top
physical reads SQL
，检查产生大量物理读的语句，主要是那些
没有使用索引或者索引被删除的。
Redo NoWait
表示在
LOG
缓冲区获得
BUFFER
的未等待比例
。
如果太低（可参
考
90%
阀值），考虑增加
LOG
BUFFER
。
当
redo buff
er
达到
1M
时，就需要写到
redo
log
文件，
所以一般当
redo
buffer
设置超过
1M
，
不太可能存在等待
buffer
空间分配的情况。当前，一般设置为
< br>2M
的
redo buffer
，对于内存总量来说，
应该不是一个太大的值。
library hit
表示
Orac
le
从
Library Cache
中
检索到一个解析过的
SQL
或
PL/S
QL
语句的比率，当应用程序调用
SQL
或存储过程时，
Oracle
检查
L
ibrary
Cache
确定是否存在解析过的版本，
如果存在，
Oracle
立即执行语句；
如果不存
在，
Oracle
解析此语句，
并在
Library
< br>Cache
中为它分配共享
SQL
区。
低的
library
hit
ratio
会导致过多的解析，
增加<
/p>
CPU
消耗，
降低性能。
如果
library
hit
ratio
低于
90%
，可能需要调
大
shared pool
区。
STA
TEMENT
在共享区的命中率，通常
应该保持在
95%
以上，否则需要要考虑：加大共享池；使用绑定变量；修改
cursor_sharing
等参数。
Latch
Hit
：
Latch
是一种保护内存结构的锁，可以认为是
SE
RVER
进程获取访
问内存数据结构的许可。要确保
Latch
Hit>99%
，否则意味着
Shared
Pool
latch
争用，可能由于未共享的
SQL
，或者
Library
Cache
太小，可使用绑
定变更或调
7
深圳博睿同创信息技术有限公司
< br>
v1.0
可编辑可修改
大
Shared
Pool
解决。
要确保
>99%
，
否则存在严重的性能问题。当该值出现问题
的时候，我们可以借助后面的等待时间和
latch
分析来查找解决问题
。
Parse CPU to
Parse <
/p>
Elapsd
：
解析实际运行时间
/(
解析实际运行时间
+
解析中
等待资源时间
)
，
越高越好
。
计算公式为：
Parse CPU to Parse Elapsd %=
100*(parse time cpu / parse time elapse
d)
。即：解析实际运行时间
/(
解析
实际运行时间
+
解析中等待资源时间<
/p>
)
。如果该比率为
100%
，意味着
CPU
等待时
间为
0
，没有任何等待。
Non-Parse CPU
：
SQ
L
实际运行时间
/(SQL
实际运行时
间
+SQL
解析时间
)
，
太
低表示解析消耗时间过多
。
计算公式为：
% Non-Parse CPU
=round(100*1-PARSE_CPU/TOT_CPU),2)
。如果这个值比较小，表示解析消耗的
CPU
时间过多。
与
PARSE_CPU
相比，如果
TOT_CPU
很高，这个比值将接近
100%
，
这是很好的，
说明计算机执行的大部
分工作是执行查询的工作，
而不是分析查询
的工作。
Execute
to
Parse
：
是语句执行与分析的比例，如果要
SQL
重用率高，则这个
比例会很高。
该值越高表示一次解析后被重复执行的次数越多。
计算公式为：
Execute
to
Parse
=100
*
(1
-
Parses/Executions)
< br>。
本例中，
差不多每
execu
tion
5
次需要一次
parse<
/p>
。所以如果系统
Parses > Executions
，就可能出现该比率
小于
0
< br>的情况。
该值
<0
通常说明
shared pool
设置或者语句效率存在问题，造
成反复解析，
reparse
可能较严重
,
或者是可能同
snapshot
有关，通常说明数据
库性能存在问题。
In-memory
Sort
：
在内存中排序的比率，
如果过低说明有大量的排序在临时表
空间中进行。
考虑调大
PGA(10g)
。
如果低于
95%
，
可以通过适当调大初始化参数
PGA_AGGREGATE_T
ARGET
或者
SORT_AREA_SIZE
来解决，
注意这两个参数设置作用
的范围时不同的，<
/p>
SORT_AREA_SIZE
是针对每个
session
设置的，
PGA_AGGREGATE_TA
RGET
则时针对所有的
sesion
的。
8
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
Soft Parse
：
软解析的百分
比（
softs/softs+hards
），近似当作
sql
在共享
区的命中率，太低则需要调整应
用使用绑定变量
。
sql
在共享区的命
中率，小于
<95%,
需要考虑绑定，如果低于
80%
，那么就可以认为
sql
基本没有被重用。
Shared Pool
Statistics
Memory Usage %:
%
SQL with executions>1:
%
Memory for SQL w/exec>1:
Begin
End
Memory
Usage
%
：
对于一个已经运行一段时间的数据库来说，共享池内存使用
率，应该稳定在
75%-90%
间
，如果太小，说明
Shared
Pool
有浪费，而如果高于
90
，说明共享池中有争用
，内存不足。
这个数字应该长时间稳定在
75%
～
90%
。
如果这个百分比太
低，
表明共享池设置过大，
带来额外的管理上的负担，
从而在
某些条件下会导致性能的下降。
如果这个
百分率太高，
会使共享池外部的组件老
化，
如果
SQL
语句被再次执行，
这将
使得
SQL
语句被硬解析。
在一个大小
合适的
系统中，共享池的使用率将处于
75%
< br>到略低于
90%
的范围内
.
SQL with executions>1
< br>：执行次数大于
1
的
sql
比率，如果此值太小，说明
需要在应用中更多使用绑定变量，
避免过多
SQL
解析。
在一个趋向于循环运行的
系统中，
必须认真考虑这个数字。<
/p>
在这个循环系统中，
在一天中相对于另一部分
时间的部分时间里执行了一组不同的
SQL
语句。
在共享池中，
在观察期间将有一
组未被执行过的
SQL
语句，这仅仅是因为要执行它们的语句在观察期间没有运
行。只有系统连续运行相同的
SQL
语
句组，这个数字才会接近
100%
。
Memory for SQL w/exec>1
：执行次数
大于
1
的
SQL
消耗内存的占比。
这是与
不频繁使用的
SQL
语句相比，
频繁使用的
SQL
语句消耗内存多少的一个度量。
这
个数
字将在总体上与
% SQL with executions>1
非常接近，除非有某些查询任务
消耗的内存没有规律。在稳定状态下，总体上会看见
随着时间的推移大约有
75%
～
85%
的共享池被使用。
如果
Statspa
ck
报表的时间窗口足够大到覆盖所有的
9
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
周期，执行次数大于一
次的
SQL
语句的百分率应该接近于
1
00%
。这是一个受观
察之间持续时间影响的统计数字。可以期
望它随观察之间的时间长度增大而增
大。
小结：
通过
ORACLE
的实例有效性统计数据，
我们可以获得大概的一个
整体印象，
然而我们并不能由此来确定数据运行的性能。
当前性
能问题的确定，
我们主要还
是依靠下面的等待事件来确认。我们
可以这样理解两部分的内容，
hit
统计帮助
< br>我们发现和预测一些系统将要产生的性能问题，
由此我们可以做到未雨绸缪。
而
wait
事件，就是表明当前数据库已经
出现了性能问题需要解决，所以是亡羊补
牢的性质。
Top 5 Timed Events
Event
CPU time
Waits
Time(s)
515
64
47
35
34
Avg
Wait(ms)
2
9
4
7
% Total Call Time
Wait Class
Network
System I/O
User I/O
System I/O
SQL*Net
more
data
from
client
27,319
log file
parallel write
db file
sequential read
db file
parallel write
5,497
7,900
4,806
这是报告概要的最后一节
，
显示了系统中最严重的
5
个等待，<
/p>
按所占等待时间
的比例倒序列示。
当我们
调优时，
总希望观察到最显著的效果，
因此应当从这里
入手确定我们下一步做什么。例如
如果‘buffer
busy
wait’是较严重的等待事
件，我们应当继续研究报告中
Buffer
Wait
和
File/Tablespace IO
区的内容，
识别哪些文件导致了问题。如果最严重的等待事件是
I/O
事件，我们应当研究
按物理读排序的
SQL
语句区以识别哪些语句在执行大量
I/
O
，
并研究
Tablespace
和
I/O
区观察较慢响应时间的文件。如果
有较高的
LATCH
等待，就需要察看详
细的
LATCH
统计识别哪些
LAT
CH
产生的问题。
10
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
一个性能良好的系统，
cpu
time
应该在
top 5
的前面，否
则说明你的系统大部分时间都
用在等待上。
在这里，
log file parallel write<
/p>
是相对比较多的等待，占用了
7%
的
CPU
时间。
通常，在没有问题的数据库中，
CPU
time
总是列在第一个。
更多的等待事件，参见本报告
的
Wait
Events
一节。
RAC
Statistics
Number of
Instances:
Begin
2
End
2
Global Cache
Load Profile
Global Cache blocks
received:
Global Cache
blocks served:
GCS/GES
messages received:
GCS/GES
messages sent:
DBWR Fusion
writes:
Estd Interconnect
traffic (KB)
Per
Second
Per Transaction
Global Cache
Efficiency Percentages (Target local+remote
100%)
Buffer
access - local cache %:
Buffer access - remote cache
%:
Buffer access - disk
%:
11
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
Global Cache and Enqueue Services -
Workload
Characteristics
Avg global enqueue get time
(ms):
Avg global cache cr
block receive time (ms):
Avg
global cache current block receive time
(ms):
Avg global cache cr
block build time (ms):
Avg
global cache cr block send time (ms):
Global cache log flushes for cr blocks
served %:
Avg global cache
cr block flush time (ms):
Avg global cache current block pin time
(ms):
Avg global cache
current block send time (ms):
Global cache log flushes for current
blocks served %:
Avg global
cache current block flush time (ms):
Global Cache and Enqueue Services -
Messaging Statistics
Avg message sent
queue time (ms):
Avg message
sent queue time on ksxp (ms):
Avg message received queue time
(ms):
Avg GCS message
process time (ms):
Avg GES
message process time (ms):
%
of direct sent messages:
%
of indirect sent messages:
%
of flow controlled messages:
Main Report
Wait Events
Statistics
SQL Statistics
12
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
Instance Activity
Statistics
IO Stats
Buffer Pool
Statistics
Advisory Statistics
Wait
Statistics
Undo Statistics
Latch Statistics
Segment
Statistics
Dictionary Cache Statistics
Library Cache
Statistics
Memory Statistics
Streams
Statistics
Resource Limit Statistics
Parameters
Wait Events Statistics
Time Model Statistics
Wait Class
Wait Events
Background Wait
Events
Operating System Statistics
Service Statistics
Service Wait
Class Stats
Back to
Top
/* oracle
等待事件
是衡量
oracle
运行状况的重要依据及指示，等待事件分为
两类：空闲等待事件和非空
闲等待事件
,
TIMED_STATISTICS = TRUE
那么等待事件按等待的时间排序，
= FALSE
那么事件按等待的数
量排序。运行
statspac
k
期间必须
session
上设置
TIMED_STATISTICS = TRUE
，否则统计的数
据将失真。
空闲等待事件是
oracle
正等待某种工作，在诊断和优化数据库时候，
不用过多注意这部分事件，
非空闲等
待事件专门针对
oracle
的活动，
指数据库任务或应用程序运行过程中发生的等待，
< br>这些等待事件是我们在
调整数据库应该关注的
。
对于常见的等待事件，说明如下：
1)
db file
scattered read
文件分散读取
13
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
2)
该事件通常与全表扫描或者
fast full index
scan
有关。因为全表扫描是被放入内存中进行的进行
的，通
常情况下基于性能的考虑，有时候也可能是分配不到足够长的连续内存空间，所以会将数据块
分散
(scattered)
读入
Buffer Cache
中。该等待过大可能是缺少索引或者没有合适的索引
(
可以调整
optimizer_index_
cost_adj)
。这种情况也可能是正常的，因为执行全表扫描可能比索引扫描效
率更
高。当系统存在这些等待时，需要通过检查来确定全表扫描是否必需的来调整。因为
全表扫描被置于
LRU(Least Recently Used
，最近最少适用
)
列表的冷端
(c
old end)
，对于频繁访问的较小的数据表，
可以选择把
他们
Cache
到内存中，以避免反复读取。当这个等待事件
比较显著时，可以结合
v$$session_longops
动态性能视图来进行诊断，
该视图中记录了长时间
(
运行时间超过
6
秒的
)
运行的
事物，可能很多是全表扫描操作
(
不管怎样，这部分信息都是值得我们注意的
)
。
3)
< br>关于参数
OPTIMIZER_INDEX_COST_ADJ
< br>＝
n
：该参数是一个百分比值，缺省值为
100
，可以理解为
FULL
SCAN
COST/INDEX SCAN
COST
。当
n%*
INDEX
SCAN
<
br>COST ，从而设置一个更合适的值。
COST
SCAN
时，
oracle
会选
择使用索引。
在具体设置的时候，我们可以根据具体的语句来调整该值。如果我们希望某
个
statement
使用索引，
而实
际它确走全表扫描，可以对比这两种情况的执行计划不同的
COST
4)
db
file
sequential
read
文件顺序读取
整代码
,
特别是表连接
：该事件说明在单个数据块上
大量
等待，该值过高通常是由于表间连接顺序很糟糕（没有正确选择驱动行源），或者使
用了非选择性索
引。
通过将这种等待与
statspack
报表中已知其它问题联系起来
(
如效率不高的
sql),
通过检查确保索
引扫描是必须的，并确保多表连接的连接顺序来调整。
5)
buffer busy
wait
缓冲区忙
增大
DB_CACHE_SIZE,
加速检查点
,
调整代码
：
当进
程需要存取
SGA
中的
buffer<
/p>
的时候，它会依次执行如下步骤的操作：
当缓冲区以一种非共享方式或者如正在被读入到缓冲时
,
就会
出现该等待。该值不应该大于
1%
。当出
现等待问题时，可以检查缓冲等待统计部分
(
或
V$$WAITSTAT)
，确定该等待发生在什么
位置：
a)
如果等待是否位于段头
(Segment Header)
。这种情况表明段中的空闲列表（
freelist
）的块比
较少。可以考虑增加空闲列表
(freeli
st
，对于
Oracle8i
DMT)
或者增加
freelist groups(
在很
多时候这个调整是立竿见影的
(alter
table tablename strorage(freelists 2))
，
在
8.1.6
之
前，
< br>这个
freelists
参数不能动态修改
;
在及以后版本，
动态修改
feelists
需要设置
COMPATIBLE
至少为。也可以增加
PCTUSED
与
PCTFREE
之间距离（
PCTUSED-to-
pctfree gap
），其实就是说
降低
< br>PCTUSED
的值，尽快使块返回
freelist<
/p>
列表被重用。如果支持自动段空间管理（
ASSM
），
也可以使用
ASSM
模式
，这是在
ORALCE
920
以后的版本中新增的特性。
b)
c)
如果这一等待位于
undo
head
er
，
可以通过增加回滚段
(roll
back
segment)
来解决缓冲区的问题。
如果等待位于
undo block
上，我们需要增加提交的频率，使
block
可以
尽快被重用；使用更大
的回滚段；降低一致读所选择的表中数据的密度；增大
DB_CACHE_SIZE
。
d)
如果等待处于
data
block
，表明出现了
hot
block
，可以考虑如下方法解决：
①将频繁并发访
问的表或数据移到另一数据块或者进行更大范围的分布
(
可以增大
pctfree
值
，扩大数据分布，
减少竞争
)
，以避开这个
热点<
/p>
数据块。②也可以减小数据块的大小，从而减少一个数据块中的<
/p>
数据行数，降低数据块的热度，减小竞争；③检查对这些热块操作的
SQL
语句，优化语句。④
14
深圳
博睿同创信息技术有限公司
v1.0
可编辑可修改
增加
hot block
上的
initrans
值。但注意不要把
initr
ans
值设置的过于高了，通常设置为
5
就足够了。因为增加事务意味着要增加
ITL
事务槽，而每个
ITL
事务槽将占用数据块中
24
个字
节长度。默认情况下，每个数据块或者索引块中是
ITL
槽是
2
个，在增加<
/p>
initrans
的时候，可
以考虑增大
数据块所在的表的
PCTFREE
值，
这样
Oracle
会利用
PCTFRE
E
部分的空间增加
ITL
slot<
/p>
数量，最大达到
maxtrans
指定。
e)
如果等待处于
index
block
，应该考虑重建索引、分割索引或使用反向键索引。为了防止与数据
块相关的缓冲忙等待，也可以使用较小的块，在这种情况下，单个块中的记录就较少，所以这
个块就不是那么
繁忙
。或者可以设置更大的
PCTFREE,
使数据
扩大物理分布，减少记录间的热
点竞争。在执行
DML
(insert/update/ delete)
时，
Ora
cle
向数据块中写入信息，对于多事务
并发访问的数据表，关
于
ITL
的竞争和等待可能出现，为了减少这个等待，可以增加
initrans
，
使用多个
ITL
槽。在
Oracle9i
中，可以使用
ASSM
这个新特性
< br>Oracle
使用位图来管理空间使
用，减小争用。
【
当进程需要存取
< br>SGA
中的
buffer
的时候
，它会依次执行如下步骤的操作：
1.
获得
cache buffers
chains latch
，遍历那条
buffer
chain
直到找到需要的
buffer
header
2.
根据需要进行的操
作类型
(
读或写
)
，它需要在
buffer
header
上获得一个共享或独占模式的
buffer
pin
或者
buffer lock
3.
若进程获得
buffer
header
pin
，
它会释放获得的
cache
buffers
chains
latch
，
然后执行对
buffer
block
的操作
4.
若进程无法获得
buffer
header pin
，它就会在
buffer busy
waits
事件上等待
进程之所以无法获得
buffer header pin
，是因为为了保证数据的一致性，同一时刻一个
block
只能被一
个进程
pin
住进行存取，因此当一个进程需要存取
buffer cache
中一个被其他进程使用的
block
的时候，
这个进程就会产生对该
block
的
< br>buffer busy waits
事件。
截至
Oracle
9i
，
buffer busy waits
< br>事件的
p1,p2,p3
三个参数分别是
file#,block#
和
id
，分别表示等待
的
buffer block
所在的文件编号，块编号和具体的等待原因编号，到了
Oracle
10g
，前两个参数没变，
第
3
个参数变成了块类型编号，这一点可以通过查询
v$$
event_name
视图来进行验证：
PHP code:
Oracle 9i
SQL
>
select param
eter1
,
parameter2
,
parameter3 from v$$event_name where
name
=
'buffer busy
waits'
PARAMETER1
PARAMETER2 PARAMETER3
------------------------
------------------------
------------------------
file
#
block# id
Oracle 10g
15
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
PARAMETER1 PARAMETER2
PARAMETER3
------------------------
------------------------
------------------------
file
#
block# class#
在诊断
buffer busy
waits
事件的过程中，获取如下信息会很有用：
1.
获取产生
buffer busy
waits
事件的等待原因编号，这可以通过查询该事件的
p3
参数值获得
2.
获取产生此事件的
SQL
语句，可以通过如下的查询获得：
select sql_text from v$$sql
t1,v$$session t2,v$$session_wait t3
where = and =
and
= and ='buffer busy waits';
3.
获取等待的块的类型以及所在的
segment
，可以通过如下查询获得：
PHP
code:
select
'Segment Header'
class,,,
from dba_segments
a
,
v$$session_wait
b
where
=
and
=
and =
'buffer
busy waits'
union
select
'Freelist Groups'
class,,,
from dba_segments
a
,
v$$session_wait
b
where
=
and
between
+
1
and +
and >
1
and
=
'buffer busy waits'
union
select
||
' block'
class,,,
from dba_extents
a
,
v$$session_wait
b
where
=
and
between
and +
and =
'buffer busy waits'
and
not
exists
(
select 1 from
dba_segments
where
header_file
=
and
header_block
=
;
查询的第一部分：如果等待的块类型是
segment
header
，那么可以直接拿
buffer
busy
waits
事件的
p1
和
p2
参数去
dba_segments
视图中匹配
he
ader_file
和
header_block
字段即可找到等待的
segment
名称和
segment
类型，进行相应调整
查询的第二部分：如果等待的块类型是
freelist
groups
，也可以在
dba_segm
ents
视图中找出对应的
segment
名称和
segment
类型，注意这里的参数
p2
表示的
freelist groups
的位置是在
segment
的
header_block+1
到
header_bl
ock+freelist
groups
组数之间，并且
freelist
groups
组数大于
1
查询的第三部分：如果等待的块类型是普通的数据块，那么可以用
p1
、
p2
参数和
db
a_extents
进行
联合查询得到
block
所在的
segment
名称
和
segment
类型
对于不同的等待块类型，我们采取不同的处理办法：
16
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
segment header
：
进程经常性的访问
data
segment
header
通常有两个原因：获取或修改
process f
reelists
信息、扩
展高水位标记，针对第一种情况，进
程频繁访问
process freelists
信息导致
freelist
争用，我们
可以增大相应
的
segment
对象的存储参数
fr
eelist
或者
freelist groups
；若由于数据块频繁进出
freelist
而导致
进程经常要修改
freelist
，则可以将
< br>pctfree
值和
pctused
值设置较大的差距，从
而避免数据块频繁进出
freeli
st
；对于第二种情况，由于该
segment
空间消耗很快，而设置的
next
extent
过小，导致频繁扩展高水位标记，解决的办法是增大
segment
对象的存储参数
next
extent
或者直接在创建表空间的时候设置
extent
size uniform
block
：
某一或某些数据块被多
个进程同时读写，成为热点块，可以通过如下这些办法来解决这个问题：
(1)
降低程序的并发度，
如果程序中使用了
parallel
查询，
降低
parallel
degree
，
< br>以免多个
parallel
slave
同时访问同样的数据对象而形成等待降低性能
(2)
调整应用程序使之能读取较少的数据块就能获取所需的数据，
减
少
buffer
gets
和
physical
reads
(3)
< br>减少同一个
block
中的记录数，使记录分布于更多的
数据块中，这可以通过若干途径实现：可以
调整
segment
对象的
pctfree
值，
可以将
segment
重建到
block
size
较小的表空间中，
< br>还可以用
alter
table minimize
records_per_block
语句减少每块中的记录数
(4)
若热点块对象是类似自增
id<
/p>
字段的索引，则可以将索引转换为反转索引，打散数据分布，分散热
点块
segment
header
：
undo
segment header
争用是因为系统中
undo
segment
不够，需要增加足够的
undo
segment
，根据
undo segment
的
管理
方法，若是手工管理模式，需要修改
rollback_segments
初始化参数来增加
rollback
segment
，若是自动管理模
式，可以减小
transactions_per_rollback_segment
初始化参数
的值来使
oracle
自动增多
rollback
segment
的数量
block
：
undo block
争用是由于应用程序中存在对数据的读和写同时进行，读进程需要到
undo segment
中去
获得一致性数据，解决办法
是错开应用程序修改数据和大量查询数据的时间
小结：
buffer busy waits
< br>事件是
oracle
等待事件
中
比较复杂的一个，其形成原因很多，需要根据
p3
参数对照
Oracle
提供的原因代码表进行相应的诊断，
< br>10g
以后则需要根据等待的
block
类型结合
引起等待时间的具体
SQL
< br>进行分析，采取相应的调整措施
】
6)
latch
free
：
当闩锁丢失率高于
%
时，
需
要调整这个问题。
详细的我们在后面的
Latch
Activity
for
DB
部分说明。
latch
是一种低级排队机制，用于保护
SGA
中共享内存结构。
latch
就像是一种快速地
被获取和释放
的内存锁。
用于防止共享内存结构被多个用户同时
访问。
如果
latch
不可用，
就会记录
latch
释放失败
(latch
free miss
)
。有两种与闩有关的类型
:
17
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
■
立刻。
■
可以等待。
假如一个进程试图在立刻模式下获得闩，而该闩已经被另外一
个进程所持有，如果该闩不能立可
用的话，那么该进程就不会为获得该闩而等待。它将继
续执行另一个操作。
大多数
latch
问题都与以下操作相关
:
没有很好的是用绑定变量
(library cache
latch)
、重作生成问题
(redo
allocation latch)
、缓
冲存储竞争问题
(cache
buffers
LRU
chain)
，
以及
< br>buffer
cache
中的存在
热点
块
(
cache
buffers
chain)
。
通常我们说，如果想设计一个失败
的系统，不考虑绑定变量，这一个条件就够了，对于异构性强
的系统，不使用绑定变量的
后果是极其严重的。
另外也有一些
latch
等待与
< br>bug
有关，
应当关注
Meta
link
相关
bug
的公布及补丁的发
布。
当
latch
miss rat
ios
大于
%
时，就应当研究这一问题
。
Or
acle
的
latch
机制是竞争，<
/p>
其处理类似于网络里的
CSMA/CD
，
所有用户进程争夺
latch
，
对于
愿意等待类型
(willing-
to-wait)
的
latch,
如果
一个进程在第一次尝试中没有获得
latch,
那么它会等待并
且再尝试一次
,
如果经过
_spin_count
次争夺不能获得
latch
,
然后该进程转入睡眠状态，持续一段指定长
度的时间，然后
再次醒来，按顺序重复以前的步骤
.
在
8i/9i
中默认值是
_spin_count=2000
。
如果
SQL
语句不能调整，
在
8.1.6
版本以上，
Orac
le
提供了一个新的初始化参数
:
C
URSOR_SHARING
可以通过设置
CURSOR_SH
ARING = force
在服务器端强制绑定变量。设置该参数可能会带来一定的
副作用，
对于
Java
的程序，有相关
的
bug
，具体应用应该关注
Meta
link
的
bug
公告。
***Latch
问题及可能解决办法
------------------------------
* Library Cache and Shared
Pool (
未绑定变量
---
绑定变
量
,
调整
shared_pool_s
ize)
每当执行
SQL
或
PL/SQL
存储过程
,
包
,
函数和触发器时
,
这个
Latch
即被用到
.Parse
操作中
此
Latch
也会被频繁使用
.
* Redo Copy (
增大<
/p>
_LOG_SIMULTANEOUS_COPIES
参数
)
重做拷贝
La
tch
用来从
PGA
向重做日志缓冲区
拷贝重做记录
.
* Redo
Allocation (
最小化
REDO
生成
,
避免不必要提交
)
此
Latch
用来分配重做日志缓冲区中的空间
,
可以用
< br>NOLOGGING
来减缓竞争
.
* Row Cache Objects
(
增大共享池
)
< br>数据字典竞争
.
过度
parsi
ng.
* Cache Buffers Chains
(_DB_BLOCK_HASH_BUCKETS
应增大或设为质数
< br>)
过热
数据块造成了内存缓冲链
Latch
竞争
.
*
Cache
Buffers
Lru
Chain
(
调整
< br>SQL
，设置
DB_BLOCK_LRU_LATCHE
S,
或使用多个缓冲区池
)
18
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
扫描全部内存缓冲区块的
LRU(
最近最少使用<
/p>
)
链时要用到内存缓冲区
LRU
链
Latch.
太小内存
缓冲区、过大的内存缓冲区吞吐量、过多的内存中进行的排序操作、
DBWR
速度跟不上工作
负载等会引起此
Latch
竞争。
7)
Enqueue
队列是一种锁，保护一些共享资源，防止并发的
DML
操作。队列采用
FIFO
策略，
注意
latch
并不是采用的
FIFO
机制。比较常见的有
3
种类型的队列：
ST
队列，
HW
队
列，
TX4
队列。
8)
ST Enqueue
的等待主要是在字典管理的表空间中进行空间管理和分配时产生的。解决方法：
< br>1
）将字
典管理的表空间改为本地管理模式
2
）预先分配分区或者将有问题的字典管理的表空间的
next
extent
设置大一些。
9)
HW Enqueue
是用于
segment
的
HWM
的。当出现这种等待的时候，可以通过手工分配
ext
ents
来解决。
10)
TX4
Enqueue
等待是最常见的等待情况。通常有
3
种情况会造成这种类型的等待：
1
）唯一索引
中的重
复索引。解决方法：
commit
或者
rollback
以释放队列。
2
）对同一个位图索引段（
bitmap index
fragment
）有多个
update
，因为一个
bitmap index fragment
可能包含了多个
rowid
，所以当多个用
户更新时，可能一个用户会锁定该段，从而造成等待。解决方法同上。
3
）有多个用户同时对一个数
据块作
update
，当然这些
DML
操作可
能是针对这个数据块的不同的行，如果此时没有空闲的
ITL
槽
，
就会产生一个
block-level
锁。解决方法：增大表的
initrans
值使创建更多的<
/p>
ITL
槽；或者增大表
的
pctfree
值，这样
oracle
可以根据需要在
pctfree
的空间创建更多的
ITL
槽；使用
smaller
block
size
，这样每个块中
包含行就比较少，可以减小冲突发生的机会。
AWR
报告分析
--
等待事件
-
队列
.doc
11)
Free
Buffer
释放缓冲区
：
这个等待事件表明系统正在等待内存中的可用空间，
这说明当前
Buffer
中
已经没有
Free
的内存空间。如果应用设计良好，
SQL
书写规范，充分绑定变量，那这种等待可能说
明
Buffe
r
Cache
设置的偏小，你可能需要增大
DB_CACHE_SIZE
。该等待也可能说明
DB
WR
的写出速度
不够，或者磁盘存在严重的竞争，可以需要考
虑增加检查点、使用更多的
DBWR
进程，或者增加物理
磁盘的数量
,
分散负载，平衡
IO
。
12)
Log file
single write
：该事件仅与写日志文件头块相关，通常发生在增加新的组成
员和增进序列
号时。头块写单个进行，因为头块的部分信息是文件号，每个文件不同。更
新日志文件头这个操作在
后台完成，一般很少出现等待，无需太多关注。
13)
log file
parallel write
：从
log buffer
写
redo
记录到
redo log
文件，主要
指常规写操作
(
相对
于
log file sync)
。如果你的
Log
group
存在多个组成员，当
flush log
buffer
时，写操作是并行
的，
这时候此等待事件可能出现。
尽管这个写操作并行处理，
直到所
有
I/O
操作完成该写操作才会完
成
(
如果你的磁盘支持异步
IO
或者使用
IO
SLAVE
，那么即使只有一个
redo log file
member,
也有可
能出现此等待
)
。这个参数和
log file sync
时间相比较可以用来衡量
log file
< br>的写入成本。通常
称为同步成本率。改善这个等待的方法是将
redo logs
放到
I/O
快
的盘中，尽量不使用
raid5
，确保
表空间不是处在热备模式下，确保
redo log
和
data
的数据文件位于不同的磁盘中。
14)
log
file
sync
：当一个用户提交
或回滚数据时，
LGWR
将会话的
re
do
记录从日志缓冲区填充到日志文
件中，用户的进程必须等待
这个填充工作完成。在每次提交时都出现，如果这个等待事件影响到数据
19
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
库性能，那么就需要修改应用程序的提交频率
,
为减少这个等待事件，须一次提交更多记录，或者将
重做日志
REDO LOG
文件访在不同的物理磁盘上，提高
I/O
的性能。
当一个用户提交或回滚数据时，
LGWR
将会话期的重做由日志缓冲器写入到重做日志中。日志文件同
步过程必须等待这一过
程成功完成。
为了减少这种等待事件，
可以尝试一次提交更多的
记录
(
频繁的提交会
带来更多的系统开
销
)
。
将重做日志置于较快的磁盘上，
或者交替使用不同物理磁盘上的重做日志，
以降低
归档对
LGWR
的影响。
对于软
R
AID
，一般来说不要使用
RAID
5
，
RAID5
对于频繁写入得系统
会带来较大的性能损失，
可以考虑使用文件系统直接输入
/
输出，或者使用裸设备
(raw
device)
，这样可以获得写入的性能提高。
15)
log buffer sp
ace
：日志缓冲区写的速度快于
LGWR
写
REDOFILE
的速度
,
可以增大日志文件大小，增
加日志缓冲区的大小，或者使用更快的磁
盘来写数据。
当你将日志缓冲
(log
buffer)
产生重做日志的速度比
LGWR
的写出速度快，或者是当日志切换
(log
< br>switch)
太慢时，就会发生这种等待。这个等待出现时，通常表明
redo log buffer
过小，为解决这个问
题，可以考虑增大日志文件的大小，或者增加日志缓冲器的大小。
另外一个可能的原因是磁盘
I/O
存
在瓶颈，可以考虑使用写入速度更快的磁盘。在允许的条件下设置
可以考虑使用裸设备来
存放日志文件，提高写入效率。在一般的系统中，最低的标准是，不要把日志文件
和数据
文件存放在一起，因为通常日志文件只写不读，分离存放可以获得性能提升。
16)
logfile switch
：通常是因为归档速度不够快。
表示所有的提交
(commit)
的请求都需要等待
日志文
件切换
的完成。
Log file Switch
主要包含两个子事件
:
17)
log file
switch (archiving needed)
这个等待事件出现时通常是因
为日志组循环写满以后，第一
个日志归档尚未完成，出现该等待。出现该等待，可能表示
io
存在问题。解决办法
:
①可以考虑增大
日志文件和增加日志组；②移动归档文件到快速磁盘；③
调整
log_archive_max_processes
。
18)
log file switch (checkpoint incomplete)
当日志组都写完以后，
LGWR
试图写第一个
log file
，
如果这时数据库没有完成写出记录在第一个
log file
中的
dirty
块时
(
例如第一个检查点未完成
)
，
该等待事件出现。该等待事件通常表示你的
DBWR
写出速度太慢或者
IO
存在问题。为
解决该问题，
你可能需要考虑增加额外的
DBWR
或者增加你的日志组或日志文件大小，或者也可以考虑增加
checkpo
int
的频率。
19)
DB File
Parallel Write
：文件被
DBWR
并行写时发生。解决办法：改善
IO
性能。
处理此事件时，需要注意
1
）
db file
parallel write
事件只属于
DBWR
进程。
2
）缓慢的
DBWR
可能影响前台进程。
3
）大量的
db file
parallel write
等待时间很可能是
I/O
问题引起的。（在确认
os
支持异步
io
的前提
下，你可以在系统中检查
disk_asynch_io
参数，保证为
TR
UE
。可以通过设置
db_writer_processes
来提
高
DBWR
进程数量，当然前提是不要超过
cpu
的数量。）
20
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
DBWR
进程执行经过
SG
A
的所有
数据库
写入，
当开始写入时，
DBWR
进程编译一组脏块
（
dirty
block
）
，
并且将系统写入调用发布到操作系统。
< br>DBWR
进程查找在各个时间内写入的块，包括每隔
3<
/p>
秒的一次查找，
当前台进程提交以清除缓冲区中的内容时：在检查
点处查找，当满足
_DB_LARGE_DIRTY_QUEUE
、
_DB_BLOCK_MAX_DIRTY_TARGET
和
FAST_START_MTTR_TARGET
阀值时，等
等。
虽然用户会话从来没有经历过
db file
parallel
write
等待事件，但这并不意味着它们
不会受到这种
事件的影响。缓慢的
DBWR
写入性能可以造成前台会话在
write complete
waits
或
free buffer waits
事
件上等待。
DBWR
写
入性能可能受到如下方面的影响：
I/O
操作的类型（同步或异
步）、存储设备（裸设备
或成熟的文件系统）、数据库布局和
I
/O
子系统配置。需要查看的关键数据库统计是当
db
file parallel
write
、
free buffer
waits
和
write complete waits
等待事件互相关联时，系统范围内的
TIME_WAITED
和
AVERAGE_WAIT
。
如果
db
file parallel
write
平均等待时间大于<
/p>
10cs
（或者
100ms
），则通常表明缓慢的
I/O
吞吐量。
可以通过很多方法来改善平均等待时间。主要的方法是使用正确类型的
I/O
操作。如果数据文件位于裸设
备（
ra
w device
）上，并且平台支持异步
I/O
，就应该使用异步写入。但是，如果数据库位于文件系统上，
则应该使用同步
写入和直接
I/O
（这是操作系统直接
I/O
）。除了确保正在使用正确类型的
I/O
操作，还应
该检查你的数据库布局并使用常见的命令监控来自操作系统的
I/O
吞吐量。例如
sar
-d
或
iostat
-dxnC
。
当
db
file
parallel
write
平均等
待时间高并且系统繁忙时，用户会话可能开始在
free
buffer
waits
事件上等待
。
这是因为
DBWR
进程不能满足释放
缓冲区的需求。
如果
free
buffer
waits
事件的
TIME_WAITED
高，则应该在高速缓存中增加缓冲区数量之
前说明
DBWR
I/O
吞吐量的问题。
高
db file parallel
write
平均等待时间的另一个反响是在
write
complete waits
等待事件上的高
TIME_WA
ITED
。前台进程不允许修改正在传输到磁盘的块。换句话说，也就是位于
DBWR
批量写入中的块。
前台的会话在
write complete
waits
等待事件上等待。因此，
write
complete waits
事件的出现，一定
标志着缓慢的
DBWR
进程，可以通过改进
DBWR
I/O
吞吐量修正这种延迟。
20)
DB File
Single Write
：当文件头或别的单独块被写入时发生，这一等待直到所有的
I/O
调用完成。
解决办法：改善
IO
性能。
21)
DB FILE
Scattered Read
：当扫描整个段来根据初始化参数
db_file_multiblock_read_count
读取多
个块时发生，因为数据可能分散在不同的部分，这与分条或分段）相关，因此通常需要多个分散的读<
/p>
来读取所有的数据。等待时间是完成所有
I/O
< br>调用的时间。解决办法：改善
IO
性能。
这种情况通常显示与全表扫描相关的等待。
当数据库进行全表扫时，基于性能的考虑，数据会分散
(scatte
red)
读入
Buffer Cache
。如果这个等待事
件比较显著，可能说明对于某些全表扫描的表，没有创建索引或者没
有创建合适的索引，我们可能需要检
查这些数据表已确定是否进行了正确的设置。
然而这个等待事件不一定意味着性能低下，
在某些条件下
Oracle
会主动使用全表扫描来替换索引扫描
以提
高性能，这和访问的数据量有关，在
CBO
下
Oracle
会进行更为智能的选择，在
RBO
下
Oracle
更
倾向于使
用索引。
21
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
因为全表扫描被置于
LRU
（
Least Recently Used
，最近最少适用）列表的冷端（
cold end
），对于频繁访
问的较小的数据表，可以选择把他们
Cache
到内存中，以避免反复读取。
当这个等待事件比较显著时，可以结合
v$$session_longop
s
动态性能视图来进行诊断，该视图中记录
了长时间（运行时间
超过
6
秒的）运行的事物，可能很多是全表扫描操作（不管怎样
，这部分信息都是值
得我们注意的）。
22)
DB FILE
Sequential Read
：当前台进程对数据文件进行常规读时发生，包括索引
查找和别的非整段
扫描以及数据文件块丢弃等待。等待时间是完成所有
< br>I/O
调用的时间。解决办法：改善
IO
性能。
如果这个等待事件比较显著，可能表示在多表
连接中，表的连接顺序存在问题，没有正确地使用驱动表；
或者可能索引的使用存在问题
，并非索引总是最好的选择。在大多数情况下，通过索引可以更为快速地获
取记录，所以
对于编码规范、调整良好的数据库，这个等待事件很大通常是正常的。有时候这个等待过高
和存储分布不连续、连续数据块中部分被缓存有关，特别对于
DML
< br>频繁的数据表，数据以及存储空间的不
连续可能导致过量的单块读，定期的数据整
理和空间回收有时候是必须的。
需要注意在很多情况下，使用
索引并不是最佳的选择，比如读取较大表中大量的数据，全表扫描可能
会明显快于索引扫
描，所以在开发中就应该注意，对于这样的查询应该进行避免使用索引扫描。
23)
Direct
Path
Read
：
一般直接路径读取是指将数据块直接读入
PGA
中。<
/p>
一般用于排序、
并行查询和
read <
/p>
ahead
操作。这个等待可能是由于
I
/O
造成的。使用异步
I/O
模式或者
限制排序在磁盘上，可能会降
低这里的等待时间。
与直接读取相关联的等待事件。当
ORACLE
将
数据块直接读入会话的
PGA
（进程全局区）中，同时绕过
SGA
（系统全局区）。
PGA
中的数据并不和其他的会话共享。即表明，读入的这部分数据该会话独自使用，
不放于共享的
SGA
中。
在排序操作
(order
by/group
by/union/distinct/r
ollup/
合并连接
)
时，由于
PGA
中的
SORT_AREA_SIZE
空
间不足，
造成需要使用临时表空间来
保存中间结果，
当从临时表空间读入排序结果时，
产生
direct
path
read
等待事件。
使用
HASH
连接的
SQL<
/p>
语句，
将不适合位于内存中的散列分区刷新到临时表空间中。
为了查明匹配
SQL
谓词
< br>的行，
临时表空间中的散列分区被读回到内存中
(
目的是为了查明匹配
SQL
谓词的行
)
，
ORALCE
会话
在
direct
path
read
等待事件上等待。
使用并行
扫描的
SQL
语句也会影响系统范围的
direct
path
read
等
待事件。
在并行执行过程中，
direct
path
read
等待事件与从属查
询有关，而与父查询无关，运行父查询的会话基本上会在
PX Deq:Execute
Reply
上等待，从属查询会产生
direct path
read
等待事件。
直接读取可能按
照同步或异步的方式执行，取决于平台和初始化参数
disk_asynch_io
参数的值。使
用异步
I/O
时，系统范围的等待的事件的统计可能不准确，会造成误导作用。
24)
direct
path
write
：直接路径写该
等待发生在，系统等待确认所有未完成的异步
I/O
都已写入
磁盘。
对于这一写入等待，我们应该找到
I/O
操作最为频繁的数据文件
(
如果有过多的排序操作，
很有可能
就是临时文件
)
，分散负载，
加快其写入操作。如果系统存在过多的磁盘排序，会导致临时表空间操
22
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
作频繁，对于这种情况
，可以考虑使用
Local
管理表空间，分成多个小文件，写入
不同磁盘或者裸设
备。
在
DSS
系统中，存在大量的
direct
path read
是很正常的，但是在
OLTP
系统中，通常显著的直接路
径读（
direct
path read
）都意味着系统应用存在问题，从而导致大量的磁盘排序读取操作。
直接路径写（
direct
paht write
）通常发生在
Oracle
直接从
PGA
写数据到数据文件或临时文件，这个写
操作可以绕过
SGA
。
这类写入操作通常在以下情况被使用：
·直接路径加载；
·并行
DML
操作；
·磁盘排序；
·对未缓存的“LOB”段的写入，随后会记录为
direct
path write(lob)
等待。
最为常见的直接路径写，多数因为磁盘排序导致。对于这一写入等待，我们应该找到
I/O
操作最为频
繁的数据文件（如果有过多的排序操作，很有
可能就是临时文件），分散负载，加快其写入操作。
25)
control
file
parallel
write
：当
server
进程更新所有控制文件时，这个事件可能出现。如果等待
很短，可以不
用考虑。如果等待时间较长，检查存放控制文件的物理磁盘
I/O
是否存在瓶颈。
26)
多个控制文件是完全相同的拷
贝，用于镜像以提高安全性。对于业务系统，多个控制文件应该存放在
不同的磁盘上，<
/p>
一般来说三个是足够的，
如果只有两个物理硬盘，
那么两个控制文件也是可以接受的。
在同一个磁盘上保存多个控制文件是不具备
实际意义的。减少这个等待，可以考虑如下方法
:
①减少
控制文件的个数
(
在确保安全的前提下
)
。②如果系统支持，使用异步
IO
。③转移控制文件到
IO
负担
轻的物理磁盘。
27)
control file
sequential read
28)
control file single write
：控
制文件连续读
/
控制文件单个写对单个控制文件
I/O
存在问题时，
这两个事件会出现。如果等待比
较明显，检查单个控制文件，看存放位置是否存在
I/O
瓶颈。
29)
library
cache pin
该事件通常是发生在先有会话在运行
PL/SQL,VIEW,TYPES
等
o
bject
时
,
又有另外的会话执行重
新编译
这些
object,
即先给对象
加上了一个共享锁
,
然后又给它加排它锁
,
这样在加排它锁的会话上就会出现这个
等待。
P1,P2
可与
x$$kglpn
和
x$$kglob
表相关
X$$KGLOB (Kernel Generic Library Cache
Manager Object)
X$$KGLPN (Kernel
Generic Library Cache Manager Object Pins)
--
查询
X$$KGLOB,
可找到相关的
object,
其
SQL
语句如下
(
即把
V$$SESSION_WAIT
中的
P1raw
与
X$$KGLOB
中的
KGLHDADR
相关连
)
select kglnaown,kglnaobj from
X$$KGLOB
where KGLHDADR =(select p1raw
from v$$session_wait
where
event='library cache pin')
--
查出引起该等待事件的阻塞者的
sid
23
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
select sid from x$$kglpn , v$$session
where KGLPNHDL in
(select
p1raw from v$$session_wait
where
wait_time=0 and event like 'library cache pin%')
and KGLPNMOD <> 0
and v$$=x$$
--
查出阻塞者正执行的
SQL
语句
select
sid,sql_text
from v$$session, v$$sqlarea
where v$$=v$$
and
sid=<
阻塞者的
sid>
这样
,
就可找到
等
待的根源，从而解决由此引起的性能问题。
30)
library cache
lock
31)
该事件通常是由于执行多个
DDL
操作导致的
,
即在
library cache obje
ct
上添加一个排它锁后
,
又从
另一个会话给它添加一个排它锁
,
这样在第二
个会话就会生成等待。可通过到基表
x$$kgllk
中查找其<
/p>
对应的对象。
32)
--
查询引起该等待事件的阻塞者的
sid
、会话用户、锁住的对
象
33)
select ,,
34)
from x$$kgllk a , v$$session b
35)
where in
36)
(select p1raw
from v$$session_wait
37)
where wait_time=0 and event = 'library
cache lock')
38)
and <> 0
39)
and =
40)
当然也可以直接从
v$$locked_objects
中查看，但没有上面语句直观根据
sid
可以到
v$$process
中查
出
pid
，然后将其
kill
或者其它处
理。
41)
对于常见的一些
IDLE
wait
事件举例：
dispatcher timer
lock element cleanup
Null event
parallel query dequeue wait
parallel query idle wait -
Slaves
pipe get
PL/SQL lock timer
pmon timer- pmon
24
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
rdbms ipc message
slave wait
smon timer
SQL*Net break/reset to
client
SQL*Net message
from client
SQL*Net
message to client
SQL*Net more data to client
virtual circuit status
client message
SQL*Net message from client
下面是关于这里的常见的等待事件和解决方法的一个快速预览
等待事件
Sequential
Read
Scattered Read
Free Buffer
Buffer Busy Segment header
Buffer Busy Data block
Buffer Busy Undo header
Buffer Busy Undo block
Latch Free
Enqueue
–
ST
Enqueue
–
HW
Enqueue
–
TX4
Log Buffer Space
Log File Switch
Log file sync
Write complete waits
一般解决方法
调整相关的索引和选择合适的驱动行源
表明出现很多全表扫描。优化
code
，
cache
小表到内存中。
增大
DB_CACHE_SIZE
，增大
c
heckpoint
的频率，优化代码
增加
freelist
或者
free
listgroups
隔离热块；使用反转索引；使用更小的
块；增大表的
initrans
增加回滚段的数量或者大小
Commit
more
；增加回滚段的数量或者大小
检查具体的等待
latch
类型，解决方法参考后面介绍
使用本地管理的表空间或者增加预分配的盘区大小
在
HWM
之上预先分配盘区
在表或者索引上增大
initrans
的值或者使用更小的块
增大
LO
G_BUFFER
，改善
I/O
增加或者增大日志文件
减小提交的频
率；使用更快的
I/O
；或者使用裸设备
增加
DBWR
；提高
CKPT
的频率；
Time Model Statistics
25
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
Total time in
database user-calls (DB Time): 663s
Statistics
including
the
word
measure
background
process
time,
and
so
do
not
contribute
to the DB time statistic
Ordered by % or DB time
desc, Statistic name
Statistic Name
DB
CPU
sql execute elapsed
time
parse time
elapsed
PL/SQL execution
elapsed time
hard parse
elapsed time
connection
management
call
elapsed
time
hard parse (sharing criteria) elapsed
time
repeated
bind elapsed time
PL/SQL
compilation elapsed time
failed parse elapsed time
DB time
background elapsed time
background cpu time
Time
(s)
%
of DB Time
此节显示了各种类型的数据库处理任务所占用的
CPU
时间。
26
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
DB time=
报表头部显示的
db
time=
cpu time + all of nonidle wait
event time
Back
to Wait Events Statistics
Back to Top
Wait
Class
等待事件的类型
s - second
cs - centisecond - 100th of a second
ms -
millisecond - 1000th of a second
us - microsecond -
1000000th of a second
ordered by wait time desc, waits desc
查询
Oracle 10gR1
提供的
12
个等待事件类：
select wait_class#, wait_class_id,
wait_class from v$$event_name group by
wait_class#, wait_class_id, wait_class
order by wait_class#;
Waits
Wait Class
Waits
%Time
-outs
Total
Wait
Time
(s)
Avg wait (ms)
/txn
User
I/O
System I/O
Network
66,837
28,295
1,571,45
0
Cluster
Other
Application
Concurrency
Commit
Configurati
on
210,548
81,783
333,155
5,182
919
25,427
29
28
16
5
4
1
0
0
0
1
4
0
120
93
66
2
3
0
Back to Wait Events
Statistics
Back to
Top
27
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
Wait Events
现实非空闲等待事件
后面是空闲等待事件
s - second
cs - centisecond - 100th of a second
ms -
millisecond - 1000th of a second
us - microsecond -
1000000th of a second
ordered by wait time desc, waits desc
(idle events last)
（
1
）查询所有等待事件及其属性：
< br>
select event#, name, parameter1,
parameter2, parameter3 from v$$event_name order
by name;
（
2
）查询
Oracle 1
0gR1
提供的
12
个等待事件类：<
/p>
select wait_class#,
wait_class_id, wait_class from v$$event_name group
by
wait_class#, wait_class_id,
wait_class order by wait_class#;
下面显示的内容可能来自下面几个视图）
V$$EVENT_NAME
视图包含所有为数据库实例定义的等待事件。
V$$SYSTEM_EVENT
视图显示自从实
例启动后，所有
Oracle
会话遇到的所有等待事件的总
计统计。
V$$SESSION_EVEN
T
视图包含当前连接到实例的所有会话的总计等待事件统计。该视图包
< br>含了
V$$SYSTEM_EVENT
视图中出现的所有列
。它记录会话中每一个等待事件的总等待次
数、已等待时间和最大等待时间。
SID
列标识出独立的会话。每个会话中每个事件的最
大等待时间在
MAX_WAIT
列中追踪。
通过用
SID
列将
V$$SES
SION_EVENT
视图和
V$$SESSION
视图结合起来，可得到有关会话和用户的更多信息。
V$$SESSION_WAIT
视图提供关于每个会话正在等待的事件或资源的详细信
息。
该视图在任
何给定时间，只包含每个会话的一行活动的或不
活动的信息。
自从
OWI
在
Oracle 7.0.12
中引入后，就具有
下来
4
个
V$$
视图：
28
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
V$$EVENT_NAME
V$$SESSION_WAIT
V$$SESSION_EVENT
V$$SYSTEM_EVENT
除了这些等待事件视图之外，
Oracle 10gR1
中引入了下列新视图以从多个角度显示等
待信息：
V$$SYSTEM_WAIT_CLASS
V$$SESSION_WAIT_CLASS
V$$SESSION_WAIT_HISTORY
V$$EVENT_HISTOGRAM
V$$ACTIVE_SESSION_HISTORY
然而，
V$$SESSION_WAIT
、
V$$SESSION_WAIT
和
V$$SE
SSION_WAIT
仍然是
3
个重要
的视图，
它们提供了不同粒度级的等待事件统计和计时信息。三者的关系如下：
V$$SESSION_WAIT
%Time
Event
Waits
-outs
SQL*Net
more data from client
log
file parallel write
db file
sequential read
db file
parallel write
db file
scattered read
direct path
write
reliable
message
SQL*Net break/reset
to client
db file parallel
read
gc current multi block
request
control file
sequential read
direct path
read temp
gc cr multi block
request
27,319
5,497
7,900
4,806
10,310
42,724
355
333,084
3,732
175,710
15,974
1,873
20,877
(s)
64
47
35
34
31
30
18
16
13
10
10
9
8
(ms)
2
9
4
7
3
1
49
0
4
0
1
5
0
/txn
Total
Wait
Time
Avg wait
Waits
V$$SESSION_EVENT
V$$SYSTEM_EVENT
29
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
log file sync
gc
cr block busy
enq: FB -
contention
DFS lock
handle
control file parallel
write
gc current block
2-way
library cache
lock
name-service call
wait
row cache
lock
gcs log flush
sync
os thread
startup
gc cr block
2-way
gc current block
busy
SQL*Net message to
client
919
526
10,384
3,517
1,946
4,165
432
22
3,894
1,259
18
3,671
113
1,544,11
5
4
3
3
3
3
2
2
2
2
2
2
2
1
1
4
6
0
1
1
0
4
76
0
1
89
0
12
0
gc buffer busy
gc
cr disk read
direct path
write temp
gc current grant
busy
log file switch
completion
CGS wait for IPC
msg
gc current grant
2-way
kjbdrmcvtq
lmon
drm
quiesce:
ping
completion
enq: US - contention
direct path read
enq: WF - contention
ksxr poll remote instances
library cache pin
ges global resource directory to be
frozen
wait for scn
ack
log file sequential
read
undo segment
extension
15
3,272
159
898
29
48,739
1,142
9
567
138
14
13,291
211
9
583
36
25,342
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
70
0
5
1
17
0
0
19
0
1
9
0
1
10
0
2
0
30
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
rdbms ipc reply
ktfbtgex
enq: HW
- contention
gc cr grant
2-way
enq: TX - index
contention
enq: CF -
contention
PX Deq: Signal
ACK
latch free
buffer busy waits
KJC: Wait for msg sends to
complete
log buffer
space
enq: PS -
contention
enq: TM -
contention
IPC send
completion sync
PX Deq: reap
credit
log file single
write
enq: TT -
contention
enq: TD - KTF
dump entries
read by other
session
LGWR wait for redo
copy
PX Deq Credit: send
blkd
enq: TA -
contention
latch: ges
resource hash list
enq: PI -
contention
write complete
waits
enq: DR -
contention
enq: MW -
contention
enq: TS -
contention
PX qref
latch
279
6
44
158
1
64
37
3
625
154
11
46
70
40
1,544
36
46
12
1
540
17
14
44
8
1
3
3
3
150
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
10
1
0
34
1
1
10
0
0
2
1
0
0
0
0
0
1
12
0
0
0
0
0
2
0
0
0
0
PX
qref latch
在并行执行的情况下偶然会发现
PX qref latch<
/p>
等待事件，当系统高峰期同时采用了高并发的情
31
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
况下最容易出现。看来要进行特殊照顾了。
概念和原理
在并行执行环境中，
query slaves
和
query coordinator
之间是通过队列交换数据和信息的。
PX qref latch
是用来保护这些队列的。
PX
qref latch
等待事件的出现一般表明信息的发送比接受快，这时需要调整<
/p>
buffer size
（可
以通过
parallel_execution_message_size
参数调整）。
但是有些情况下也是难以避免发生这种情况的
，比如
consumer
需要长时间的等待数据的处理，
原因在于需要返回大批量的数据包，这种情况下很正常。
调整和措施
当系统的负载比较高时，
需要把并行度降低；如果使用的是默认并行度，可以通过减小
parallel_thr
ead_per_cpu
参数的值来达到效果。
DEFAULT degree =
PARALLEL_THREADS_PER_CPU * #CPU's
优化
parallel_execution_message_siz
e
参数
Tuning
parallel_execution_message_size is a tradeoff
between
performance and
memory. For parallel query, the
connection
topology between
slaves and QC requires (n^2 + 2n)
connections
(where n is the
DOP not the actual number of slaves) at maximum.
If each connection has 3
buffers associated with it then you can
very quickly get into high memory
consumption on large machines
doing high DOP queries
enq: MD - contention
latch: KCL gc element parent
latch
enq: JS - job run lock
- synchronize
SQL*Net more
data to client
latch: cache
buffers lru chain
enq: UL -
contention
gc current
split
enq: AF - task
serialization
latch: object
queue header operation
latch: cache buffers chains
2
11
1
16
1
1
1
1
3
1
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
32
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
latch: enqueue hash chains
SQL*Net message from client
2
1,544,11
3
0
12,626
0
8
gcs remote
message
DIAG idle
wait
ges remote
message
Streams AQ: qmn
slave idle wait
Streams AQ:
qmn coordinator idle wait
Streams
AQ:
waiting
for
messages
in
the
queue
virtual
circuit status
PX Idle
Wait
jobq slave
wait
Streams AQ: waiting for
time management or
cleanup
tasks
PX Deq: Parse
Reply
PX Deq: Execution
Msg
PX Deq: Join
ACK
PX Deq: Execute
Reply
PX Deq: Msg
Fragment
Streams AQ: RAC qmn
coordinator idle wait
class
slave wait
634,884
23,628
149,591
167
351
488
157
1,072
145
1
9,203
4,616
4,612
4,611
4,611
4,605
4,596
2,581
420
270
14
195
31
27611
13137
9436
29272
2407
2896
269747
40
121
38
34
16
351
2
0
0
0
0
0
0
0
3
0
1
0
0
0
0
db
file scattered read
等待事件是当
SES
SION
等待
multi-block
I/O
时发
生的，通过是由于
full
table scans
或
index fast full
scans
。发生过多读
操作的
Seg
ments
可以在“Segments by Physical
Reads”和
“SQL ordered by
Reads”节中识别（在其它版本的报告中，可能是别的名称）。如果在
OLTP
应用
中，不应该有过多的全扫描操作，而应使用选择
性好的索引操作。
DB file sequential
read
等待意味着发生顺序
I/O
读
等待（通常是单块读取
到连续的内存区域中）
，
如果这个等待非常严重，
应该使用上一段的方法确定执
行读操作的热点
SEGMENT
，然后通过对大表进行分区以减
少
I/O
量，或者优化执
行计划（通过
使用存储大纲或执行数据分析）以避免单块读操作引起的
33
深
圳博睿同创信息技术有限公司
v1.0
可编辑可修改
sequential
read
等待。通过在批量应用中，
DB file
sequential read
是很影
响性能的事件，总是应
当设法避免。
Log File Parallel
Write
事件是在等待
LGWR
进
程将
REDO
记录从
LOG
缓冲
区写到联机日志文件时发生的。虽然写操作可能是并发的，但
LGWR
需要等待最
后的
I/O
写到磁盘上才能认为并行写的完成，因此等待时间依赖于
OS
完成所有
请求的时间。
如果这
个等待比较严重，
可以通过将
LOG
文
件移到更快的磁盘上或
者条带化磁盘（减少争用）而降低这个等待。
Buffer Busy Waits
事件是在一个
SESSION
需要访问
BUFFER C
ACHE
中的一个
数据库块而又不能访问时发生的。缓冲区“<
/p>
busy
”的两个原因是：
1
）另一个
SESSION
正在将数据块读进
BUFFER
。
2
）
另一个
SESSION
正在以排它模式占用着
< br>这块被请求的
BUFFER
。可以在“
< br>Segments by Buffer Busy Waits
”一节中找出<
/p>
发生这种等待的
SEGMENT
，然后通
过使用
reverse-key
indexes
并对热表进行分
区而减少这种等待事件。
Log
File
Sync
事件，当用户
SESSION
执行事务操作（<
/p>
COMMIT
或
ROLLBACK
等）
后，会通知
LGWR
< br>进程将所需要的所有
REDO
信息从
LOG BUFFER
写到
LOG
文件，
在用户
SESSION
等待
LGWR
返回安全写入磁盘的通知时发生此等待。减少此等待
的方法写
Log File Parallel
Write
事件的处理。
Enqueue
Waits
是串行访
问本地资源的本锁，
表明正在等待一个被其它
SESSION<
/p>
（一个或多个）
以排它模式锁住的资源。
减少这种等待的方法依赖于生产等待的
锁类型。导致
Enque
ue
等待的主要锁类型有三种：
TX
（
事务锁）
, TM D
（
ML
锁）
和
ST
（空间管理
锁）。
Back to Wait Events
Statistics
Back to
Top
Background Wait
Events
ordered
by wait time desc, waits desc (idle events last)
34
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
%Time
Event
Waits
-outs
log file
parallel write
db file
parallel write
events in
waitclass Other
control file
sequential read
control file
parallel write
os thread
startup
direct path
read
db file sequential
read
direct path
write
log file sequential
read
gc cr block
2-way
gc current block
2-way
log buffer
space
row cache
lock
log file single
write
buffer busy
waits
gc current grant
busy
5,497
4,806
69,002
9,323
1,946
18
138
21
138
36
96
78
11
59
36
151
29
(s)
47
34
22
7
3
2
0
0
0
0
0
0
0
0
0
0
0
(ms)
9
7
0
1
1
89
1
5
0
2
0
0
2
0
0
0
0
/txn
Total
Wait Time
Avg wait
Waits
35
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
library cache lock
enq: TM - contention
gc current grant 2-way
gc cr multi block request
gc cr grant 2-way
rdbms ipc message
gcs remote message
DIAG idle wait
pmon timer
ges
remote message
Streams AQ:
qmn slave idle wait
Streams
AQ: qmn coordinator idle wait
smon timer
Streams AQ: waiting for time management
or
cleanup tasks
PX Deq: Parse Reply
PX Deq: Join ACK
PX Deq: Execute Reply
Streams AQ: RAC qmn coordinator idle
wait
4
10
8
7
5
97,288
634,886
23,628
1,621
149,591
167
351
277
1
0
0
0
0
0
50,194
9,203
4,616
4,615
4,612
4,611
4,611
4,531
270
1
0
0
0
0
516
14
195
2847
31
27611
13137
16356
269747
40
38
34
351
0
0
0
0
3
1
0
0
Back to Wait
Events Statistics
Back to
Top
Operating System
Statistics
Statistic
NUM_LCPUS
NUM_VCPUS
AVG_BUSY_TIME
AVG_IDLE_TIME
AVG_IOWAIT_TIME
AVG_SYS_TIME
Total
0
0
101,442
371,241
5,460
25,795
36
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
AVG_USER_TIME
BUSY_TIME
IDLE_TIME
IOWAIT_TIME
SYS_TIME
USER_TIME
LOAD
OS_CPU_WAIT_TIME
RSRC_MGR_CPU_WAIT_TIME
PHYSICAL_MEMORY_BYTES
75,510
812,644
2,971,077
44,794
207,429
605,215
0
854,100
0
8,589,934,59
2
NUM_CPUS
NUM_CPU_CORES
8
4
NUM_LCPUS
：
NUM_VCPUS
：
如果显示
0
，是因为没有设置
LPARS
同上。
BUSY_TIME / NUM_CPUS
IDLE_TIME / NUM_CPUS
IOWAIT_TIME / NUM_CPUS
SYS_TIME /
NUM_CPUS
AVG_BUSY_TIME
：
AVG_IDLE_TIME
：
AVG_IOWAIT_TIME
：
AVG_SYS_TIME
：
AVG_USER_TIME
：
BUSY_TIME
：
IDLE_TIME
：
USER_TIME / NUM_CPUSar o
time equiv of
%usr+%sys in sar output
time
equiv of %idle in sar
IOWAIT_TIME
：
SYS_TIME
：
USER_TIME
：
LOAD
：
time equiv of %wio in sar
time equiv of %sys in sar
time equiv of %usr in
sar
未知
supposedly time waiting on run
queues
OS_CPU_WAIT_TIME
：
RSRC_MGR_CPU_WAIT_TIME
：
time waited coz of resource
manager
PHYSICAL_MEMORY_BYTE
S
：
total memory
in use supposedly
37
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
NUM_CPUS
：
number of CPUs reported by OS
操作系统
CPU
数
number of CPU sockets on motherboard
主板上
CPU
NUM_CPU_CORES
：
插槽数
总的
elapsed
time
也可以用以公式计算：
BUSY_TIME + IDLE_TIME + IOWAIT
TIME
或：
SYS_TIME +
USER_TIME + IDLE_TIME + IOWAIT_TIME
（因为
BUSY_TIME =
SYS_TIME+USER_TIME
）
Back to Wait Events
Statistics
Back to
Top
Service
Statistics
ordered by DB Time
Service Name
ICCI
SYS$$USERS
ICCIXDB
SYS$$BACKGROUND
DB
Time (s)
DB CPU
(s)
Physical Reads
315,849
6,539
0
282
Logical Reads
16,550,972
58,929
0
38,990
Back to
Wait Events Statistics
Back
to Top
Service Wait Class
Stats
Wait Class
info for services in the Service Statistics
section.
Total
Waits and Time Waited displayed for the following
wait classes: User I/O, Concurrency,
Administrative, Network
Time Waited (Wt Time) in
centisecond (100th of a second)
Service Name
User
User
Concurcy
Concurcy
Admin
Admin
Network
Network
38
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
I/O
Total
Wts
ICCI
SYS$$USERS
SYS$$BACKGROUND
59826
6567
443
I/O Wt
Time
Total
Wts
Wt Time
Total
Wts
Wt Time
Total
Wts
Wt Time
8640
3238
115
4621
231
330
338
11
168
0
0
0
0
0
0
1564059
7323
0
6552
3
0
Back to Wait
Events Statistics
Back to
Top
SQL Statistics
v$$sqlarea
SQL
ordered by Elapsed Time
SQL ordered by CPU Time
SQL ordered by Gets
SQL ordered by
Reads
SQL
ordered by Executions
SQL ordered by Parse Calls
SQL ordered by Sharable
Memory
SQL
ordered by Version Count
SQL ordered by Cluster Wait Time
Complete List
of SQL Text
本节按各种资源分别列出对资源消
耗最严重的
SQL
语句，
并显示它们所
占统计
期内全部资源的比例，这给出我们调优指南。例如在一个系统中，
CPU
资源是系
统性能瓶颈所在，那么优化
buffer
gets
最多的
< br>SQL
语句将获得最大效果。在一
个
I/O
等待是最严重事件的系统中，
调优的目标应该是
physical
IOs
最多的
SQL
语句。
在
STATSPACK
报告中，没有完整的
S
QL
语句，可使用报告中的
Hash Value
通
过下面语句从数据库中查到：
select sql_text
from stats$$sqltext
39
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
where hash_value =
&hash_value
order by
piece;
Back to
Top
SQL ordered by Elapsed
Time
Resources
reported
for
PL/SQL
code
includes
the
resources
used
by
all
SQL
statements
called
by
the
code.
% Total DB Time
is the Elapsed Time of the SQL statement divided
into the Total Database Time
multiplied
by 100
Elap
Elapsed
CPU
Execution
Time
(s)
Time
s
(s)
per
%
Tota
SQL Id
SQL Module
SQL
Text
Exec
l DB
(s)
Time
93
57
1
d8z0u8hgj8xdy
cuidmain@HPGICCI1 (TNS
insert into CUID select
V1-V3)
CUID_...
insert
into ICCICCS
values (:...
76
75
172,329
4vja2k2gdtyup
load_fnsact@HPGICCI1
(TNS
V1-V3)
58
42
1
569r5k05drsj7
cumimain@HPGICCI1 (TNS
insert into CUMI select
V1-V3)
CUSV_...
51
42
1
ackxqhnktxnbc
cusmmain@HPGICCI1 (TNS
insert into CUSM select
V1-V3)
CUSM_...
select ,
from co...
SELECT ,
TO_...
insert into
iccifnsact
values...
DECLARE job
BINARY_INTEGER
:= ...
38
35
23
36
3
23
166,069
1
172,329
7gtztzv329wg0
6z06gcfw39pkd
1dm3bq36vu3g8
SQL*Plus
load_fnsact@HPGICCI1
(TNS V1-V3)
15
11
5
djs2w2f17nw2z
14
14
172,983
7wwv1ybs9zguz
load_fnsact@HPGICCI1
(TNS
V1-V3)
update ICCIFNSACT
set
BORM_AD...
13
13
172,337
gmn2w09rdxn14
load_oldnewact@HPGICCI1
insert into OLDNEWACT
(TNS
V1-V3)
values
...
insert into ICCICCS
values (:...
13
13
166,051
chjmy0dxf9mbj
icci_migact@HPGICCI1
(TNS
V1-V3)
10
4
1
0yv9t4qb1zb2b
cuidmain@HPGICCI1 (TNS
select CUID_CUST_NO ,
40
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
V1-V3)
10
8
5
1crajpb7j5tyz
CUID_ID_...
INSERT INTO
STATS$$SGA_TARGET_A...
8
8
172,329
38apjgr0p55ns
load_fnsact@HPGICCI1
(TNS
V1-V3)
update ICCICCS set
CCSMAXOVER...
select * from
ICCIPRODCODE
wh...
8
8
172,983
5c4qu2zmj3gux
load_fnsact@HPGICCI1
(TNS
V1-V3)
Back to SQL
Statistics
Back to
Top
SQL ordered by CPU
Time
Resources
reported
for
PL/SQL
code
includes
the
resources
used
by
all
SQL
statements
called
by
the
code.
% Total DB Time
is the Elapsed Time of the SQL statement divided
into the Total Database Time
multiplied
by 100
CPU
CPU
Elapsed
Execution
Time
(s)
Time
s
(s)
(s)
75
76
172,329
per
%
Tota
SQL Id
SQL Module
SQL
Text
Exec
l DB
Time
4vja2k2gdtyup
load_fnsact@HPGICCI1
(TNS
V1-V3)
insert into ICCICCS
values (:...
57
93
1
d8z0u8hgj8xdy
cuidmain@HPGICCI1 (TNS
insert into CUID select
V1-V3)
CUID_...
42
51
1
ackxqhnktxnbc
cusmmain@HPGICCI1 (TNS
insert into CUSM select
V1-V3)
CUSM_...
42
58
1
569r5k05drsj7
cumimain@HPGICCI1 (TNS
insert into CUMI select
V1-V3)
CUSV_...
select ,
from co...
insert into
iccifnsact
values...
update ICCIFNSACT set
BORM_AD...
36
23
38
23
166,069
172,329
7gtztzv329wg0
1dm3bq36vu3g8
load_fnsact@HPGICCI1
(TNS
V1-V3)
14
14
172,983
7wwv1ybs9zguz
load_fnsact@HPGICCI1
(TNS
V1-V3)
41
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
13
13
172,337
gmn2w09rdxn14
load_oldnewact@HPGICCI1
insert into OLDNEWACT
(TNS
V1-V3)
values
...
insert into ICCICCS
values (:...
DECLARE job
BINARY_INTEGER
:= ...
13
13
166,051
chjmy0dxf9mbj
icci_migact@HPGICCI1
(TNS
V1-V3)
11
15
5
djs2w2f17nw2z
8
8
172,329
38apjgr0p55ns
load_fnsact@HPGICCI1
(TNS
V1-V3)
update ICCICCS set
CCSMAXOVER...
INSERT INTO
STATS$$SGA_TARGET_A...
8
10
5
1crajpb7j5tyz
8
8
172,983
5c4qu2zmj3gux
load_fnsact@HPGICCI1
(TNS
V1-V3)
select * from
ICCIPRODCODE wh...
4
10
1
0yv9t4qb1zb2b
cuidmain@HPGICCI1 (TNS
select CUID_CUST_NO ,
V1-V3)
CUID_ID_...
SELECT , TO_...
3
35
1
6z06gcfw39pkd
SQL*Plus
Back to
SQL Statistics
Back to
Top
SQL ordered by
Gets
Resources
reported
for
PL/SQL
code
includes
the
resources
used
by
all
SQL
statements
called
by
the
code.
Total Buffer
Gets: 16,648,792
Captured SQL account for % of Total
这一部分，通过
Buffer Ge
ts
对
SQL
语句进行排序，即通过它
执行了多少个逻辑
I/O
来排序。顶端的
注释表明一个
PL/SQL
单元的缓存获得
< br>(Buffer Gets)
包括被这个代码块执行的所有
SQL
语句的
Buffer
Get
s
。
因此将经常在这个列表的顶端看到
PL/SQL
过程，
因为存储过程执行的单独的语句的数目被总
计
出来。在这里的
Buffer
Ge
ts
是一个累积值，所以这个值大并不一定意味着这条语句的性能存在问题。
通常我们可以通过对比该条语句的
Buffer
Gets
和
physical
reads
值，如果这两个比较接近，肯定这
条语句是存在问题的，我们可以通过执行计划来分析，为什么
physical rea
ds
的值如此之高。另外，
我们在这里也可以关注
gets per exec
的值，这个值如果太大，表明这条语句可能使用
了一个比较差
的索引或者使用了不当的表连接。
42
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
另外说明一点：
大量的逻辑读往往伴随着较高的
C
PU
消耗。
所以很多时候我们看到的系统
CPU
将近
100
％
的时候，很多时候就是
SQL
语句造成的，这时候我们
可以分析一下这里逻辑读大的
SQL
。
select * from
(select
substr(sql_text,1,40) sql,
buffer_gets,
executions,
buffer_gets/executions
hash_value,address
from v$$sqlarea
where buffer_gets > 0 and
executions>0
order by buffer_gets desc)
where rownum <= 10
CPU
Elapse
Buffer
Executio
Gets
ns
Gets per
%Tota
Exec
l
Tim
d
Time
e
(s)
(s)
3,305,3
63
172,329
4vja2k2gdtyup
load_fnsact@HPGICCI1
insert
into
(TNS V1-V3)
ICCICCS
values
(:...
2,064,4
14
1
2,064,
d8z0u8hgj8xdy
cuidmain@HPGICCI1
(TNS
insert into
V1-V3)
CUID select
CUID_...
1,826,8
69
1,427,6
48
172,337
166,069
7gtztzv329wg0
select
, from
co...
gmn2w09rdxn14
load_oldnewact@HPGICC
insert
into
I1 (TNS V1-V3)
OLDNEWACT
values
...
1,278,6
67
172,329
1dm3bq36vu3g8
load_fnsact@HPGICCI1
insert
into
(TNS V1-V3)
iccifnsact
values...
1,216,3
1
1,216,
ackxqhnktxnbc
cusmmain@HPGICCI1
(TNS
insert into
SQL Id
SQL Module
SQL
Text
43
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
67
V1-V3)
CUSM select
CUSM_...
1,107,3
05
1
1,107,
569r5k05drsj7
cumimain@HPGICCI1
(TNS
insert into
V1-V3)
CUMI select
CUSV_...
898,868
172,983
7wwv1ybs9zguz
load_fnsact@HPGICCI1
update
(TNS V1-V3)
ICCIFNSACT
set
BORM_AD...
711,450
166,051
chjmy0dxf9mbj
icci_migact@HPGICCI1
insert
into
(TNS V1-V3)
ICCICCS
values
(:...
692,996
172,329
38apjgr0p55ns
load_fnsact@HPGICCI1
update
ICCICCS
(TNS V1-V3)
set
CCSMAXOVER...
666,748
166,052
7v9dyf5r424yh
icci_migact@HPGICCI1
select
(TNS V1-V3)
NEWACTNO
into :b0
from...
345,357
172,983
5c4qu2zmj3gux
load_fnsact@HPGICCI1
select
* from
(TNS V1-V3)
ICCIPRODCODE
wh...
231,756
51,633
49ms69srnaxzj
load_fnsact@HPGICCI1
insert
into
(TNS V1-V3)
ICCIRPYV
values
(...
Back to SQL
Statistics
Back to
Top
SQL ordered by
Reads
Total Disk
Reads: 322,678
Captured SQL account for % of Total
这部分通过物理读对
SQL
语句进行排序。这显示引起大部分对这个系统进行读取活动的
SQL
，即物理
I/O
。当我们的系统如果存在<
/p>
I/O
瓶颈时，需要关注这里
I/O
操作比较多的语句。
select *
from
44
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
(select
substr(sql_text,1,40) sql, disk_reads,
executions, disk_reads/executions
hash_value,address
from
v$$sqlarea
where disk_reads > 0 and executions >0
where rownum <=
10;
order by disk_reads
desc)
CPU
Physic
Executio
al
ns
Reads
Exec
(s)
66,286
1
66,
d8z0u8hgj8xdy
cuidmain@HPGICCI1
insert
into CUID
(TNS V1-V3)
50,646
1
50,
select
CUID_...
per
l
e
(s)
Reads
%Tota
Tim
d Time
SQL Id
SQL
Module
SQL Text
Elapse
0yv9t4qb1zb2b
cuidmain@HPGICCI1
select
CUID_CUST_NO ,
(TNS V1-V3)
CUID_ID_...
24,507
1
24,
569r5k05drsj7
cumimain@HPGICCI1
insert
into CUMI
(TNS V1-V3)
select CUSV_...
21,893
1
21,
ackxqhnktxnbc
cusmmain@HPGICCI1
insert
into CUSM
(TNS V1-V3)
select CUSM_...
19,761
1
19,
a7nh7j8zmfrzw
cumimain@HPGICCI1
select
CUSV_CUST_NO
(TNS V1-V3)
from CUMI...
select count(*) from
CUSVAA_T...
19,554
1
19,
38gak8u2qm11w
SQL*Plus
6,342
4,385
1
1
6,
4,
6z06gcfw39pkd
SQL*Plus
SELECT
, TO_...
cp5duhcsj72q0
cusmmain@HPGICCI1
select
(TNS V1-V3)
CUSM_CUST_ACCT_NO
from...
63
5
djs2w2f17nw2z
DECLARE job
BINARY_INTEGER := ...
35
1
1uk5m5qbzj1vt
SQL*Plus
BEGIN <
/p>
dbms_workload_reposit
ory...
Back to SQL
Statistics
45
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
Back to Top
SQL
ordered by Executions
Total Executions: 1,675,112
Captured SQL account for %
of Total
这部分告诉我们在这段时间中执行次数最
多的
SQL
语句。为了隔离某些频繁执行的查询，以观察是否<
/p>
有某些更改逻辑的方法以避免必须如此频繁的执行这些查询，这可能是很有用的。或许一个
查询正在
一个循环的内部执行，而且它可能在循环的外部执行一次，可以设计简单的算法
更改以减少必须执行
这个查询的次数。即使它运行的飞快，任何被执行几百万次的操作都
将开始耗尽大量的时间。
select * from
(select substr(sql_text,1,40) sql,
executions,
rows_processed,
rows_processed/executions
CPU
Rows
Rows
Executions
Processed
Exec
(s)
172,983
172,329
(s)
5c4qu2zmj3gux
load_fnsact@HPGICCI1 (TNS
select * from
V1-V3)
ICCIPRODCODE
wh...
172,983
172,329
7wwv1ybs9zguz
load_fnsact@HPGICCI1 (TNS
update
V1-V3)
ICCIFNSACT set
BORM_AD...
172,337
172,337
gmn2w09rdxn14
load_oldnewact@HPGICCI1
(TNS
V1-V3)
insert into
OLDNEWACT
values
...
172,329
172,329
1dm3bq36vu3g8
load_fnsact@HPGICCI1 (TNS
insert into
V1-V3)
iccifnsact
values...
per
Exec
Exec
per
per
SQL Id
SQL Module
SQL
Text
Elap
hash_value,address
from
v$$sqlarea
where executions > 0
where rownum <= 10
order by executions desc)
46
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
172,329
172,329
38apjgr0p55ns
load_fnsact@HPGICCI1 (TNS
update ICCICCS
V1-V3)
set
CCSMAXOVER...
172,329
6,286
4vja2k2gdtyup
load_fnsact@HPGICCI1 (TNS
insert into
V1-V3)
ICCICCS values
(:...
166,069
166,069
7gtztzv329wg0
select , from
co...
166,052
166,052
7v9dyf5r424yh
icci_migact@HPGICCI1 (TNS
select NEWACTNO
V1-V3)
into :b0 from...
166,051
166,051
chjmy0dxf9mbj
icci_migact@HPGICCI1 (TNS
insert into
V1-V3)
ICCICCS values
(:...
51,740
51,740
bu8tnqr3xv25q
load_fnsact@HPGICCI1 (TNS
select count(*)
V1-V3)
into :b0 fro...
51,633
51,633
49ms69srnaxzj
load_fnsact@HPGICCI1 (TNS
insert into
V1-V3)
ICCIRPYV values
(...
Back to SQL
Statistics
Back to
Top
SQL ordered by Parse
Calls
Total
Parse Calls: 182,780
Captured SQL account for % of Total
在这一部分，主要显示
PARSE<
/p>
与
EXECUTIONS
的对比情况。如
果
PARSE/EXECUTIONS>1
，往往说明这个
语句可能存在问题：没有使用绑定变量，共享池设置太小，
curs
or_sharing
被设置为
exact
，没有设
置
session_cached_cursor
s
等等问题。
select *
from
(select substr(sql_text,1,40) sql,
parse_calls,
executions,
hash_value,address
from
v$$sqlarea
where
parse_calls > 0
47
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
Parse
order by parse_calls desc)
where rownum <= 10
Executions
%
Total
Parses
Calls
166,069
6,304
2,437
1,568
1,554
444
421
421
86
81
166,069
6,304
2,438
1,568
1,554
444
421
421
86
81
SQL
Id
SQL Module
SQL Text
7gtztzv329wg0
2ym6hhaq30r73
bsa0wjtftg3uw
9qgtwh66xg6nz
aq4js2gkfjru8
104pd9mm3fh9p
350f5yrnnmshs
g00cj285jmgsw
3m8smr0v7v1m6
f80h0xb1qvbsk
select , from
co...
select type#, blocks,
extents,...
select file#
from file$$ where ...
update
seg$$ set type#=:4, bloc...
update tsq$$ set blocks=:3,
max...
select blocks,
maxblocks, gran...
lock
table $$ in ex...
update $$
set inser...
INSERT INTO
$$_adv_messa...
SELECT
$$_adv_seq_msggro...
Back to
SQL Statistics
Back to
Top
SQL ordered by Sharable
Memory
No data exists for
this section of the report.
在这一部分，主要是针对
shared
memory
占用的情况进行排序。
select * from
(select
substr(sql_text,1,40) sql, sharable_mem,
executions,
hash_value,address
48
深圳博睿同创信息技术有限公司
from
v$$sqlarea
where sharable_mem >
1048576
order by sharable_mem desc)
where rownum <= 10;
v1.0
可编辑可修改
Back to SQL Statistics
Back to Top
Running Time top 10 sql
select * from
(select ,
,'yyyy-mm-dd
hh24:mi:ss'))*24*60,
disk_reads,buffer_gets,rows_processed,
,,
from
v$$sqlarea
t
order by desc)
where rownum < 10;
SQL ordered by
Version Count
No data exists
for this section of the report.
在这一部分，主要是针对
SQL
语句的多版本进行排
序。相同的
SQL
文本，但是不同属性，比如对象
owner
不同，会话优化模式不同、类型不同、长度不同和绑定变量不同等
等的语句，他们是不能共享的，所以再
缓存中会存在多个不同的版本。这当然就造成了资
源上的更多的消耗。
Back to SQL
Statistics
Back to
Top
SQL ordered by Cluster
Wait Time
Clust
CWT %
Elapse
er
of
Wait
Elaps
Time
d
Time
(s)
1
d8z0u8hgj8xdy
cuidmain@HPGICCI1 (TNS insert
into
CUID
select
)
Time(s
)
d
Time(s
s
CPU
Execution
SQL
Id
SQL Module
SQL Text
49
深圳博睿同创信息技术有限公司
v1.0
可编辑可修改
V1-V3)
CUID_...
1
569r5k05drsj7
cumimain@HPGICCI1 (TNS
insert
into
CUMI
select
V1-V3)
CUSV_...
1
ackxqhnktxnbc
cusmmain@HPGICCI1 (TNS
insert
into
CUSM
select
V1-V3)
CUSM_...
select ,
from co...
166,069
7gtztzv329wg0
172,329
4vja2k2gdtyup
load_fnsact@HPGICCI1
insert
into ICCICCS
(TNS V1-V3)
values (:...
1
0yv9t4qb1zb2b
cuidmain@HPGICCI1 (TNS
select CUID_CUST_NO ,
V1-V3)
CUID_ID_...
SELECT , TO_...
1
6z06gcfw39pkd
SQL*Plus
1
a7nh7j8zmfrzw
cumimain@HPGICCI1 (TNS
select CUSV_CUST_NO
V1-V3)
from CUMI...
select blocks,
maxblocks,
gran...
444
104pd9mm3fh9p
1
38gak8u2qm11w
SQL*Plus
select
count(*) from
CUSVAA_T...
1,554
aq4js2gkfjru8
update tsq$$ set
blocks=:3, max...
187
04xtrk7uyhknh
select obj#,
type#,
ctime, mti...
172,337
gmn2w09rdxn14
load_oldnewact@HPGICC
insert
into OLDNEWACT
I1 (TNS V1-V3)
values ...
172,329
1dm3bq36vu3g8
load_fnsact@HPGICCI1
insert
into iccifnsact
(TNS V1-V3)
values...
1
cp5duhcsj72q0
cusmmain@HPGICCI1 (TNS
select
V1-V3)
CUSM_CUST_ACCT_NO
from...
1,568
9qgtwh66xg6nz
update seg$$ set
type#=:4, bloc...
51,633
49ms69srnaxzj
load_fnsact@HPGICCI1
insert
into ICCIRPYV
(TNS V1-V3)
values (...
166,051
chjmy0dxf9mbj
icci_migact@HPGICCI1
insert
into ICCICCS
(TNS V1-V3)
values (:...
BEGIN BEGIN IF ...
39
cn1gtsav2d5jh
cusvaamain@HPGICCI1
50
深圳博睿同创信息技术有限公司
费雷德-冷镦钢
费雷德-冷镦钢
费雷德-冷镦钢
费雷德-冷镦钢
费雷德-冷镦钢
费雷德-冷镦钢
费雷德-冷镦钢
费雷德-冷镦钢
-
上一篇：有限元分析中英文对照资料
下一篇：2020年上海市闵行区高考英语二模试卷