7 Сегменты отката

Сегменты отката — это структуры, данных которые сервер Oracle использует для предоставления следующих услуг:

• Непротиворечивость чтения — сегменты отката содержат информацию отката (undo) транзакций. Сервер Oracle использует информацию отката для поддержания непротиворечивости чтения запросов, использующих блоки, модифицированные (другими транзакциями) после начала транзакции.
• Автоматический откат транзакции — эта же информация отката используется для поддержания целостности данных после краха СУБД, а также при требовании пользователя отменить изменения незафиксированной транзакции.

Сегмент отката — это циклическая очередь, состоящая из блоков данных Oracle, в которые процессы сервера Oracle записывают информацию отката в течение выполнения транзакции.

Рисунок ниже демонстрирует сегмент отката с 8 экстентами, каждый из которых содержит 4 блока данных Oracle. Блок, нарисованный в центре — это заголовок сегмента отката. Стрелка, указывающая на начало третьего блока во втором экстенте определяет место, в которое будет производиться очередная запись в сегмент отката. Она называется «указатель записи» в сегменте отката и движется по часовой стрелке повторно используя блоки сегмента отката после завершения круга.

7.1 Размер сегмента отката

Ключевыми ограничениями для правильного выбора размера сегментов отката являются:

• Достаточно малый для кэширования — блоки сегментов отката загружаются и выгружаются в SGA по тем же правилам (LRU), что и другие блоки базы данных. БОльшие размеры сегментов отката заполнят бОльшую часть кэша блоков данных и, тем самым, вытеснят другие блоки данных (например, блоки данных ветвей индексов), которые улучшали бы производительность приложения. Возросшее число неуспехов в кэше блоков данных БД, вызванное б.ольшим размером сегментов отката, не только снизит качество кэша, но резко увеличивает загрузку ЦПУ и подсистемы ввода/вывода.
• Достаточно большой размер для больших транзакций — если Ваше приложение использует длительные транзакции, генерирующие сотни килобайт информации отката без фиксации, то Вы должны иметь, как минимум, один сегмент отката с таким размером, чтобы хранить всю информацию отката, создаваемую с.амой длительной Вашей транзакцией. Иначе, транзакция может завершиться с ошибкой.

Oracle7 имеет несколько возможностей, которые резко снижают сложность администрирования сегментов отката по сравнению с тем, что мы имели в Oracle6: (1) сегменты отката могут расти и сжиматься, и (2) имеется возможность перевода сегментов отката в автономный или оперативный режимы без необходимости останова инстанции.

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

• Проектирование приложения — проектируйте Ваши приложения так, чтобы большие объемы DML (особенно вставки) выполнялись с unrecoverable-опцией везде, где это допустимо. Для транзакций, которые должны выполняться в обычном режиме, проектируйте приложение таким образом, чтобы оно вызывало частые промежуточные фиксации. Если Вы не можете выполнить этого, то как минимум, для хранения информации отката, выбирайте упомянутый ранее большой сегмент отката с помощью команды set transaction use rollback segment.
• Планирование заданий — если Вы вынуждены использовать пакетные программы, выполняющие большой объем DML-операций без промежуточных фиксаций (например, предустановленные программы, которые Вы не имеете возможности настраивать), то старайтесь планировать такие задание таким образом, чтобы они не конкурировали с интенсивными параллельными процессами работающими с SGA. Для снижения накладных расходов по поддержанию непротиворечивости чтения, а также для предотвращения ошибок «snapshot too old», Вы также должны стараться разделить по времени запуск таких программ и программ читающих изменяемые данные.

Вы можете использовать следующий метод для определения оптимального размера сегментов отката для Вашей системы.

1. Убедитесь, что все оперативные сегменты отката имеют одинаковый размер. Вы можете держать несколько сегментов отката специального размера в автономном режиме для использования во временном окне, выделенном для пакетной обработки. Если Вы используете такую схему, то в начале окна пакетной обработки, Вы должны перевести небольшие OLTP-сегменты отката в автономный режим и перевести сегменты отката предназначенные для пакетной обработки в оперативный режим. После окончания окна пакетной обработки Вам необходимо выполнить обратные действия для подготовки БД к OLTP-нагрузке.
2. Выберите размер сегмента отката таким, чтобы он был достаточно большим для хранения информации отката некоторого небольшого числа k одновременно запущенных наибольших транзакций, которые Вы будете использовать в момент активности этого сегмента отката. Критерий для выбора значения k заключается в минимизации числа блоков в кэше блоков данных БД, выделенных для хранения сегмента отката. Если наибольшая транзакция генерирует менее чем один блок БД информации отката, то k = 4, 5, 6 . . . , 10.
3. Если наибольшая транзакция порождает сотни килобайт информации отката, то установите k < 4 и побеседуйте с людьми, которые разработали приложение.
4. Установите значение minextents в диапазоне от 8 до 20 для каждого сегмента отката, а также значение optimal в значение, гарантирующее, что сегмент отката не будет сокращаться менее чем до 8 (до 20) экстентов. Обратите внимание, что большое значение minextents предполагает небольшое значение для размера экстента сегмента отката.

   Использование нескольких экстентов в сегмента отката снижает частоту появления событий роста и сжатия [5, Millsap (1995b)].

