Cache buffer latches
的形成原因分析
当一个数据块被读入
SGA.
这些数据块所在缓冲区的头地址
(buffer headers)
被挂载到链列表上
(LRU, LRUW).
这些连列表被挂载在
hash buckets
上
. Oracle
定义了一些
cache buffer chains latches
来保护这种内存结构的数据一致性读取
.
如下表所示
.
一个进程在对数据块执行
add, remove, search, inspect, read
或者
modify
之前需要首先获得
cache buffers chains latch.
有两条规则跟
oracle
访问数据块时的
cache buffers chains
相关
.
l
每一个
logical read
都会造成一个
latch
和
cpu
时间
.
l
Oracle
必须获得期望的
latch
才能执行下一个步骤
.
不够优化的
SQL
语句是导致
cache buffers chains latch
的主要原因。如果
SQL
语句需要访问过多的内存数据块,那么必然会持有
latch
很长时间。找出逻辑读特别大的
sql
语句进行调整。
还有一个原因可能会引起
cache buffers chains latch
,就是热点数据块问题。这是指多个
session
重复访问一个或多个被同一个
child cache buffers chains latch
保护的内存数据块。这主要是应用程序的问题。大多数情况下,单纯增加
child cache buffers chains latches
的个数对提高性能没有作用。这是因为内存数据块是根据数据块地址以及
hash chain
的个数来进行
hash
运算从而得到具体的
hash chain
的,而不是根据
child cache buffers chains latches
的个数。如果数据块的地址以及
hash chain
的个数保持一致,那么热点块仍然很有可能会被
hash
到同一个
child cache buffers chains latch
上。可以通过
v$session_wait
的
p1raw
字段来判断
latch free
等待事件是否是由于出现了热点块。如果
p1raw
保持一致,那么说明
session
在等待同一个
latch
地址,系统存在热点块。当然也可以通过
x$bh
的
tch
来判断是否出现了热点块,该值越高则数据块越热。
对于一些大型的数据库系统来说
, hash chains
可能会较长
,
比如每个
hash chains
上可能会有上百个数据块
.
这也可能是造成性能问题的一个重要原因
.
1,
考虑
10
个相同的查询语句同时开始执行查询同一个
hash latch(L1)
中的第一个数据块
.
A,
在第一个
cpu
时间
, session1
获得
latch L1,
其他
session
获取失败
.
B,
在第二个
cpu
时间
,
假设
sesson1
已经完成
, L1
被
session2
获得
,
其他
session
获取失败
.
C, ….
D,
在第
n
个
cpu
时间
,
前
n
个
session
获得
latch
成功
,
剩余
10-n
个
session
获取失败
.
E…
F,
在第十个
cpu
时间里
, session10
获得
L1
成功
.
在上述的描述过程中
, session N
的等待时间可以用下面的公式描述
.
WaitTime(n) = (n-1) *
单位
cpu
时间
.
2,
考虑
10
个相同的查询语句同时开始执行查询同一个
hash latch(L1)
中的最后一个数据块
.
A,
在第一个
cpu
时间
, session1
获得
latch L1,
其他
session
获取失败
.
B,
在第二个
cpu
时间
,
假设
sesson1
已经完成
, L1
被
session2
获得
,
其他
session
获取失败
.
C, ….
D,
在第
n
个
cpu
时间
,
前
n
个
session
获得
latch
成功
,
剩余
10-n
个
session
获取失败
.
E…
F,
在第十个
cpu
时间里
, session10
获得
L1
成功
.
在这里的单位
cpu
时间跟情况
1
下少有不同
.
我们假设遍历一条
chain
的时间为
t1,
则每个
session
的等待时间可以用下述公式描述
.
WaitTime(n) = (n-1) * (
单位
cpu
时间
+t1)
3,
考虑
10
个相同的查询语句同时开始执行查询同一个
hash latch(L1)
中的最后一个数据块
.
A,
在第一个
cpu
时间
, session1
获得
latch L1,
其他
session
获取失败
.
B,
在第二个
cpu
时间
, session1
由于需要重新获得同一个
latch,
所以也会加入竞争队列
.
我们为了计算方便
,
假设使用一个先进先出的队列处理竞争
,
于是
L1
被
session2
获得
,
其他
session
获取失败
.
C, ….
D,
在第
n
个
cpu
时间
,
前
n
个
session
获得
latch
成功
,
剩余
9
个
session
获取失败
.
E…
F,
在第十个
cpu
时间里
, session10
获得
L1
成功
.
其他获取失败
G,
在第十一个
cpu
时间里
, session1
获得
L1
成功
,
其他获取失败
.
我们依然假设每个
latch
的拥有时间均为单位
cpu
时间
t,
则每个
session
等待的时间变为
.
WaitTime(n) =10 *
单位
cpu
时间
+ (n-1) * (
单位
cpu
时间
+t1)
测试环境建立
1,
创建一个包含
10
个数据块的表
/*
创建数据表
将pctfree
设置为99
主要是为了使每个数据块只有1
条数据
*/
create
table
jax_t1(
FID
varchar2
(
10
),
FName
varchar2
(
400
),
Ftype
varchar2
(
4
)
)
pctfree
99
pctused
1
;
--
插入测试数据
insert
into
jax_t1
select
rownum
,rpad(
rownum
,
400
,
'*'
),
mod
(
rownum
,
2
)
from
dba_objects
where
rownum
<
11
;
--
检查各记录存储的数据块号
select
dbms_rowid.rowid_relative_fno(
rowid
) fileno,
dbms_rowid.rowid_block_number(
rowid
) blockno,
fid,fname,ftype
from
jax_t1;
--
检查各数据块在x$bh
中的存储情况
select
*
from
x$bh
where
file
# = &fileno
and
dbablk
between
&blockno1
and
&blockno2;
--90794
90803
2,
同时打开多个
session,
同时执行下述语句
,
然后到
v$session_wait
中查询结果如下
.
declare
i
integer
;
vid
varchar2
(
400
);
begin
i:=
0
;
loop
exit
when
i >
1000000
;
select
fname
into
vid
from
jax_t1
where
fid =
1
;
i := i+
1
;
end
loop
;
end
;
.
select
a.*
from
v$session_wait a, v$session b
where
a.sid = b.sid
and
b.STATUS =
'ACTIVE'
and
b.
type
<>
'BACKGROUND'
分享到:
相关推荐
如果该 Latch 竞争激烈,可以通过增大 Buffer Cache、修改参数_db_block_lru_latches、使用多缓冲池技术等方法来解决。 Oracle Buffer Cache 是 Oracle 数据库中的一种重要机制,用于提高数据库的性能。通过理解 ...
Latches分为不同类别,如Buffer Cache Latches、Row Cache Latches、Redo Buffer Latches等,每种都有其特定的用途和保护的内存结构。 二、Latch Contention的原因 1. 高并发:当大量并发事务试图访问共享资源时,...
本书深入探讨了Oracle数据库如何有效地使用和管理内存资源,包括共享池(Shared Pool)、数据缓冲区高速缓存(Data Buffer Cache)和重做日志缓冲区(Redo Log Buffer)等内存结构。理解这些内部机制有助于数据库管理员...
然而,单纯增加Buffer Cache的大小并不能解决所有性能问题,因为Buffer Cache的管理机制(如Latches)可能会成为性能瓶颈。此外,Buffer Cache中的数据可能不是最新的,因为它依赖于后台进程DBWR来刷新数据。 为了...
3. 高速缓存管理器(Cache Manager):高速缓存命中率(CacheHit Ratio %)综合了Log Cache、Buffer Cache和Procedure Cache的命中率,若持续低于80%,考虑增加内存。 4. 闩(Latches):平均闩等待时间(Average ...
在Oracle SGA(共享全局区)中,Buffer Cache是数据块被读入的内存区域,也被称作Buffer Cache。如果启用了ASMM(自动共享内存管理),则共享池的一部分可以被标记为KGH:NOALLOC,并映射到Buffer Cache区域。 每个...
1. **调整Buffer Cache**:如果Buffer Hit %低于99%,可以考虑增大Buffer Cache大小,以减少物理读取次数。 2. **优化SQL查询**:硬解析(Hard Parse)较少,但软解析(Soft Parse)仍有优化空间。检查SQL语句,优化...
Latches分为不同种类,如Block Latch用于保护数据块,Buffer Cache Latch用于管理缓冲区缓存,Library Cache Latch则涉及到库缓存的访问。当多个进程同时请求同一latch时,会产生竞争,如果等待时间过长,可能会影响...
**Hang Analysis** 用于分析挂起情况: - **`ALTER SESSION SET EVENTS 'immediate trace name hanganalyze level n'`** ##### 12\. Work Area **Work Area** 命令可以获取Work Area Table的信息: - **`ALTER ...
+ 缓冲区高速缓存命中率(Buffer Cache Hit Ratio %):指在缓冲区高速缓存中找到而不需要从磁盘中读取的页的百分比,值越高越好。 * 缓冲器管理器(Buffer Manager)对象包含的性能计数器: + 读的页/秒(Page ...
常见的 latch 等待如 buffer cache latch、row cache latch 等。 3. **Redo Log Space(重做日志空间)**:当事务需要写入重做日志时,如果日志文件空间不足,会引发等待。确保足够的日志空间并及时归档,可以避免...
- **Buffer Cache(缓冲区缓存)**:讨论如何通过调整缓冲区缓存来改善I/O性能。 #### 三、目标读者群 本书主要面向进行高级性能调优的专业人士和技术人员,特别是那些对Oracle数据库内部机制有深入了解需求的人士...
- **缓冲区高速缓存命中率(Buffer Cache Hit Ratio %)**:这个比例表示在缓冲区中找到数据而不需从磁盘读取的百分比。目标是保持在90%以上,可通过增加内存来提升。 - **读的页/秒(Page Reads/sec)**:此指标衡量...
- `db_block_lru_latches`:数据库块LRU闩锁数量。 - `shared_pool_size`:共享池大小。 - `log_buffer`:日志缓冲区大小。 - `large_pool_size`:大池大小。 - `java_pool_size`:Java池大小。 - `shared_pool_...
第5章“Caches and Copies”关注Oracle的数据缓冲区高速缓存(Buffer Cache)和共享池(Shared Pool),讨论了如何优化内存使用以提高性能。 第6章“Writing and Recovery”讨论了Oracle的数据写入流程,包括检查点...
在启用VLM的情况下,`_DB_BLOCK_LRU_LATCHES`等于`(Max buffer pools * SETS_PER_POOL)`,而`SETS_PER_POOL`则根据是否启用了`USE_INDIRECT_DATA_BUFFERS`而不同: - 如果`USE_INDIRECT_DATA_BUFFERS = TRUE`,...
- **缓冲区高速缓存命中率 (Buffer Cache Hit Ratio%)** - **指标描述**: 表示从缓冲区高速缓存中获取数据而非从磁盘中读取的比例。 - **指标范围**: 0%-100% - **指标单位**: % - **重要性**: 极高 - **参考值...
- **缓冲区高速缓存命中率 (Buffer Cache Hit Ratio %)** - **指标描述**:表示从缓冲区高速缓存中获取数据而非磁盘的百分比。 - **重要性**:较高的缓存命中率意味着大部分数据请求可以直接从内存中获取,减少了...