Конфликты при доступе к журналу

Эти конфликты, как и сообщения Cannot allocate new log, должен устранять администратор базы данных, как правило, совместно с системным администратором. Однако заметить их может и разработчик, если администраторы следят за сервером недостаточно внимательно. При описании важных представлений динамической производительности V$ в главе 10 мы разберемся, как понять, чего именно ждет сеанс. Часто дольше всего сеансу приходится ждать события log file sync1. Это значит, что возникают конфликты при доступе к журналам повторного выполнения; работа с ними выполняется недостаточно быстро. Это может происходить по многим причинам. Одна из причин, связанных с приложениями (ее не может устранить администратор базы данных - это должен делать разработчик), - слишком частая фиксация, например фиксация в цикле после выполнения каждого оператора INSERT. Здесь фиксация выполняется искусственно, исходя из ложного предположения, что так можно сэкономить ресурсы. Слишком частая фиксация, помимо того, что это плохая практика программирования, - еще и гарантированный способ добавить множество ожиданий доступа к журнальным файлам, поскольку придется ждать, пока процесс LGWR сбросит буферы журнала повторного выполнения на диск. Обычно процесс LGWR может это делать в фоновом режиме, и ожидать не придется. При фиксации транзакции также приходится ожидать чаше и дольше, чем это необходимо. Предполагая, что все транзакции имеют правильный размер (фиксация выполняется не чаше, чем это диктуется выполняемыми действиями), основными причинами, вызывающими ожидание доступа к файлам журнала повторного выполнения являются следующие.

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

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

Использование устройств с буферизацией. Речь идет об использовании файлов в файловой системе (вместо неформатированных дисков). Операционная система буферизует данные, СУБД тоже буферизует данные (речь идет о буфере журнала повторного выполнения). Двойная буферизация замедляет работу. По возможности используйте неформатированные устройства. Способ такого использования зависит от операционной системы и устройства, но обычно это возможно.

Размещение журнала повторного устройства на низкоскоростных дисковых массивах, например RAID-5. Массивы RAID-5 прекрасно подходят для чтения, но резко снижают производительность записи. Как было показано ранее, при фик-

сации транзакции необходимо дождаться, пока процесс LGWR сбросит данные на диск. Использование люб1х технологий, замедляющих процесс записи, - плохая идея.

Желательно использовать для журнализации пять отдельнгх устройств, оптимально - шесть, чтобы можно было выполнять резервное копирование архивов. Сегодня, при наличии дисков объемом 20, 36 и более Гбайт, это становится все сложнее, но если выделить четыре высокоскоростных диска небольшой емкости и один или два диска большей емкости, можно существенно ускорить работу процессов LGWR и ARCH. Эти диски разбиваются на три группы:

группа журналов повторного выполнения 1 - диски 1 и 3

группа журналов повторного выполнения 2 - диски 2 и 4

архив - диск 5 и, необязательно, диск 6 (диск большого объема)

Нечетные группы (1,3,5)

i: Четные группы (2,4,6)

Архивные журналы

Группу журналов повторного выполнения 1 с членами А и Б помещаете в группу 1. Группу журналов повторного выполнения 2 с членами В и Г помещаете в группу 2. Если есть группы 3, 4 и т.д., они размещаются, соответственно, на нечетной и четной группе дисков. При использовании группы 1 процесс LGWR будет записывать на диск 1 и диск 3 одновременно. При заполнении этой группы процесс LGWR перейдет к дискам 2и 4. Когда эти диски заполнятся, он вернется к дискам 1 и 3. Тем временем процесс ARCH будет обрабатывать заполненные активные журналы повторного выполнения и записывать их в группу 3 на диск большой емкости. В результате ни процесс ARCH, ни процесс LGWR никогда не читает диск, на который идет запись, и не пишет на диск, читаемый другим процессом, т.е. конфликтов нет:

Нечетные группы (1.3,5) Четные группы (2,4,6) Архивные журналы

- LGWR

Диск 1

* Диск З

: ARCH 4

Диск 2

----rl

Диск 4

LGWR

... .т. ; Диск 5 ;

Диск 6

Диск 1

Диск З

. .т .. . 1

: Диск2

..... ARCH

Диск 5

:--------Диск 4

Диск 6

Итак, когда процесс LGWR записывает группу 1, процесс ARCH читает группу 2 и записывает ее на диски архива. Когда процесс LGWR записывает группу 2, процесс ARCH читает группу 1 и записывает на диски архива. Таким образом, каждый из процессов LGWR и ARCH использует собственные отдельные устройства и не конфликтует с другими процессами.

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

Временные таблицы выполнения/отката

и данные повторного

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