In one of my previous blog post i demonstrated that the amount of work needed for IN-MEMORY population/[trickle] re-population in oracle 22.214.171.124.6 is more than we may expect : IN-MEMORY population/[trickle] re-population : How much work ? You may be surprised !
Let’s do a very quick check on how this is now handled in oracle 126.96.36.199/OEL 6/UEK4
As in my previous post i will trace the work done by the In-memory background worker processes W0nn during population and trickle re-population using a systemtap script. trace_oracle_logical_io_basic.stp
NOTE : If you receive “inode-offset registration error (rc 0)” using systemtap then check this post : Workaround for systemtap issue : Oracle Tracing [registration error (rc 0) !]
Test of In-memory population :
Create a table and load it IN-MEMORY.
Let’s check the systemtap trace file :
It’s seem that for some reason the IN-MEMORY population still need to reread the segment multiple times !
Test of In-memory re-population :
So here we gonna update a row which is located at block number “24491”.
Let’s check the systemtap trace file
There is huge improvement here compared with the previous release ! Only the needed block “21491” is reread (block 21472 is the segment header)
That’s it 😀