2008/05/05
skate
重做日志缓冲区优化
学习目标: 监视和确定重做日志缓冲区的大小
1.重做日志缓冲区的内容
A. 对于每个dml或ddl语句,oracle服务器进程都会用户内存空间的重做条目复制到重做日志缓冲区上
B. 重做条目包含用于重做或重构dml或ddl操作对数据库所做更改的所需的信息,用于恢复数据库,并
占据日志缓冲区的连续的有序的空间
2.那缓冲区满了,该怎么办呢?,这就需要lgwr进程来行动了
A. lgwr进程负责把重做日志缓冲区的内容写到磁盘上的活动的联机重做日志文件(或活动组的成员),他写入
自上次写入后的所有复制到缓冲区的条目
B. 重做日志缓冲区是一个循环的缓冲区,oracle服务器进程负责把重做的条目覆盖重做日志缓冲区的已经写入磁盘的
条目,lgwr的写入速度是非常快的,以确保重做日志缓冲区总有写入新条目的空间
3.lgwr什么时候开始空工作的,他要有触发他的动作阿
A. 重做日志缓冲区的已使用的空间达到三分之一时
B. 当dbwn进程向磁盘写入已修改的缓冲区的时候
C. 每隔3秒钟
D. 用户提交事务处理时的一条提交记录(经常commit会及时刷新重做日志缓冲区空间)
4. 知道了一些原理, 下面开始讨论重做日志缓冲区的大小及调节和优化
A. 日志缓冲区的大小 log_buffer,默认值为512k或128*cpu_count ,取较大的一个值
B. 增大log_buffer值可以降低日志文件文件的i/o,缓冲区太小很容易达到已用空间的3/1
C. 频繁commit将清空日志缓冲区
重做日志缓冲区的诊断: 服务器进程可能向重做日志缓冲区请求写入新条目的空间,但未能找到,这时候将不得不
等待lgwr将日志缓冲区刷新到磁盘
优化的目标: 确保服务器进程在重做日志缓冲区中有充足的空间,但是过大的空间将减少分配给其他区域的内存量
我们知道了优化的目标,知道了我要做什么,下面就是确定日志缓冲区的效率,通过一些动态性能视图
v$session_wait 日志缓冲区空间
v$sysstat 重做日志缓冲区再分配重做条目
1. 重做日志缓冲区空间等待
sql> select sid,event,seconds_in_wait,state from v$session_wait where event='log buffer space'
2. 重做日志缓冲区再分配的统计
sql> select r.value "entries" ,
e.value "allocation retries" ,
e.value/(r.value + e.value) "pct"
from v$sysstat r,v$sysstat e
where r.name='redo entries'
and e.name='redo buffer allocation retries'
entries allocation retries pct
---------- ------------------ ----------
1776124 312 .000175633
1 row selected.
重做缓冲区再分配的值应为0,此数值应不大于重做条目的1%,如果这个比例持续增加,则进程将不得不等待日志
缓冲区空间
通过v$session_wait我们检测到等待了,那是什么原因引起的呢,如何解决呢?
引起的原因:日志缓冲区太小,检查点操作或归档操作造成
解决方法: 1可以增加log_buffer的大小
2 改进检查点和归档进程
3 将日志文件放到更快的磁盘上
数据库应该设置多少个重做日志文件和其大小阿?
lgwr释放日志缓冲区空间缓慢的原因
查询视图v$system_event
log file switch completion 由于日志文件切换而等待的次数
log file switch (checkpoint incomplete) 由于未完成检查点而引起的日志切换等待的次数
log file switch (arch%) 由于归档问题而引起的日志文件切换等待的次数
日志切换的频率的检查方法:
1.查询视图v$log_history
select * from v$log_history
2.直接去观察alter_sid文件
建议切换联机重做日志的频率不要小于5分钟,如果高过这个频率就要扩大日至组的大小,倾向于
在安静的条件下切换频率超过每小时一次,在调整redo日志文件的时候,要随时观察alter.log文件
查看是否有"checkpoint not complete",如果看到了可以增加日志组的容量
先总结到这吧
----end ---