7.2 Количество сегментов отката

Ограничения на количество сегментов отката подобны ограничениям на размер сегментов отката:

• Достачно малое, чтобы кэшироваться — Наличие слишком большого числа сегментов отката имеет тот же болезненный эффект на качество кэша в SGA и обработку контрольной точки, что и слишком большие размеры сегментов отката.
• Достаточно большое, чтобы избежать конкуренции — Наличие слишком малого числа сегментов отката будет причиной конкуренции за транзакционную таблицу (transaction table) сервера Oracle, которая храниться в заголовке сегмента отката. Определить наличие конкуренции за сегменты отката Вы можете с помощью показателя undo header waits из динамической таблицы производительности v$waitstat.

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

1. Выберите коэффициент достоверности C, где 0 < C < 1. К примеру, если Вы хотите получить 90% оценку, то C = 0.90.
2. Оцените максимальное число активных пользователей в момент пиковой загрузки системы. Обозначим это число пользователей как n.
3. Оцените вероятность того, произвольно взятая транзакция будет активной в случайно заданный момент. Обозначим эту вероятность как p.
4. Найдите наименьшее значение x для которого

   

   где

   

   и P(X = x) есть функция биноминального распределения Бернулли, определенная как

   

   Если Вы имеете Excel или подобный инструмент, то можете найти значение x очень просто, как показано в таблице 4.

5. После некоторого времени эксплуатации Вы можете выполнить тонкую настройку сегментов отката на основе наблюдений за таблицей v$waitstat. Если присутствует событие ожидания undo header waits, то попытайтесь решать проблему с помощью увеличения числа сегментов отката. Если событий ожидания заголовка сегмента отката нет, Вы можете удалить один или несколько сегментов отката, не оказывая влияния на производительность системы.

8 Заключение

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

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

Благодарности

Я искренне благодарю друзей за потраченное ими время и полезные комментарии: Dominic Delmolino, Greg Doherty, Tim Gorman, Todd Guay, Deepak Gupta, Gary Hallmark, Andrew Holdsworth, Phil Joel, Anjo Kolk, Mark Pavkovic, Richard Powell, Lyn Pratt, Willis Ranney, Craig Shallahamer, Hank Tullis, Hugh Ujhazy, Peter Utzig, Mitch Wallace, и Graham Wood.

Список литературы

[1] обратно	CHEN, P.; LEE, E.; GIBSON, G.; KATZ, R.; PATTERSON, D. 1994. «RAID:high-performance, reliable secondary storage» in ACM Computing Surveys, Vol. 26 No. 2 (Jun 1994).
[2] обратно	GUI, JEFFREY. 1993. «OLTP and System Reliability» in OLTP Handbook, edited by Gary McClain, Intertext/McGraw-Hill, New York NY.
[3] обратно	MAULIK, B.; PATKAR, S. 1995. «Outage recovery timings» in Technical Reports Compendium Vol. I (Dec 1995). Oracle internal document.
[4] обратно	MILLSAP, C. 1995a. «The OFA Standard-Oracle7 for Open Systems». Oracle internal document, available on-line at http://www.europa.com/~orapub/.
[5] обратно	MILLSAP, C. 1995b. «Oracle7 Server Space Management». Oracle internal document, available on-line at http://www.europa.com/~orapub/.
[6] обратно	MILLSAP, C. 1996. Selecting the Optimal Oracle Database Block Size. Oracle internal document. Not yet available on-line.
[7] обратно	Oracle7 Server Administrator’s Guide. 1996. Oracle standard product documentation, Redwood Shores CA.
[8] обратно	Oracle7 Server Concepts Manual. 1996. Oracle standard product documentation, Redwood Shores CA.
[9] обратно	PATTERSON, D.; GIBSON, G.; KATZ, R. 1988. «A case for redundant arrays of inexpensive disks (RAID)» in International Conference on Management of Data (SIGMOD). ACM, New York: 109-116.
[10] обратно	TO, L. 1995. «Outage prevention, detection, and repair» in Technical Reports Compendium Vol. I (Dec 1995). Oracle internal document.
[11] обратно	Understanding Disk Arrays. 1995. Sun Microsystems white paper, Mountain View CA.

Замечания к переводу

Перевод выполнен Михаилом Прусовым (mprusov.narod.ru/). По всем вопросам и предложениям пишите по этому адресу. Приведенная в библиографии ссылка на www.europa.com/~orapub/, по всей видимости, уже не действительны. Указанные документы можно найти либо на сайте компании Hotsos, либо на сайте http://www.orapub.com/. В обоих случаях, Вам необходимо пройти бесплатную регистрацию.