Все SCN в оракле используют одну и ту же последовательность. Разница в моментах времени, когда происходит изменение этой последовательности. При коммите назначается system commit number. Он же пишется в транзакционную таблицу блока и сегмента отката для пометки завершенности транзакции. System checkpoint number - это номер изменения системы, на который надо проводить синхронизацию, по окончании чекпойнта он прописывается в заголовки датафайлов. А в промежутках между коммитами, чекпойнтами и т.д. оракл проводит свои внутренние операции, которые помечаются как system change number. Поэтому различить их достаточно сложно.

Есть сомнения? В принципе, всю эту внутреннюю кухню и не надо знать. Какая разница, что означает scn, если он уникально определяет закоммиченную транзакцию? До коммита на scn ориентироваться нельзя, что опять-таки показывает ваш эксперимент - его просто нет. До фиксации уникальным идентификатором транзакции является положение транзакции в сегменте отката (поэтому одна транзакция и не может распределяться по разным сегментам отката). Это можно проверить по колонкам в v$logmnr_contents, относящимся к сегменту отката - xidusn, xidslt, xidsqn. Кстати, почему-то вы не посмотрели на столбец cscn - это как раз scn коммита.

Можно также сделать дампы блоков и посмотреть как занимаются транзакционные слоты, когда появляется номер коммита, как выставляются блокировки и т.п. Один раз это даже интересно сделать. Команда очень простая

alter system dump datafile {'filename'}|{fno} block {blockno}|block min {blockno} block max {blockno}.

Надеюсь, синтаксис понятен. Команда недокументирована, поэтому на вопросы о ней отвечать не буду.

Я буду ориентироваться на имена колонок в v$logmnr_contents. itl - interested transaction list - список транзакций в заголовке блока.

Вы хотите сказать что номер SCN для операторов в транзакции определяется положением в сегменте отката?
А что у сегментов отката уникальные номера в течении всей жизни БД?

Разумеется, у сегмента отката есть свой уникальный номер (usn), который не изменяется.

Архитектура транзакции следующая - в первой операции транзакции она распределяется в один из сегментов отката автоматически или по выбору разработчика xidusn. В транзакционной таблице в заголовке сегмента отката ей выделяется слот xidslt. Эта транзакционная таблица не бесконечна и переписывается по циклу. Каждый цикл переписывания этой таблицы увеличивает счетчик xidsqn. Таким образом, при активации транзакции ей назначается тройка чисел xidusn.xidslt.xidsqn. Эта же тройка чисел пишется и в itl блока данных, который модифицирруется транзакцией. Если транзакция затем меняет другие строки этого же блока, то в заголовках строк просто прописывается номер слота в itl блока для данной транзакции. Для других блоков, модифицируемых той же транзакцией, в itl пишутся та же тройка чисел xidusn.xidslt.xidsqn.

Это не предположение, а архитектура оракула. SCN в данном случае не играет определяющей роли в идентификации транзакции. Все изменения, проводимые транзакцией будут всегда характеризоваться одним и тем же идентификатором. В транзакционной таблице сегмента отката также находится ссылка на последний использованный блок отката (rba колонки в v$logmnr_contents) и признак активности/завершенности транзакции.

Если транзакция завершается аварийно, происходит откат изменений от последнего блока в usn по цепочке к первому в обратной последовательности изменений. В таблице транзакция помечается как неактивная и ей не назначается SCN, имеющий смысл system commit number. Если блок данных находится в кеше, то происходит откат "на месте", если блок был выбит из кеша, то он читается в ходе отката транзакции из датафайла в кеш и соответственно модифицируется.

При коммите, выделяется SCN (commit number), lgwr пишет журнальный буфер в журнальный файл, в транзакционную таблицу пишется выделенный номер коммита и транзакция там же помечается как неактивная. Если блок с изменениями не выбит на диск, то в itl также прописывается SCN транзакции (commit cleanout) - точный номер коммита. Если блок был выбит из кеша, то работает механизм delayed cleanout - транзакция в itl помечается как неактивная и блокировки снимаются следующими транзакциями. Тонкость в том, что не всегда возможно восстановить точный номер коммита в этом случае (переписана транзакционная таблица в USN). Тогда в блок прописывается приблизительный номер scn (минимальный, присутствующий в USN).

Замечу что вызывает какое-то внутреннее несогласие фраза "положение транзакции в сегменте отката".

Извините, ораклу наплевать на это.

Но она несколько избыточна. По сути же очень мало. Только без обид, но меня интересует только SCN - system change number.

То, что я написал - просто транзакционная архитектура оракла. Ориентироваться на scn в ней просто нельзя.

Я понял твою мыслю так, что один и тот-же SCN присваивается операторам, информация отмены для которых помещается в один сегмент?

Я этого не писал. Перечитай еще раз.

То есть возвращаясь к моему примеру, и исходя из твоих слов - для транзакции было выделено 947 сегментов отката?

Еще раз - scn это просто отметка о каком-то изменении состояния системы. В твоем примере под транзакцию был выделен только один сегмент отката, но в ходе выполнения транзакции система сменила свое состояние 947 раз. Ведь были невидимые транзакции в словаре типа выделения экстентов, переноса hwm, модификаций заголовков файлов от чекпойнтов, которые тоже приводили к увеличению scn.