Starting on page 151 you describe the scenario that leads to the “log file switch (private strand flush incomplete)” message in the alert log. I think I got the big picture, but there are a couple of things I didn’t understand.

1) What does “triggers a log file switch prematurely” exactly mean in the context it appears on page 151 – does LGWR start writing into the new log file at this very moment or does it mean the processing you describe subsequently (DBWR flushing private redo …) is initiated?

2) After the log file switch is triggered prematurely, DBWR flushes private redo into the public buffers as you describe on page 152. How does the redo finally get into the (old) redo log file? Is it DBWR that (exceptionally) writes this data into the redo log files (as you write “the database writer gets it [the redo data] there [into the log file]“) or is it LGWR? However, if it was LGWR, wouldn’t the data end up in the new log file, as the log file switch has already happened (see question 1)?

3) When Oracle decides at moment t to switch from log file L1 to log file L2, I believe it must ensure that (i) everything that was in the private or public redo buffers at time t will go into log file L1 and that (ii) no redo generated after time t will go into log file L1. (i) is to ensure that all the redo records in each log file are between this file’s starting SCN and the following file’s starting SCN as you describe on page 151 (I don’t understand exactly why this is necessary, but it seems plausible that e.g. in some scenarios the code needs to be sure it got all redo records up to a certain SCN). (ii) I believe is necessary to ensure that L1 can be safely overwritten once the corresponding media recovery checkpoint completes (as DBWR will have written to disk the data blocks that were modified up to time t, but blocks modified more recently may still not be up to date in the datafiles).
Does that imply that Oracle will stop redo generation for all sessions (not only those using private redo) until the private strands are flushed into the public redo buffers? This might be necessary to prevent some redo generated before time t from ending up in log file L2 despite the space that was reserved in L1 at the premature log file switch (which would compromise (i)) and also to prevent new redo generated after time t to end up in L1 (which would compromise (ii)). Does Oracle even stop such redo generation until the LGWR has written the entire public redo buffers (including the flushed content from the private redo buffers) into log file L1 or are there other ways (i.e. telling the LGWR after which redo buffer entry it should start writing into the new log file L2)?

Than you
kind regards
Martin

On page 139 you describe how a buffer is getting on the checkpoint queue when it becomes dirty. You also write that the buffer’s LRBA is set – I understand this as being the Redo Block Address of the change record describing the change that made the buffer dirty. However, at the moment the buffer becomes dirty, this change record has not necessarily been written to the redo logs – it may still be in one of the (potentially multiple) log buffers. How can Oracle at this moment determine the Redo Block Address this record is going to be written to? This becomes even more difficult when taking into account the possibility that redo from private redo buffers may yet have to be flushed into one of the public redo log buffers and may thus end up in the redo log files before or after the change record mentioned before depending on the public redo log buffer it is written to and the order in which LGWR will write the public redo logs to disk.
Could it be (this is just a guess) that for the purpose of checkpointing it is sufficient to have a lower bound of what I understood to be the LRBA, in which case it might be the Redo Block Address last written by LGWR at the moment the buffer became dirty?

thank you
kind regards
Martin

On page 141 you describe the scenario where LGWR is stuck because it cannot overwrite a redo log that contains changes that where not yet written to the data files by DBWR. You mention “… occasionally it means you need a faster device for your redo logs”. Shouldn’t that say “…you need a faster device for your data files”. As I understand it, the redo logs are already written too fast in this scenario (relatively speaking), thus I would not expect a faster device for the redo logs to relieve the problem.

Thank you for clarification
kind regards
Martin

Thank you for your reply. So if I understand correctly, the scenario is one possible side effect of what you describe in the section “ACID Anomaly” starting on page 129? I am however surprised that Oracle tries to rectify this side effect (by reordering redo records before applying them) but does not address the root problem (ACID anomaly) itself. Are there maybe other scenarios which justify / necessitate the reordering of redo records during recovery?

kind regards
Martin

At the hypothetical level given in the manuals you’re correct. In fact Tony’s starting scenario is possible because of a time-lag that he and I have both blogged about elsewhere.

When a session issues a commit (on a small transaction), the sequence of events is this:

Note particularly that the transaction IS visibly committed by the change applied to the undo segment header being applied before the log writer has been called.

Because of this it would be possible for a second transaction to see the results of the first committed (unwritten) transactions, and so on.

It would, of course, be hard to prove that this had happened – but it would be easy to make it happen by mixing some very rapid, high volume updates in one session while performing some highly concurrent, very small transactions from another. As some point lgwr would be busy doing a large write to the log file giving the high frequency sessions time to go through Tony’s scenario.

If I understand correctly the term “dependent transactions” it implies that T1 commits before T2 makes any changes which depend on changes made by T1 and T2 commits before T3 makes any changes depending on changes made by T2. If this is correct, than I believe the scenario described by Tony Hasler would not be possible however.
If T1 commits before T2 makes any modification depending on T1 then all redo records generated by T1 will be written to the redo log files before any redo records are generated for the dependent modifications made by T2 and idem for T2/T3, no matter which redo strands are used by the transactions.
Did I misunderstand something?

