Что такое oracle scn

Обновлено: 21.11.2024

SCN（Номер изменения системы），Иными словами, номер изменения системы является очень важной структурой данных в базе данных.

SCN используется для идентификации версии, отправленной базой данных в определенное время. Когда транзакция зафиксирована, ей присваивается уникальный SNN, идентифицирующий транзакцию. SCN также используется в качестве внутреннего механизма часов базы данных Oracle и может рассматриваться как логические часы. Каждая база данных имеет глобальный генератор SCN.

Как и логические часы в базе данных, транзакции базы данных сортируются в соответствии с SCN. Oracle также реализует некоторые важные функции базы данных, такие как непротиворечивость чтения на основе SCN. Кроме того, SCN также очень важен для распределенных транзакций, которые здесь не обсуждаются.

SCN уникален в базах данных и со временем увеличивается, но может быть несогласованным. Если база данных не будет перестроена, значение SCN никогда не будет сброшено до 0.

О SCN было много споров. Многие думают, что SCN означает System Commit Number, SCN обычно меняется при отправке, поэтому эти два существительных часто повторяются в документе. Даже в официальных документах Oracle SCN часто встречается в форме System Change/Commit Number. Это не самое главное слово. Важно знать, что SCN — это внутренний механизм часов Oracle. Oracle поддерживает согласованность базы данных через SCN и реализует жизненно важный механизм восстановления Oracle через SCN. SCN повсеместно используется в базах данных. Общие таблицы транзакций, управляющие файлы, заголовки файлов данных, файлы журналов и заголовки блоков данных записывают значения SCN.

С разными префиксами SCN также имеет разные имена, например SCN Checkpoint, SCN Resetlogs и т. д.

<р>2. Приобретение SCN

Текущий или приблизительный SCN базы данных можно получить несколькими способами.

<р>3. Дальнейшее объяснение SCN

Текущий SCN системы не изменяется при выполнении любой операции с базой данных. SCN обычно меняется, когда транзакция фиксируется или откатывается. SCN существует в управляющем файле, заголовке файла данных, блоке данных, заголовке файла журнала и векторе изменения файла журнала, но его функции различны.

(1) Заголовок файла данных содержит SCN контрольной точки файла данных, который представляет SCN последней операции контрольной точки файла данных.

Каждый файл данных содержит запись, в которой записано значение SCN контрольной точки файла и время возникновения контрольной точки, где SCN контрольной точки, SCN остановки и Cnt контрольной точки являются очень важными структурами данных.

<р>4. Контрольные точки

Многие документы описывают контрольно-пропускные пункты очень сложно, что создает препятствия для правильного понимания контрольно-пропускных пунктов. В результате контрольно-пропускные пункты стали очень сложной проблемой. На самом деле контрольная точка — это всего лишь событие базы данных, и ее фундаментальное значение — сокращение времени восстановления после сбоя.

При изменении данных необходимо сначала прочитать данные в память (буферный кэш). При изменении данных Oracle записывает информацию о повторении для восстановления. Из-за наличия информации повторного выполнения Oracle не нужно записывать измененные данные обратно на диск во время отправки (эффективность немедленной записи будет очень низкой), и существует повторное выполнение для восстановления данных после сбоя базы данных.

В наиболее распространенном случае может произойти сбой базы данных из-за сбоя питания, и данные, которые были изменены в памяти и еще не были записаны в файл, будут потеряны. После следующей загрузки базы данных Oracle может восстановить базу данных до ее состояния до сбоя с помощью журнала повторов (т. е. выполнить повтор транзакций), затем открыть базу данных для использования, а затем выполнить откат незафиксированных транзакций.

В этом процессе чаще всего возникает вопрос о том, сколько времени потребуется для открытия базы данных. То есть, сколько журналов повторного выполнения необходимо прочитать, чтобы выполнить повтор транзакций. Конечно, пользователи надеются, что чем короче время, тем лучше. Oracle постоянно оптимизирует процесс с помощью различных средств, чтобы сократить время восстановления.

Существуют контрольные точки для сокращения времени восстановления.

