3. SQL>
4. SQL> select a.ksppinm name,b.ksppstvl value,a.ksppdesc description
5. 2 from x$ksppi a,x$ksppcv b
6. 3 where a.indx = b.indx
7. 4 and a.ksppinm like '%log_io_size%'
8. 5 /
9. NAME VALUE DESCRIPTION
10. --------------- ---------- -----------------------------------------------------------------
---------------
11. _log_io_size 0 automatically initiate log write if this many redo blocks in
buffer
4) 每3秒
5)DWWn写之前写
LGWR写的具体过程:
1)先尝试获取redo writing latch,确保其他process不会继续触发lgwr(这里可能会产生log
file sync等待事件)
2)获取redo allocation latch(public redo allocation latch),防止有新的change vector
继续写入log buffer,造成LGWR无法确定应该写多少redo.
3)LGWR确定写的范围(从上次lgwr启动所写的最后一个日志块到这个时间点时的最后一个被
使用的所有写满or未写满的日志块)此时前台process仍可以向这个范围内的redo block(buffer)写内容(从
PGA写)所以lgwr不阻碍其它进程获得redo copy latch(即:不阻止其它进程向log buffer 中可用块中写
change vector)
4)确定redo block(buffer)后生成新SCN号
5)LGWR释放redo allocation latch与redo writing latch
6)LGWR需要等待 其它进程对要写入日志文件的block的更新操作完成(pga-log buffer的操
作),通过判断日志block(buffer)上的redo copy latch是否都释放。
7)将第4步scn号copy到要写入logfile的log buffer的块头里,然后触发物理的写操作,将这些
待写日志块写入redo file
“LOG BUFFER大于3M浪费空间,对性能影响不大的观点”是错误的,因为存在LOG FILE SYNC等待事件:
指等待LGWR将log buffer的数据写入到redo log file中。一般:
1)如果事务在做commit时,会有log file sync等待事件。
2)redo writing latch竞争过多,sp会有log file sync等待事件。
这种情况下,加大log buffer,适当调整_log_io_size大小,就可能可以减小log file sync等待事件。
计算redo的大小
法一:
利用下列sql语句在sql语句执行前后取差值即为此session产生的redo
评论