Redo

Jonathan Lewis erläutert ein paar subtile Details der Redo-Erzeugung. Unter anderem zeigt er, dass die Reihenfolge von Redo-Einträgen in den redo log Dateien seit 10g nicht mehr so ganz den Erwartungen entspricht, was anscheinend dem “private redo/in-memory undo” Mechanismus geschuldet ist:

In the 9.2.0.8 dump we’ll see the “traditional” sequence of redo generation, which follows very closely to the steps listed above and also shows that Oracle pairs a “redo change vector” for a table or index block with the matching “redo change vector” for an undo record that describes how to reverse the table (or index) change – an undo record, of course, is just a piece of information that gets stored in an undo block. In general, each pair of redo change vectors will be gathered into a single “redo record”.

In the 10.2.0.3 dump we’ll see that the same redo change vectors still exist but they’ve all been lumped into a single redo record, and their ordering in that record is completely different from the 9.2.0.8 ordering, demonstrating (or at least supporting) the point that the “private redo/in-memory undo” mechanism uses two separate buffers, one for redo change vectors related to table/index blocks (the private redo bit) and the other for redo change vectors related to undo records (the in-memory undo bit).

In den Kommentaren (vor allem von JL und Mathew Butler) folgt noch eine detailliertere Diskussion der Schritte, die im Zusammenhang des Commits erfolgen.