При возникновении контрольной точки (в настоящее время SCN называется контрольной точкой SCN) Oracle уведомляет процесс DBWR о необходимости записи измененных данных, т. е. грязных данных перед контрольной точкой SCN, из буферного кэша на диск. Когда запись завершена, процесс CKPT обновляет заголовок управляющего файла и файла данных и записывает контрольную точку. Информация, идентифицирующая изменения.

SCN контрольной точки можно получить из базы данных:

После завершения контрольной точки все данные, измененные до контрольной точки, записываются обратно на диск, и соответствующая запись повторного выполнения в файле журнала повторного выполнения больше не используется для восстановления после сбоя/экземпляра.

Частота контрольных точек сильно влияет на время восстановления базы данных. Если частота контрольных точек высока, журналов повторного выполнения, которые необходимо применить во время восстановления, относительно немного, и время восстановления может быть сокращено.Однако следует отметить, что внутренняя работа базы данных очень актуальна, слишком частые контрольные точки также принесут проблемы с производительностью, особенно частые обновления базы данных. Так что оптимизация базы данных — это системная инженерия, и с ней не следует торопиться.

Кроме того, если Oracle сможет сделать так, чтобы SCN контрольных точек постепенно приближался к последним изменениям Redo, когда позволяет производительность, в конечном итоге будет достигнута точка оптимального баланса, что позволит Oracle минимизировать время восстановления.

Для достижения этой цели Oracle совершенствует алгоритмы контрольных точек в различных версиях.

резюме

Выше приведено полное содержание этой статьи об Oracle SCN и контрольной точке, я надеюсь помочь вам. Заинтересованные друзья могут обратиться к: анализу фазы запуска базы данных Oracle, параметрам инструмента Oracle EBS: закрыть другие методы модификации форм, сведениям о виртуальной частной базе данных Oracle. Если у вас есть какие-либо вопросы, вы можете оставить сообщение в любое время. Xiaobian ответит вам вовремя.

Номер изменения системы (SCN) — это логическая внутренняя отметка времени, используемая базой данных Oracle. SCN упорядочивают события, происходящие в базе данных, что необходимо для удовлетворения свойств ACID транзакции.

Oracle Database использует SCN, чтобы пометить SCN, до которого известно, что все изменения находятся на диске, чтобы при восстановлении не применялся ненужный повтор. База данных также использует SCN, чтобы отметить точку, в которой для набора данных не существует повторов, чтобы можно было остановить восстановление.

SCN встречаются в монотонно возрастающей последовательности. База данных Oracle может использовать SCN как часы, поскольку наблюдаемый SCN указывает логический момент времени, а повторные наблюдения возвращают равные или большие значения. Если одно событие имеет более низкий SCN, чем другое событие, то оно произошло в более раннее время по отношению к базе данных. Несколько событий могут иметь один и тот же SCN, что означает, что они произошли в одно и то же время по отношению к базе данных.

Scn можно создать с помощью команды сохранения?

Статьи по теме

SCN и…

Транзакция

У каждой транзакции есть SCN. Например, если транзакция обновляет строку, то база данных записывает SCN, в котором произошло это обновление. Другие модификации этой транзакции имеют тот же SCN. Когда транзакция фиксируется, база данных записывает SCN для этой фиксации.

Процесс

База данных Oracle увеличивает SCN в глобальной системной области (SGA). Когда транзакция изменяет данные, база данных записывает новый SCN в сегмент данных отмены, назначенный транзакции. Затем процесс записи журнала немедленно записывает запись фиксации транзакции в оперативный журнал повторов. Запись фиксации имеет уникальный SCN транзакции. Oracle Database также использует SCN как часть своих механизмов восстановления экземпляров и носителей.

ORA_ROWSCN

Для каждой строки функция ORA_ROWSCN возвращает консервативную верхнюю границу номера системного изменения (SCN) самого последнего изменения строки. Этот псевдостолбец полезен для приблизительного определения времени последнего обновления строки. Это не совсем точно, поскольку Oracle отслеживает SCN по транзакциям, зафиксированным для блока, в котором находится строка.

Обсуждение настройки производительности Oracle, RAC, внутреннего пакета Oracle и электронного бизнеса.

Архивы

Нажмите на изображение, чтобы узнать подробности:

Ссылки на обучение, скрипты и т. п.