Example:
Assume transactions T1, T2, T3 which consecutively increment the value of one column for one row in a table i.e. “UPDATE T SET VAL=VAL+1 WHERE ID=:X;”. It is my understanding that this is what is ment by “dependent transactions” as mentioned in the scenario described by Tony Hasler.
In this example T2 cannot lock the row in table T until T1 will have committed. I would assume that T2 will not generate any redo for the increment of T.VAL until it has locked the corresponding row. Once T2 can lock the row, this impiles that T1 has committed (or rolled back) and thus all redo records generated by T1 are in the redo log file, i.e. the redo records generated by T2 for the modification (increment) of the column value will be placed after the redo records generated by T1 in the redo log file.

Thank you for clarification
kind regards
Martin

Timur’s references do, in fact, explain everything. I had found the patent for the previous OPS mechanism (with the default few second delay) but had searched in vain for a description of anything new. The records are indeed cached and sorted before application. Not only does this sort out the issues I raised but also allows a) records confirming the writing of a data block to disk to avoid any attempt to apply redo generated earleir and b) blocks to be updated in order optimising head movements. This algorithm isn’t rocket science but obviously only becomes practical with modern high memory systems. I haven’t read the patents in detail yet but do intend to. Seems like the contents would make for a good user group masterclass one day!

I am not sure if this question belongs here or in chapter 6 but here goes.

I am thoroughly confused by the concept of multiple public redo strands. Suppose three dependent transactions occur in the order T1 , T2, T3. Suppose the redo data for T1 and T3 are placed in one public redo strand and the redo data for transaction T2 gets placed in another. It seems that the redo log will eventaully contain the data in the order T1, T3, T2 or T2, T1, T3 depending on which strand’s buffer is written out by LGWR first. This would seem to suggest that any recovery process would need to have some mechanism for looking ahead and reordering redo before applying it but I have never heard of such a thing. I am similarly confused about how dependent transactions in RAC are recovered.

Can you help me out?

Tony,
Your assumption about recovery having to “look ahead” and reordering redo before applying it is, I believe, correct; and your mention of RAC is extremely pertinent. When the question originally came up about how Oracle could handle recovery from parallel threads the first answer I heard was “it’s been doing it for years with RAC”.

There are a couple of public clues about the mechanism – there is a statistic called “redo ordering marks” which is a little suggestive, and there has been a KK lock type for ages that is used as the “Kick” lock when one RAC instance forces another instance to switch log files in order to keep the log file sequences close to each other. Beyond that I don’t have any details – I could do some hand-waving and produce a hypothesis, but with your previous experience in designing logging mechanisms you could probably do at least as well as I could.

The patents supplied by Timur may contain the information you need – but I haven’t read them yet.

Reply made by Timuy Akhmadeev to Tony’s question at its original location:

Thanks for that. It prompted me to add a little note to the Addenda for the Appendix showing how to generate an up to date list of events in the10,000 range since that’s one of the things I used from time to time when investigating problems.

I think event 10120 changed it’s meaning in the 8.1 time scale, the “CBO Index fast full scan” may have beeen the v7 and 8.0 effect, but I no longer have copies of those versions around to check. It’s a useful reminded, of course, that the events are (a) undocumented and (b) subject to change with no notice.

I’ve also pointed outin the addenda for this chapter your follow-up detail that “relative” file number is nominally “relative to tablespace” – although when you look closely the numbering isn’t anything that would match what most people would think of as “relative” since Oracle doesn’t start each tablespace at (relative) file number 1.

There’s plenty of scope for error when working with file numbers – for example, rowids show relative file numbers, not absolute file numbers:

SQL> select rowid from t1;

ROWID
------------------
AAAYHMAAGAAAACKAAA

1 row selected.

SQL> select rowid from t2;

ROWID
------------------
AAAYHLAAGAAAAAZAAA

1 row selected.

The format of the rowid is: {data_object_id[6]} {relative_file_number[3]} {block number[6]} {rownumber[3]} so, in this case, both rowids come from relative file AAG (which translates into relative file 6 – which I can count to since AAA corresponds to zero).

Since I happen to know that the two tables are in different tablespaces Oracle has to have some way of working out that there are two different absolute file numbers involved – and it can do this through the data object id, which can be used to determine the tablespace number for the segment.

ALTER SYSTEM SET EVENTS '10120 TRACE NAME CONTEXT OFF';
 
CREATE SMALLFILE TABLESPACE "TEST2" LOGGING DATAFILE 'C:\Oracle\OraData\OR1122P\TEST2.dbf' SIZE 5M EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
 
SELECT
  FILE#,
  RFILE#
FROM
  V$DATAFILE
WHERE
  NAME LIKE '%TEST2%';
 
FILE#     RFILE#
----- ----------
   10         10

Event 10120 clearly behaves as described in the book. Now my database has two datafiles with the same relative file number 10. Related to the Note’s comments, how would the user-facing code in Oracle Database that expects the relative file number react to the above situation – it seems as though one other key piece of information must be requested when the relative file number is required by user-facing code in Oracle Database.

Referencing the documentation:
http://docs.oracle.com/cd/E14072_01/server.112/e10595/dfiles001.htm
“Absolute: Uniquely identifies a datafile in the database.
Relative: Uniquely identifies a datafile within a tablespace.”