Oracle LGWR进程跟踪
Oracle LGWR进程在正常情况下有以下条件被唤醒:每三秒,写满logbuffer 1M,log buffer空间写满了三分之一,用户提交和其他进程通知需要写出log buffer(比如 dbwr进程在写出数据库块,都要通知LGWR进程先把对应的redo写出).
基本过程如下:
用户进程发布提交请求=>LGWR进程被唤醒=>LGWR进程发布IO调用写出log buffer=>IO写出成功返回=>LGWR进程通知用户进程可以继续下一步操作.
用户进程实际上是使用semctl这个系统调用去唤醒LGWR进程
我们打开第一个窗口执行一条insert语句,然后再提交
DONGDONGTANG> insert into t1 values(10);
1 row inserted
DONGDONGTANG> commit;
另一个窗口跟踪进程调用
[oracle@localhost ~]$ strace -t -p 22777
18:04:56 semctl(2883584, 17, SETVAL, 0x1) = 0
18:04:56 times(NULL) = 439153919
18:04:56 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 86131}, ru_stime={0, 123814}, ...}) = 0
18:04:56 times(NULL) = 439153919
18:04:56 times(NULL) = 439153919
18:04:56 getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 86138}, ru_stime={0, 123823}, ...}) = 0
18:04:56 semtimedop(2883584, {{47, -1, 0}}, 1, {0, 100000000}) = 0
用户进程在semid为2883584设置标志位,然后用户进程调用semtimedop,在2883584上进行睡眠.
系统为oracle分配了三个semphore id
[oracle@localhost ~]$ ipcs -s
------ Semaphore Arrays --------
key semid owner perms nsems
0xaece40bc 2883584 oracle 640 152
0xaece40bd 2916353 oracle 640 152
0xaece40be 2949122 oracle 640 152
LGWR进程的调用
18:04:55 semtimedop(2883584, {{17, -1, 0}}, 1, {3, 0}) = 0
18:04:56 times(NULL) = 439153919
18:04:56 times(NULL) = 439153919
18:04:56 pwrite(260, "\1\"\0\0\2158\0\0\17\0\0\0\20\200\331\217H\2\0\0\r\0\0\0=X\33\0\1\0\0\0"..., 1024, 7412224) = 1024
18:04:56 semctl(2883584, 47, SETVAL, 0x1) = 0
18:04:56 times(NULL) = 4391
在semid 2883584上被唤醒,通过pwrite调用写出日志文件,260刚好是当前打开的redo文件号.写出1024个字节后通过
过semctl调用返回给用户进程,用户进程接着可以继续下一步操作.
[oracle@localhost ~]$ ll /proc/22040/fd | grep 260
lrwx------. 1 oracle oinstall 64 May 23 18:19 260 -> /u01/app/oracle/oradata/cdb12/redo03.log
DONGDONGTANG> select group#,status from v$log;
GROUP# STATUS
---------- ----------------
1 INACTIVE
2 INACTIVE
3 CURRENT
所以在这里可以看出几个比较重要影响LGWR进程效率的因素:1,cpu负载,如果cpu负载比较高,而LGWR进程一直
得不到cpu运行,会使log file sync时间变得很长,隐含参数_high_priority_process可以使LGWR进程的PI为-12
而正常的进程运行优先级为20.(VKTM,LMS进程默认为-2);2,io系统的性能,在影响LGWR的效率占主要因素,IO越快
那么LGWR进程对应也能越快返回; 3,使用sem效率的问题,当一个系统中大量用户进程提交时,使用sem单次操作的
最大限制受kernel.semopm限制.在后续的版本中引入了adaptive log fie sync机制,当达到一定值时,使用polling
机制.