Оракул блога

Блогролл

SCN — что, почему и как?

Опубликовано Рияджем Шамсудином 19 января 2012 г.

В этой записи блога мы исследуем удивительный мир SCN и то, как база данных Oracle использует SCN внутри. Мы также рассмотрим несколько новых ошибок и проясним несколько неправильных представлений о самом SCN.

Что такое SCN?

SCN (номер изменения системы) — это основной механизм обеспечения согласованности данных в базе данных Oracle. SCN используется преимущественно в следующих областях, разумеется, это не полный список:

Каждая запись повтора имеет версию SCN записи повтора в заголовке повтора (а записи повтора могут иметь неуникальный SCN). При наличии повторных записей из двух потоков (как в случае с RAC) Recovery упорядочивает их в порядке SCN, по существу сохраняя строгий последовательный порядок. Как объясняется в моей статье, каждая запись повторения также имеет несколько векторов изменений.
Каждый блок данных также имеет блочный SCN (он же блочная версия). Кроме того, вектор изменения в записи повтора также имеет ожидаемый блочный SCN. Это означает, что вектор изменения может быть применен к одной и только версии блока. Код проверяет, совпадает ли целевой SCN в векторе изменений с SCN блока перед применением записи повтора. В случае несоответствия выдаются ошибки повреждения.
Консистентность чтения также использует SCN. Каждый запрос имеет среду запроса, которая включает SCN в начале запроса. Сеанс может видеть изменения транзакций только в том случае, если SCN фиксации транзакции ниже, чем SCN среды запроса.
Совершить.Каждый коммит будет генерировать SCN, также известный как коммит SCN, который отмечает границу транзакции. Также возможна групповая фиксация.

Формат SCN

SCN — это огромное число, состоящее из двух компонентов: базового и переносного. Wrap — это 16-битное число, а base — 32-битное число. Он имеет формат wrap.base. Когда база превышает 4 миллиарда, цикл увеличивается на 1. По сути, метод переноса подсчитывает количество раз, когда база обернута около 4 миллиардов. Несколько простых SQL-скриптов перечислят это лучше:

В приведенном ниже операторе SQL мы используем вызов пакета dbms_flashback, чтобы получить текущий номер изменения системы, мы также конвертируем это число в шестнадцатеричный формат, чтобы разбить SCN.

формат col curscn 999999999999999999999999

