lgwr 为Log writer的简称,oracle核心进程之一的lgwr进程也是极为重要的一个进程,我们通常所接触的log file sync,log file parallel write都跟该进程有做紧密联系。
Write-Ahead Logging
This rule implies two conditions:
- Before a change is made to a block, the Oracle server guarantees that the redo record has been written to the redo log buffer.
- Because of the LRU algorithm that implements buffer replacement policy in the buffer cache, it is possible that a dirty and uncommitted block may be required to be paged out to disk. Before DBWR can write the dirty block back to disk, the redo log records that contain the corresponding changes (which is on the redo log buffer according to the previous condition) must be written to persistent storage (the online log files). The entries are written to the online logs by LGWR. Thus DBWR must post and wait for LGWR before doing its own write operation.
Redo Generation:
A server process intending to change a data block has to start by pinning the buffer in Exclusive mode. Then, it constructs an array of change vectors describing the changes. The array, called kcocv, is built in the PGA. Making calls to kconew() and kcoadd(), this array is populated.
After the redo record is built, it has to be written to the redo log file by a call to kcrfwr(). This routine starts by determining how many bytes must be allocated. Then, it determines the SCN to be stored with the redo record. Note that not every record has necessarily a different SCN.
After a valid SCN has been determined, a redo copy latch is acquired, while holding the latch, each change vector is checked to ensure that it is not changing a file that has had its redo generation stopped.
Next the redo allocation latch is acquired. The redo copy latch is not really needed until later on, but acquiring the redo copy latch first eliminates executing the code to acquire it while holding the redo allocation latch. This increases the contention on the redo copy latch, but it can be reduced by using multiple latches. At this point, a quick check is made to ensure that no other process has generated redo at a higher SCN than the one that is determined above. If this is the case, then a new SCN is allocated. Next, the function determines if there is enough space available to write the redo record. Space can only be allocated in the redo buffer if there is enough space in the log file. If there is space in the buffer, but not in the file, then a log switch must occur first. Because a small part of the redo log may be unused, on some platforms the archive redo logs may be smaller than the online logs.
If there is not enough space to proceed with the allocation, then the process has to wait for LGWR to make it available. The redo allocation latch and redo copy latch are freed at this point. Then, the process must determine whether to wait for LGWR to finish the current I/O (if one is in progress), whether to post LGWR to initiate a new I/O (because no other process has made the request yet) or whether to request a log switch.
In order to prevent multiple processes posting LGWR or requesting log switches simultaneously, the redo writing latch is implemented. A process in need for space must first allocate this latch to determine what to do next, whether to post LGWR to perform a write and free space in the buffer, request a log switch, or simply wait.
When LGWR is writing redo to the files, it also has the redo writing latch, so any other process trying to get this latch has to wait. Hence, the first thing a process is going to do after it gets the redo writing latch is to check whether space has just become available. If this is the case, then the latch is released and processing starts again, trying to get the redo copy latch.
If there is no space in the current log file, and kcrfwr() returns False indicating that it cannot write the redo to the buffer, then kcrfws() is called to determine whether another process has already requested a log switch, in which case, it just waits for the space to become available. Or, it requests a log switch itself.
If there is no space in the buffer but there is space in the current redo log, then LGWR is posted to do a write and free some space.
If the latches were released because space was not available, then they have to be acquired again. When space is finally available, it is allocated. Then, the redo allocation latch is freed. Still under the redo copy latch, the change vectors are copied into the log buffer, the buffers are linked into the checkpoint queues for bounded recovery time, and the change vectors are applied to them. At this point, the redo copy latch is also released.
The last thing this function does is to determine whether LGWR should be posted for a write or not. This is determined by reaching certain thresholds. If the answer is yes, LGWR is requested to perform a write.
This diagram shows the algorithm of kcrfwr(). This is followed by the server process when copying redo information into the log buffer
The server process:
- Pins a data block buffer in Exclusive mode
- Builds change vectors and bundles them into a redo record in the PGA
- Determines the space that is required in the log buffer
- Allocates that space in the log buffer
- Writes the redo record into the log buffer
- Changes the data block in the buffer cache
LGWR writes the contents of the buffer to disk:
- If posted by foreground processes: 1)Because redo log buffer space is not available 2)Because the transaction is committed
- If the log buffer is 1/3 full
- If 1 MB worth of redo records has been logged
- If the thread is closed
- At a log switch (user-initiated or normal)
- At a three-second LGWR inactivity timeout
LGWR Algorithm
When LGWR is required to write redo buffers, it requests the redo writing latch first to make sure that other foreground process do not continue to post LGWR requesting I/O, and then the redo allocation latch to prevent them from allocating more redo space. LGWR then determines the buffers to be written. All full buffers up to and including the buffer which is to be synched or used are included for write. At this point, a new SCN is allocated to ensure that LGWR never does two flushes at the same SCN. After this has been completed, the redo allocation latch can be released.
Because the log buffer is a circular structure that is represented by an array, up to two write requests are built. Depending on where the last request ended, the log may have wrapped.For recovery purposes, the target RBA is calculated and the need for a checkpoint is evaluated based on LOG_CHECKPOINT_INTERVAL. After this, the redo writing latch is released. Because it is possible in some cases that redo generation is still in progress, LGWR must ensure that all foregrounds have completed modifying the redo buffers it is about to write. While copying into the redo buffer a foreground holds a redo copy latch and has the low block number of the redo stored with the latch. When the redo copy latch is not being used, the buffer number is set to UB4MAXVAL. Thus LGWR need not wait unless the block that is associated with the redo copy latch is less than the first block that goes into the next disk write.
This must be done before calculating the checksums because the values to be check summed could be in the middle of changing. If a foreground is still copying redo, then LGWR requests an awakening post message when the corresponding redo copy latch is released. Note that LGWR does not acquire any redo copy latches at all, it just waits for them to be released. This is enough to guarantee that the foreground has finished modifying the buffer to be written. This way, LGWR is not blocking foregrounds that intend to write in other areas of the log buffer. After all the redo generation is completed for the buffers to be written, LGWR fills the block header (with SCN information) for each redo buffer and then issues the disk writes. You can enable async I/O for LGWR by using the parameter _LGWR_ASYNC_IO.
Redo Wait Events
- Log file parallel write:This is the main event waited while writing the redo records to the current log file. The call to write the log buffer is only made in LGWR, and the write operation is parallelized per physical disk. However, the wait is not over until the last redo buffer is sent to the disk.
- Log file sync:When a request is made to sync, the write by LGWR includes all the redo up to the specific RBA and the redo pointed to by that RBA that is not already on disk. The time it takes for LGWR to complete the write and then post the requestor is the log file sync wait event. Each user COMMIT or ROLLBACK must sync the redo with an infinite RBA, forcing a complete flush of the log buffer to the redo log file.
- Log file switch (checkpoint incomplete):This can be caused under heavy load when the checkpoint for the next log is not completed. The process has to wait before a log switch is possible.
- Log file switch (archiving needed):A process has to wait for the log switch and the reason why this is not done yet is because the previous contents of the new log have not been archived yet.
- Log file switch (clearing log file):This happens when the DBA enters the ALTER SYSTEM CLEAR LOG FILE command and the LGWR needs to switch to the log file that is being cleared. Wait time: 1 second.
- Log file switch completion:This happens when the current log file is simply full. The LGWR must complete the writing to the current log file and open the new one (switch log files). Wait time: 1second.
- Switch log file command:Waiting for the user command to switch log files to complete.
- Log buffer space:This is the event kcrfws() waits on. It means a process is waiting for space in the log buffer because the foreground processes are writing redo records faster than LGWR can write them out. Consider making the log buffer bigger if it is small, or moving the log files to faster disks such as striped disks. Wait time: 1 second normally, but 5 seconds if waiting for a switch log file to complete.
- Log switch/archive:This event is waited when the DBA manually enters the command ALTER SYSTEM ARCHIVE LOG CHANGE <scn>. If the log that is to be archived is in the current thread, then a log switch is requested and waited until it is done. Otherwise (the log that is to be archived is not in the current thread), this event is waited for 10 seconds.
- Log file sequential read:Any request to read from the redo log files waits for this event. The read can be the redo records or the log file header. The P3 column indicates the number of blocks that are read and is set to 1 if the wait is for the log file header. The number of blocks to read in one batch is port specific and cannot be tuned.
- Log file single write:This event is waited only when writing the log file header block. There are two places where the header block is written: when adding a new member file and when the log sequence number is advanced. The only contention reason could be the access time to the file, which can simply be resolved by reducing nonredo-related activity on the disk or placing the redo files on faster disks.
- LGWR wait for redo copy:LGWR is about to write a set of log blocks but it has to wait until the foreground processes complete any current copy operations which affect the buffers that are about to be written out. This used to occur under latch waits for the redo copy latch in Oracle7.0 and 8.0. This method of waiting is intended to be faster as the foreground should post LGWR when done. Wait time: 10 ms or until posted.
strace跟踪
1 2 3 4 5 6 7 8 9 |
delete from test.t where rownum<100; exec dbms_lock.sleep(10); delete from test.t where rownum<1000; exec dbms_lock.sleep(10); delete from test.t where rownum<10000; exec dbms_lock.sleep(10); delete from test.t where rownum<1; exec dbms_lock.sleep(1); commit; |
lgwr strace:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
4728 10:14:35.037358 pwrite(258, "\1\"\0\0\377[\0\0007\0\0\0\20\200\354\26|\21\0\0\r\0\0\0\204\4-\0\1\0000\0"..., 38912, 12058112) = 38912 4728 10:14:35.047958 pwrite(259, "\1\"\0\0\377[\0\0007\0\0\0\20\200\354\26|\21\0\0\r\0\0\0\204\4-\0\1\0000\0"..., 38912, 12058112) = 38912 4728 10:14:38.069613 pwrite(258, "\1\"\0\0K\\\0\0007\0\0\0\20\200\214\230\340\0\0\0\6\2\0\0\205\4-\0\1\0\1\0"..., 6144, 12097024) = 6144 4728 10:14:38.081141 pwrite(259, "\1\"\0\0K\\\0\0007\0\0\0\20\200\214\230\340\0\0\0\6\2\0\0\205\4-\0\1\0\1\0"..., 6144, 12097024) = 6144 4728 10:14:44.109445 pwrite(258, "\1\"\0\0W\\\0\0007\0\0\0\20\200\315\245\310\1\0\0\5\0\0\0\210\4-\0\1\0\0\0"..., 392704, 12103168) = 392704 4728 10:14:44.119379 pwrite(259, "\1\"\0\0W\\\0\0007\0\0\0\20\200\315\245\310\1\0\0\5\0\0\0\210\4-\0\1\0\0\0"..., 392704, 12103168) = 392704 4728 10:14:53.169996 pwrite(258, "\1\"\0\0V_\0\0007\0\0\0\20\200\203\235\240\1\0\0\5\0\0\0\214\4-\0\1\0\0\0"..., 6144, 12495872) = 6144 4728 10:14:53.180675 pwrite(259, "\1\"\0\0V_\0\0007\0\0\0\20\200\203\235\240\1\0\0\5\0\0\0\214\4-\0\1\0\0\0"..., 6144, 12495872) = 6144 4728 10:14:53.183200 pwrite(258, "\1\"\0\0b_\0\0007\0\0\0L\200\274s\356\7\0\1\214\4-\0\0\0003\0\17\0\6["..., 1048576, 12502016) = 1048576 4728 10:14:53.187680 pwrite(259, "\1\"\0\0b_\0\0007\0\0\0L\200\274s\356\7\0\1\214\4-\0\0\0003\0\17\0\6["..., 1048576, 12502016) = 1048576 4728 10:14:53.191589 pwrite(258, "\1\"\0\0bg\0\0007\0\0\0\324\200\31x\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 38912, 13550592) = 38912 4728 10:14:53.192263 pwrite(259, "\1\"\0\0bg\0\0007\0\0\0\324\200\31x\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 38912, 13550592) = 38912 4728 10:14:53.196430 pwrite(258, "\1\"\0\0\256g\0\0007\0\0\0\20\200l\373\250\1\0\0\5%\0\0\215\4-\0\1\0\0\0"..., 1048576, 13589504) = 1048576 4728 10:14:53.201005 pwrite(259, "\1\"\0\0\256g\0\0007\0\0\0\20\200l\373\250\1\0\0\5%\0\0\215\4-\0\1\0\0\0"..., 1048576, 13589504) = 1048576 4728 10:14:53.205136 pwrite(258, "\1\"\0\0\256o\0\0007\0\0\0T\200\261\364\v\3\1\0\4\0\1\0?\10\0\1\215\4-\0"..., 989184, 14638080) = 989184 4728 10:14:53.208060 pwrite(259, "\1\"\0\0\256o\0\0007\0\0\0T\200\261\364\v\3\1\0\4\0\1\0?\10\0\1\215\4-\0"..., 989184, 14638080) = 989184 4728 10:14:53.215231 pwrite(258, "\1\"\0\0:w\0\0007\0\0\0\10\201\240\37\v\1\35!\0\0\245\25\2\r\0\0\0\0\0\0"..., 25088, 15627264) = 25088 4728 10:14:53.216629 pwrite(259, "\1\"\0\0:w\0\0007\0\0\0\10\201\240\37\v\1\35!\0\0\245\25\2\r\0\0\0\0\0\0"..., 25088, 15627264) = 25088 4728 10:14:53.220856 pwrite(258, "\1\"\0\0kw\0\0007\0\0\0\20\200%C\240\1\0\0\5A\0\0\216\4-\0\1\0\26\4"..., 784384, 15652352) = 784384 4728 10:14:53.222674 pwrite(259, "\1\"\0\0kw\0\0007\0\0\0\20\200%C\240\1\0\0\5A\0\0\216\4-\0\1\0\26\4"..., 784384, 15652352) = 784384 4728 10:15:04.216833 pwrite(258, "\1\"\0\0g}\0\0007\0\0\0\20\200r>\250\0\0\0\5\2\0\0\222\4-\0\1\0\0\1"..., 512, 16436736) = 512 4728 10:15:04.227321 pwrite(259, "\1\"\0\0g}\0\0007\0\0\0\20\200r>\250\0\0\0\5\2\0\0\222\4-\0\1\0\0\1"..., 512, 16436736) = 512 4728 10:15:07.203236 pwrite(258, "\1\"\0\0h}\0\0007\0\0\0\20\200\375\305\374\1\0\0\r\0\0\0\224\4-\0\1\0\10\225"..., 1024, 16437248) = 1024 4728 10:15:07.207265 pwrite(259, "\1\"\0\0h}\0\0007\0\0\0\20\200\375\305\374\1\0\0\r\0\0\0\224\4-\0\1\0\10\225"..., 1024, 16437248) = 1024 4728 10:15:07.295293 pwrite(258, "\1\"\0\0j}\0\0007\0\0\0\20\200\26\341t\0\0\0\5\0\0\0\225\4-\0\1\0009\0"..., 1536, 16438272) = 1536 4728 10:15:07.302058 pwrite(259, "\1\"\0\0j}\0\0007\0\0\0\20\200\26\341t\0\0\0\5\0\0\0\225\4-\0\1\0009\0"..., 1536, 16438272) = 1536 |
kst观察lgwr 3s timeout唤醒:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
2020-11-23 03:51:44.773636 :8010F742:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[0] comment=[Monitor Cleanup] 2020-11-23 03:51:44.773754 :8010F743:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[3] comment=[KSB action for bast checking] 2020-11-23 03:51:44.773800 :8010F744:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[96] comment=[Redo writer IO's] 2020-11-23 03:51:44.773838 :8010F745:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[98] comment=[Redo writer log switch operations] 2020-11-23 03:51:44.773864 :8010F746:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[100] comment=[Redo writer generate offline immed marker] 2020-11-23 03:51:44.773887 :8010F747:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[101] comment=[Cache all logfiles] 2020-11-23 03:51:44.773910 :8010F748:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[275] comment=[kfr Poke LGWR] 2020-11-23 03:51:44.773933 :8010F749:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[276] comment=[kfr Incr Ckpt] 2020-11-23 03:51:44.773956 :8010F74A:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[277] comment=[kfr ACD relocation] 2020-11-23 03:51:47.775130 :8010F95B:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[0] comment=[Monitor Cleanup] 2020-11-23 03:51:47.775152 :8010F95C:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[3] comment=[KSB action for bast checking] 2020-11-23 03:51:47.775173 :8010F95D:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[96] comment=[Redo writer IO's] 2020-11-23 03:51:47.775206 :8010F95E:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[98] comment=[Redo writer log switch operations] 2020-11-23 03:51:47.775229 :8010F95F:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[100] comment=[Redo writer generate offline immed marker] 2020-11-23 03:51:47.775250 :8010F960:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[101] comment=[Cache all logfiles] 2020-11-23 03:51:47.775271 :8010F961:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[275] comment=[kfr Poke LGWR] 2020-11-23 03:51:47.775294 :8010F962:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[276] comment=[kfr Incr Ckpt] 2020-11-23 03:51:47.775380 :8010F963:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[277] comment=[kfr ACD relocation] 2020-11-23 03:51:50.776305 :8010FB01:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[0] comment=[Monitor Cleanup] 2020-11-23 03:51:50.776325 :8010FB02:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[3] comment=[KSB action for bast checking] 2020-11-23 03:51:50.776343 :8010FB03:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[96] comment=[Redo writer IO's] 2020-11-23 03:51:50.776375 :8010FB04:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[98] comment=[Redo writer log switch operations] 2020-11-23 03:51:50.776402 :8010FB05:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[100] comment=[Redo writer generate offline immed marker] 2020-11-23 03:51:50.776422 :8010FB06:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[101] comment=[Cache all logfiles] 2020-11-23 03:51:50.776440 :8010FB07:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[275] comment=[kfr Poke LGWR] 2020-11-23 03:51:50.776458 :8010FB08:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[276] comment=[kfr Incr Ckpt] 2020-11-23 03:51:50.776476 :8010FB09:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[277] comment=[kfr ACD relocation] 2020-11-23 03:51:53.777445 :8010FD31:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[0] comment=[Monitor Cleanup] 2020-11-23 03:51:53.777484 :8010FD32:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[3] comment=[KSB action for bast checking] 2020-11-23 03:51:53.777503 :8010FD33:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[96] comment=[Redo writer IO's] 2020-11-23 03:51:53.777533 :8010FD34:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[98] comment=[Redo writer log switch operations] 2020-11-23 03:51:53.777554 :8010FD35:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[100] comment=[Redo writer generate offline immed marker] 2020-11-23 03:51:53.777572 :8010FD36:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[101] comment=[Cache all logfiles] 2020-11-23 03:51:53.777590 :8010FD37:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[275] comment=[kfr Poke LGWR] 2020-11-23 03:51:53.777609 :8010FD38:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[276] comment=[kfr Incr Ckpt] 2020-11-23 03:51:53.777626 :8010FD39:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[277] comment=[kfr ACD relocation] 2020-11-23 03:51:56.779507 :8010FF9B:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[0] comment=[Monitor Cleanup] 2020-11-23 03:51:56.779527 :8010FF9C:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[3] comment=[KSB action for bast checking] 2020-11-23 03:51:56.779544 :8010FF9D:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[96] comment=[Redo writer IO's] 2020-11-23 03:51:56.779589 :8010FF9E:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[98] comment=[Redo writer log switch operations] 2020-11-23 03:51:56.779611 :8010FF9F:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[100] comment=[Redo writer generate offline immed marker] 2020-11-23 03:51:56.779629 :8010FFA0:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[101] comment=[Cache all logfiles] 2020-11-23 03:51:56.779648 :8010FFA1:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[275] comment=[kfr Poke LGWR] 2020-11-23 03:51:56.779666 :8010FFA2:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[276] comment=[kfr Incr Ckpt] 2020-11-23 03:51:56.779685 :8010FFA3:db_trace:ksb.c@1835:ksbcti(): [10254:11:130] KSBCTI: (LGWR) : (timeout action) : acnum=[277] comment=[kfr ACD relocation] |
结论
- lgwr进程每3s触发一次,但不一定write,只是被唤醒,如果没有需要写的log buffer则不写。
- lgwr进程每次写入的大小是不固定的,是以batch的方式写入,但是都是redo log block_size(512 byte)的整数倍.
- lgwr是顺序写
- lgwr的一次性写大小最大达到了1048576 byte=1m大小,可以认为最大单次io大小是1m(_max_io_size)
- log file parallel write并不是同时写的,以最后一个写完的为准