Granularität der SCN

Ich mache es mir immer leichter mit meinen Blog-Einträgen: diesmal beschränke ich mich auf einen Link zu einem Artikel von Frits Hoogland und zitiere dann einfach die dort gelieferte Zusammenfassung:

Changes in the database are synchronised by system change numbers, also known as SCNs. SCNs are the way Oracle serialises changes to data. However, this post shows that the Oracle engine tries to maximise the number of changes inside a SCN, and as such a SCN is not an highly granular serialisation mechanism. This is not a problem, since Oracle’s transactional protection mechanisms (like TX and TM locks) do work alongside SCNs to make sure no conflicting changes can happen at the same time. The changes itself do just read and pick the current global SCN from the instance, a commit of these changes does increase the global SCN, but as little as possible. You might find multiple changes in the same SCN, and you might even find commits with the same SCNs.

Sehr kompakt und präzise. Merken werde ich mir in erster Linie, dass der Artikel erklärt, warum mehrere Commits die gleiche SCN beinhalten können.

Zusammenspiel von log writer und foreground Prozessen beim Commit

Wenn Frits Hoogland, dessen Beiträge in der Regel ziemlich komplexe Analysen beinhalten, seinen Artikel How the log writer and foreground processes work together on commit mit den Worten beginnen lässt "warning: this is a rather detailed technical post on the internal working of the Oracle database’s commit interactions between the committing foreground processes and the log writer", dann sollte ich so einen Hinweis vielleicht lieber ernst nehmen. Nach der wiederholten Lektüre des Textes bin ich zum Ergebnis gekommen, dass ich in diesem Fall nicht dazu in der Lage bin, ein halbwegs plausibles Exzerpt zu schreiben, weil der Artikel dafür zu viele technische Details beinhaltet, die ich nicht aus dem Kontext reißen mag und auch nicht ausreichend klar erläutern könnte, ohne den Artikel komplett zu übersetzen - und dazu bin ich, Gott sei Dank, nicht verpflichtet. Sollte ich aber jemals in eine Situation kommen, in der das Wissen um die exakten Zusammenhänge bei der Ermittlung der SCN im Kontext von private redo strands eine Rolle spielt und die Auswirkungen der Verwendung der Funktion kcscur3() relevant sind, dann wüsste ich, wo ich nachzuschauen hätte. Und das gleiche gilt für den Fall, dass ich mir ausgefeilte Analysestrategien für die Untersuchung interner Oracle-Operationen ausdenken müsste. Der Artikel kann als vertiefende Ergänzung zu Jonathan Lewis' Buch Oracle Core betrachtet werden - und viel tiefer geht es nicht...

SCN

Zuletzt haben sich Martin Decker und Riyaj Shamsudeen ausführlicher zum Thema System Change Number (SCN) geäußert:

• Martin Decker weist auf einen häßlichen Bug hin, der sich ergibt, wenn die SCN ihren Maximalwert erreicht - was unter bestimmten Umständen sehr viel schneller passieren kann, als man angesichts des gigantischen Werteraums, der für sie zur Verfügung steht, erwarten würde.
• Bei Riyaj Shamsudeen erfährt man Grundsätzliches zum Thema, beispielsweise zum gerade angesprochenen Wertebereich: "SCN is a huge number with two components to it: Base and wrap. Wrap is a 16 bit number and base is a 32 bit number. It is of the format wrap.base. When the base exceeds 4 billion, then the wrap is incremented by 1. Essentially, wrap counts the number of times base wrapped around 4 billion." Außerdem wird erläutert, wo die SCN verwendet und wann sie erhöht wird, und auch die Bugs, die der Herr Decker anspricht, werden beleuchtet.