I have a couple of questions related to the private redo buffers and in-memory undo which you describe starting at page 14.

1) From the figures on page 16 it seems, that a transaction hits the private redo allocation latch once (and presumably “reserves” the corresponding private redo buffer for exclusive usage until the transaction flushes its contents to a public redo buffer) while the transaction hits the in-memory undo latch once per change, which suggests that one in-memory undo pool may be used simultaneously by many transactions.
a) Are my conclusions about the usage patterns correct? I doubt a bit, as you state on page 16 “1. Start the transaction by acquiring a matching pair of the private memory structures”, which might be interpreted as “acquiring them exclusively” – however if this is the case, why would the transaction have to hit the in-memory undo latch once for every change?
b) If so, what justifies the different usage patterns? I.e. why are the private redo buffers used exclusively by a transaction while the in-memory undo pools are shared by concurrent transactions. It seems that the number of private redo buffers equals the number of in-memory undo pools (see http://www.teamycc.com/rmoug_2008_conference/PDF/Haisley.pdf, slide 20). To me this makes the different usage pattern /allocation schema even more surprising.
c) If my assumption on concurrent usage of the in-memory undo pools is correct, then upon commit a transaction has to search its undo change vectors from the in-memory undo pool as they may be mingled with undo change vectors from other transactions in the same pool. This seems as quite an overhead to me – are there any auxiliary structures mitigating that effect?

2) What is the reason to apply the changes to the data and undo blocks only upon commit (rather than right after creation of the change vectors)? Are there any performance benefits from this proceeding or is it just to ensure the write-ahead protocol is respected when DBWR writes data and undo blocks to disk (which I believe could also be achieved if the DBWR just looked at the block’s “has private redo” flag).

3) Did you write any additional blog on the in-memory undo / private redo or do you know any other resources describing the mechanism in more details?

thank you
kind regards
Martin

When you roll back a transaction, you will generate redo because you are making changes to data blocks (which includes changed to undo blocks) – but you do not generate new undo records, you are only marking existing records as “user applied”. Rolling back does not create a new transaction so there is no need for further ITL entries to come into play.

when we rollback a transaction ,we will apply the undo record in reverse order,and the itl in undo record will replace the itl in the data block …… finally,to get the correct version of the block.
the process of rollback can also produce redo record and undo record,and what is its own itl(i think the itl here is different from the itl replaced by the undo record)? the block have more than one itl ,when undo record cover one itl ,if the rollback session use another ltl to point to its own new undo?

thanks!!

The comment is simply pointing out that when we make read-consistent copies of a block it’s okay to discard them within a short period of time.
They can be useful, and the way the copy is used may mean that it stays in memory for some time – but it’s not a copy that HAS to be protected for the sake of database correctness. (Other sessions may be able to use the CR copy we’ve created, either to read it directly, or to clone it and take their clone further back in time.).

In page 21, you wrote:

“”There is an important difference between read consistency and rolling back, of course. For read consistency we make a copy of the data block in memory and apply undo records to that block, and it’s a copy of the block that we can discard very rapidly once we’ve finished with it……”

What do you mean by “and it’s a copy of the block that we can discard very rapidly”? I might not have clearly understood this. Does this mean that a new session could not benefit from an exact reconstructed read consistency image of a block done by a preceding session because the copy of the block used for that purpose has been rapidly discarded?

Or does the work done on the copy of the block is kept in the buffer cache(for reuse) while the copy of the block is thrown away?

My question came up here after having participated to the following otn thread :

https://forums.oracle.com/forums/message.jspa?messageID=10712705#10712705

Thanks in advance

Mohamed Houri

The reference object for buffers is x$kcrfstrand, and there’s a little script listing important addresses in the Appendix D, and I’ve just posted a variant on the script to show how you can get the sizes (and a little extra information) for your system. As a general principal, Oracle minimises the use of multiple log buffers (public and private). In the case of the private buffers this is done by picking the lowest numbered buffer that is available, in the case of the public buffers Oracle will only use more than one thread if there are indications of latch contention (on the public redo allocation latches.)

On a log writer flush, the log writer writes each of the public redo threads in turn before returning. Tony Hasler has an interesting post on this topic.

In general you shouldn’t be setting the log_buffer parameter, but if you do you may find that the value you set is (roughly) divided equally between the number of public redo threads – but the behaviour is not very consistent.

Page 15: Note [...] In 10g you get at least two public log buffers (redo threads) if you have more than one CPU.

I thought that multiple threads are only in RAC databases where each instance has its own thread. How big public log buffers are and what do they have in common with the buffer defined by log_buffer parameter? Is there any sort of redo record sorting when the log writer flushes the public log buffers to disk or are they managed independently?

How can I check how many public log buffers are used in my database? Any init parameter responsible for that? I see that log_parallelism dissappeared in 10g.

2) There are various points where the block (or part thereof) may be checked. Some checks can be enabled or disabled by parameter settings (e.g. db_block_checksum) some are simply built-in as implicit checks (e.g. code to update a row that finds that one row over-runs into a area of memory pointed at by another rowindex entry).

3) I don’t really know. There are a couple statistics about “db block corrupt” and “gc block corrupt” that might be relevant (one of the checks applies when block are sent across the RAC interconnect, another as they arrive). It’s also possible that some of the stats about block recovery and redo applied for recovery (which will be modified during instance recovery) wil also be modified during block recovery.

Possible statistics (may really be only for database startup)

redo blocks read for recovery
redo k-bytes read for recovery
db corrupt blocks detected
db corrupt blocks recovered
gc blocks corrupt

Possible wait events

recovery buffer pinned
recovery read

I have three question regarding the note on page 14 “…a session can read the online redo log files when it discovers the in-memory version of a block to be corrupt…”.
1) What is the intended purpose of this mechanism, what kind of corruptions does this mechanism address, data corruptions caused by Oracle bugs, data corruptions caused by hardware (RAM) failures, any other data corruptions or a combination of those?
2) At which points during the processing does Oracle check in-memory blocks for data corruption (every time a session visits them, before the DBWR writes them to disk, …)?
3) Is there any metric (e.g. session statistic) showing how many times in-memory blocks were checked for corruption and/or how many times online redo logs had to be used in order to rectify such corruptions?

Thanks a lot
kind regards
Martin

MOS DOC ID 8338582.8 points to Bug 8338582 in 11.1.0.7 but that is with index access and says it has been fixed in 11.2.0.1
Bug 8338582 SET TRANSACTION READ ONLY may see wrong data for index access.