вопрос о привязке сегмента oracle undo

Question

Я не администратор баз данных, я просто хочу узнать о модели Multi-Version Concurrency Oracle.

При запуске операции DML первым шагом в протоколе MVCC является привязка сегмента отмены.Вопрос в том, почему один сегмент отмены может обслуживать только одну активную транзакцию?

спасибо за ваше время ~~

Answer 1

«почему один сегмент отмены может служить только для одной активной транзакции?»

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

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

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

Answer 2

Multi-Version Concurrency, вероятно, является наиболее важной концепцией, которую нужно понять, когда речь заходит об Oracle. Программистам полезно понимать это, даже если они не хотят становиться администраторами баз данных.

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

1. Транзакция может состоять из множества операторов и генерировать много отмен: она может вставить одну строку, она может удалить тридцать тысяч. Лучше назначить один пустой блок UNDO в начале, а не постоянно разыскивать частично заполненные блоки с достаточным пространством.
2. Вслед за этим для совместного использования блоков отмены потребуется, чтобы ядро ​​отслеживало использование с гораздо более тонкой гранулярностью, что просто добавляет сложности.
3. Когда транзакция завершается, отмена отменяется (если только см. Следующий пункт). Чем меньше блоков использовала транзакция, тем меньше защелок необходимо сбросить. Кроме того, если блоки используются совместно, нам нужно будет освободить осколки блока, что требует больше усилий.
4. Ключевым моментом в MVCC является согласованность чтения . Это означает, что все записи, возвращаемые более длинным запросом, будут отображаться в том состоянии, в котором они находились при запуске запроса. Поэтому, если я выполню команду SELECT для таблицы EMP, выполнение которой занимает пятнадцать минут, а на полпути вы фиксируете обновление всех зарплат, я не увижу ваши изменения, база данных делает это путем извлечения данных отмены из блоков, которые использовала ваша транзакция. , Опять же, это намного проще, когда все данные отмены расположены в один или два блока.