TO_CHAR(DBMS_FLASHBACK. CURSCN
———————— ————————
280000371 10737419121

Здесь шестнадцатеричное значение SCN – 0x280000371, а десятичный формат – 10737419121. Давайте рассмотрим шестнадцатеричное значение 0x280000371. Это значение можно разделить на две составляющие, лучше записать в виде 0x2.80000371, где 0x2 – перенос, а 0x80000371 – шестнадцатеричное представление базы. Чтобы проверить основу и обертку, мы можем собрать их вместе, чтобы получить значение SCN. По сути, умножьте перенос на 4 миллиарда и добавьте основание, чтобы получить SCN в числовом формате. Скрипт показывает вывод и видит, что эти два числа совпадают.

формат col n2 999999999999999999999999

Если продолжить дискуссию логически, то максимальное значение обтекания определяет максимальное значение SCN, т.е. максимальное значение обтекания*4 миллиарда = 65536* 4* мощность(2,30) = 281 474 976 710 656 = 281 триллион значений.

Увеличивает ли SCN каждое изменение?

Не обязательно. Приращение SCN не для каждого изменения. Например, в приведенном ниже скрипте мы изменим таблицу 1000 раз, но сгенерированных SCN будет очень мало.

Несмотря на то, что в таблицу было внесено 1000 изменений, SCN увеличились всего на 9. Если мы выгрузим запись повтора с помощью скрипта dump_last_log.sql (сценарий встроен в конце этого поста), то мы увидим, что записи повтора также имеют как SCN, так и SUBSCN ниже. Многие записи REDO имеют одинаковую комбинацию SCN и SUBSCN.

Ссылка на базу данных и SCNS

Транзакции на основе ссылки на базу данных также могут привести к увеличению SCN. Например, предположим, что три базы данных db1, db2 и db3 участвуют в распределенной транзакции, и допустим, что их текущий SCN равен 1000, 2000, 5000 соответственно в этих базах данных. Во время фиксации для распределенной транзакции требуется скоординированный SCN, и выбирается максимальное значение SCN из всех участвующих баз данных; Значение SCN этих трех баз данных будет увеличено до 5000.

У вас может закончиться SCN?

Как вы видели ранее, максимальное жесткое ограничение SCN составляет 281 триллион. В дополнение к этому существует также мягкое ограничение, накладываемое кодом Oracle в качестве механизма защиты. Если следующий SCN превышает мягкое ограничение, выдается ORA-600[2252] и операция отменяется. Например, в случае распределенной транзакции на основе ссылки на базу данных, если скоординированный SCN больше, чем мягкое ограничение, выдаваемое ORA-600.

Это мягкое ограничение рассчитывается по формуле (количество секунд с 01.01.1988) * 16384. Поскольку количество секунд с 01.01.1988 постоянно увеличивается, мягкое ограничение увеличивается со скоростью 16 тыс. второй непрерывно. Если ваша база данных не работает на полную мощность, генерируя более 16 000 SCN, вам не удастся так легко достичь этого мягкого ограничения. [Но вы можете создать ORA-600[2252], сбросив часы сервера на 01.01.1988].

Проблема возникает, если множество взаимосвязанных баз данных генерирует более высокую скорость в циклическом режиме. DB1 генерирует 20 000 SCN в секунду в течение первых 5 минут, DB2 генерирует 20 000 SCN в секунду в следующие 5 минут, DB3 генерирует 20 000 SCN в секунду. в секунду в течение следующих 5 минут и т. д. В этом случае все три базы данных будут иметь устойчивую скорость 20 000 SCN в секунду. База данных медленно догоняет мягкое ограничение (1 секунда каждые 4 секунды ровно), и опять же, им потребуется много лет, чтобы догнать мягкое ограничение, при условии, что базы данных активны, постоянно. Но есть печально известная, ненавидимая моим клиентом ошибка горячего резервного копирования.

(Кстати, для достижения жесткого предела потребуется 544 года, чтобы исчерпать SCN при нормальной скорости 16 КБ (65536*4*1024*1024*1024 / 16384 / 60/60/24/365)).

Вот пример ошибки ORA-600 [2252]. В приведенных ниже строках примера 2838 — это обертка SCN, а 395527372 — это основа SCN. Если мы преобразуем это в десятичный SCN, это будет в диапазоне 12 триллионов. Соединение на основе ссылки на базу данных пыталось увеличить значение SCN более чем на 12 триллионов, но оно было отклонено базой данных, поскольку SCN превышал мягкое ограничение.

Кстати, в 10 g эти 16 КБ в секунду были жестко запрограммированы. Но, 11gR2, этот предел контролируется параметром подчеркивания _max_reasonable_scn_rate, по умолчанию равным 32 КБ.

Ошибка горячего резервного копирования

Большинство администраторов баз данных используют RMAN для резервного копирования. Но, тем не менее, есть несколько баз данных, которые используют режим горячего резервного копирования, в основном из-за резервного копирования на основе дискового зеркала.Часто наблюдается более высокая скорость SCN, если база данных переведена в режим горячего резервного копирования. Массив переменных SGA отслеживает режим резервного копирования на уровне файлов. Когда вы переводите базу данных из режима резервного копирования, переменные SGA сбрасываются, и более высокая скорость SCN возвращается к нормальному состоянию. Из-за ошибки (12371955) эта переменная SGA не сбрасывается, поэтому база данных думает, что она все еще находится в режиме горячего резервного копирования. База данных генерирует SCN с большей скоростью. (если вы перезапустите базу данных позже, конечно, переменная сбрасывается на нормальную скорость). Существует способ сбросить переменную SGA, чтобы проверить, считает ли база данных в настоящее время, находится ли она в режиме горячего резервного копирования или нет.

Из-за этой ошибки очень активная база данных может создать повышенную скорость SCN более 16 КБ. В течение длительного периода времени (на самом деле, это, вероятно, займет много лет) SCN догоняет мягкий лимит. После достижения мягкого предела следующее обновление SCN вызовет ошибки ORA-660[2252]. Конечно, этот рост SCN распространяется на другие базы данных по каналу базы данных. Поскольку расчет мягкого лимита основан на времени, также важен часовой пояс сервера. Например, если значения достаточно близки к мягкому пределу, то базы данных, работающие в часовом поясе США по восточному времени, будут иметь более высокий мягкий предел на (4*60*60*16384 = 235 миллионов), чем базы данных, работающие в тихоокеанском часовом поясе.

Отсутствует опасность повреждения, сеансы могут завершиться или базы данных могут выдавать ошибки ORA-600. В редких случаях базы данных должны быть отключены в течение нескольких часов или удалены распределенные транзакции из базы данных, чтобы увеличить запас между мягким ограничением и текущим SCN.
Эта ошибка возникает, только если вы используете команду «ИЗМЕНИТЬ БАЗУ ДАННЫХ». Если вы используете команду ALTER TABLESPACE для резервного копирования, эта ошибка не затрагивает вас.
Коэффициент SCN также напрямую связан с активностью. Если база данных имеет более низкую активность, скорость SCN также ниже, даже если база данных переведена в режим резервного копирования с этой ошибкой.

Существует сценарий, выпущенный Oracle, который может сообщить вам, насколько ваша база данных близка к мягкому пределу, также известному как запас SCN. Итак, сначала проверьте, есть ли в вашей базе данных какие-либо проблемы с SCN или нет, этот скрипт доступен как ошибка 13498243 и сообщает вам, сколько дней запаса SCN у вас есть.

Как проверить скорость SCN?

Метод 1: smon_scn_time отслеживает сопоставление между временем и SCN с точностью примерно до 5 минут. Это можно использовать для измерения скорости SCN, см. код ниже. Хотя это легче проверить, помните, что нет простого способа определить, связано ли увеличение SCN с внутренней активностью в базе данных или с внешней базой данных, увеличивающей SCN за счет действия распределенной транзакции. Мы обсудим эту дифференциацию позже.

v$log_history также можно использовать для проверки скорости SCN базы данных. В приведенном ниже коде вы можете увидеть скорость SCN в секунду, запрашиваемую из v$log_history. Даже если вы работаете в RAC, запроса к v$log_history достаточно, поскольку он содержит архивные журналы всех потоков. Если есть всплеск SCN, скажем, из удаленной базы данных, вы увидите всплеск SCN в выходных данных этого запроса ниже.

В приведенных выше выходных данных SCN увеличился на 10 миллиардов между 14:27 и 14:05. Вы не можете легко различить, произошло ли это увеличение из-за внешних систем или из-за внутренней активности. В данном конкретном случае, потому что это экстремальное увеличение SCN, и я предполагаю, что оно произошло из-за внешних систем. (Но обычно такой уровень увеличения SCN не происходит на вашем производственном сайте, и мой пример просто объясняет концепцию).

Что происходит в RAC?

В RAC экземпляр, который получает обновление из внешней системы, увеличивает SCN базы данных до нового более высокого SCN. Когда другие экземпляры запрашивают следующий SCN, это увеличение SCN немедленно распространяется и на другие экземпляры.

Могут ли два потока получить один и тот же SCN?

Очевидный ответ — нет. Правильный ответ — да. Например, повторные записи из двух потоков показывают, что они имеют одинаковые SCN и subSCN. Это не проблема и не проблема, так как изменения буфера защищены кодом уровня GCS, а изменения строк защищены механизмом блокировки.

Внутренний и внешний рост SCN

Существует статистика, которая также может помочь нам определить, является ли увеличение SCN внутренним или внешним. Статистика «звонки в kcmgas» дает приблизительное количество звонков для выделения SCN. Эта статистика является только оценкой, а не абсолютным количеством сгенерированных SCN. Мы разберемся в этой статистике с помощью скрипта и вспомогательной функции.

Из выходных данных видно, что в этом сеансе различаются 857 SCN и 826 вызовов kcmgas. Могут быть другие фоновые процессы, генерирующие SCN, которые объясняют эту разницу. Даже на уровне экземпляра он не совпадает точно, но умножение статистики «вызовов kcmgas» на 1,1 дает более точную оценку.Этот метод можно использовать для определения того, является ли рост SCN внутренним или внешним в базе данных. Его также можно использовать для определения экземпляра, генерирующего больше SCN в кластере RAC, или базы данных, генерирующей больше SCN в сложной взаимосвязанной среде.

Проблема с уязвимостью SCN

Я вообще не собираюсь подробно обсуждать эту проблему с уязвимостью. Но для этой уязвимости требуется доступ к производственной базе данных. Администраторы баз данных, заботящиеся о безопасности, в любом случае не разрешают доступ к рабочей среде так легко. Так что, на мой взгляд, это проблема, которую необходимо решить, но вам понадобится злонамеренный администратор базы данных с экспертными знаниями, чтобы злоупотребить этой уязвимостью. Следуйте указаниям службы поддержки Oracle по этому вопросу, поскольку я обычно не говорю о проблемах уязвимости безопасности. Подробности здесь

Как проверить состояние горячего резервного копирования по переменным SGA

В прошлом многие из вас спрашивали меня о деталях проверки флага с помощью переменных SGA. Ниже приведен способ сделать это.

Переменная SGA kcvblg представляет собой тип данных массива и отслеживает состояние горячего резервного копирования на уровне файлов. Длина каждого элемента массива составляет 8 байт, поэтому, сделав дамп массива длиной (db_files*8), вы сможете увидеть состояние резервного копирования для каждого файла.

Если вы просмотрите файл трассировки, вы увидите следующие строки, напечатанные для массива kcvblg. Для всех элементов массива установлено значение 0, что указывает на то, что горячее резервное копирование для этих файлов данных не включено.

После перевода базы данных в режим резервного копирования мы снова делаем дамп массива kcvblg.

Из нового файла трассировки видно, что для многих элементов массива установлено значение 1, что указывает на то, что для этих файлов данных включено горячее резервное копирование. Кстати, массив kcvblg полностью выделен для размера db_files*8. Но флаг изменяется только в том случае, если для этого слота массива назначен файл данных. Итак, если у меня есть 100 файлов данных с db_files=200, то только 100 элементов изменяются на 1 или 0.

Используя этот метод, вы можете определить, включено ли горячее резервное копирование на уровне файла данных или нет. По сути, команды alter database или alter tablespace определяют все затронутые файлы данных и изменяют элемент массива kcvblg, связанный с файлом данных. Команда «alter database end backup» или «alter tablespace end backup» сбрасывает флаг на 0. Конкретная ошибка, которую я обсуждал в этом блоге, заключалась в том, что команда alter database забывает сбросить флаг, что приводит к увеличению использования SCN.

Сводка

Я откладывал публикацию этой записи в блоге уже много месяцев. Поскольку эта проблема является общедоступной, я могу поделиться информацией без каких-либо последствий. Короче говоря, важно понимать генерацию SCN и его внутренние детали. Вооружившись сценариями, вы можете просмотреть свою среду.

Скрипт Dump_last_log неправильно печатает в формате html.

печать в строке

Поддержка Oracle опубликовала заметку с описанием этой проблемы 1376995.1. Вы также можете обратиться к этому примечанию.

обновление 1: исправлено форматирование и опечатки.

обновление 2: исправлено: «По сути, умножьте основание на 4 миллиарда и добавьте перенос, чтобы получить SCN в числовом формате».
обновление 3: исправлена опечатка во фрагменте кода.
обновление 4: добавлен раздел о том, как использовать переменную SGA для проверки состояния резервной копии (этого не было в открытом доступе, когда я опубликовал его изначально, но теперь он есть и так, публикуя подробности здесь).
обновление 5: добавлен идентификатор документа MOS.

Ну, существует не МНОГО типов SCN, которые на самом деле существуют, но хранятся во многих местах с разными именами и разными целями.

SCN будет состоять только из одного числа, увеличивающегося на каждые 3?(5 секунд 10g?). Номер SCN в определенный момент записывается во множестве разных мест, чтобы помочь определить состояние базы данных. Для каждого отдельного места он записывается и для каждой отдельной цели он записывается, как правило, ему дается другое имя.

Сколько существует видов SCN? или сколько мест в магазине SCN.

В каждом блоке базы данных есть несколько мест, несколько в заголовках файлов данных, пара в управляющих файлах, некоторые в файлах журналов повторов, некоторые в сегментах UNDO/ROLLBACK и число в системном словаре. (а также некоторые другие неупомянутые пластины). Каждое местоположение в основном обеспечивает целевое «время», когда произошло важное изменение (относительно данных), что позволяет программному обеспечению базы данных восстановить этот объект до этого времени.

Есть SCN контрольной точки (конец контрольной точки), SCN фиксации (конец транзакции), SCN моментального снимка (начало запроса), SCN системы и т. д. Они в основном представляют собой последовательность целых чисел, которые Oracle использует внутри для отслеживания различных событий. и блочные версии для обеспечения согласованности чтения на уровне инструкций, многоверсионности, отката транзакций, восстановления экземпляра и т. д. и т. д. Они (системные SCN) ДЕЙСТВИТЕЛЬНО увеличиваются при внесении изменений в блоки данных независимо от состояния транзакции.Oracle различает эти SCN в зависимости от их назначения (например, вы беспокоитесь о Snapshot SCN, когда вы начинаете свой оператор. Вы беспокоитесь о COMMIT SCN, когда делаете фиксацию или откат. Вы беспокоитесь о CHECKPOINT SCN при выполнении восстановления и т. д.)< /p>

Что такое SCN? (Из поста Рияза)

Каждая запись повтора имеет версию SCN записи повтора в заголовке повтора (а записи повтора могут иметь неуникальный SCN). При наличии повторных записей из двух потоков (как в случае с RAC) Recovery упорядочивает их в порядке SCN, по существу сохраняя строгий последовательный порядок. каждая запись повтора также имеет несколько векторов изменений.
Каждый блок данных также имеет блочный SCN (он же блочная версия). Кроме того, вектор изменения в записи повтора также имеет ожидаемый блочный SCN. Это означает, что вектор изменения может быть применен к одной и только версии блока. Код проверяет, совпадает ли целевой SCN в векторе изменений с SCN блока перед применением записи повтора. В случае несоответствия выдаются ошибки повреждения.
Консистентность чтения также использует SCN. Каждый запрос имеет среду запроса, которая включает SCN в начале запроса. Сеанс может видеть изменения транзакций только в том случае, если SCN фиксации транзакции ниже, чем SCN среды запроса.
Совершить. Каждый коммит будет генерировать SCN, также известный как коммит SCN, который отмечает границу транзакции. Также возможна групповая фиксация.

Что происходит, когда транзакция фиксируется? из документации.

Для COMMIT создается номер системного изменения (SCN).
Внутренняя таблица транзакций для связанного табличного пространства отмены записывает, что транзакция зафиксирована. Соответствующий уникальный SCN транзакции назначается и записывается в таблицу транзакций. См. "Сериализуемый уровень изоляции".
Процесс записи журнала (LGWR) записывает оставшиеся записи журнала повторения в буферах журнала повторения в оперативный журнал повторения и записывает SCN транзакции в оперативный журнал повторения. Это атомарное событие представляет собой фиксацию транзакции.
Oracle Database снимает блокировки строк и таблиц.
Пользователям, которые были поставлены в очередь в ожидании блокировок, удерживаемых незафиксированной транзакцией, разрешено продолжать свою работу.
Oracle Database удаляет точки сохранения.
Oracle Database выполняет очистку фиксации.
Если измененные блоки, содержащие данные из зафиксированной транзакции, все еще находятся в SGA и никакой другой сеанс не изменяет их, то база данных удаляет из блоков информацию о транзакции, связанной с блокировкой. В идеале COMMIT очищает блоки, чтобы последующему SELECT не приходилось выполнять эту задачу.
Примечание.Поэтому очистка (полная с повтором) будет выполняться во время фиксации, если блоки все еще находятся в SGA.В активных системах это Обычно блоки с незафиксированными транзакциями записываются на диск и сбрасываются из SGA. В этом случае блок остается как есть, и следующий запрос, касающийся блока, выполнит отложенную очистку блока (ваш пункт 5 выполняется не во всех случаях).

Каждый тип SCN, их расположение, названия и назначение

Читайте также: