Отправляет email-рассылки с помощью сервиса Sendsay

Открыто о СУБД Oracle на русском

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "СУБД Oracle "с нуля"" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

  Июнь 2002   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Автор
Сергей

Статистика

10.773 подписчиков
-8 за неделю
←   Все выпуски   →

Открыто о СУБД Oracle на русском Unix + Oracle = Ixora


Информационный Канал Subscribe.Ru

Выпуск 3

Unix + Oracle = Ixora

Уважаемые подписчики! Этот выпуск посвящен обзору новых материалов на одном из наиболее полезных сайтов для администраторов баз данных Oracle - на австралийском сайте Ixora.

В мае на сайте Ixora Стив Адамс (Steve Adams) опубликовал пару новых материалов. Их перевод с моими комментариями представлен в этом выпуске рассылки.

Проверка контрольных точек

При переключении журнала во время интенсивной генерации информации повторного выполнения вполне нормально, что в кэше содержится большое количество грязных буферов, которые необходимо записать на диск при обработке контрольной точки, вызванной переключением журнала (log switch checkpoint). Объем ввода/вывода, который должны выполнить процессы DBWn для обработки контрольной точки, может превышать половину размера буферного кэша.

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

Если процесс LGWR таки заполнил оставшиеся файлы журнала повторного выполнения прежде, чем процессы DBWn закончат записи блоков для исходной контрольной точки, вызванной переключением журнала, следующее переключение будет заблокировано, а генерация информации повторного выполнения - невозможна до заврешения обработки контрольной точки и переключения журнала. Это, несомненно, катастрофически скажется на производительности при обработке транзакций. Процессы, генерирующие информацию повторного выполнения, будут ждать события переключения журнала (завершения обработки контрольной точки, и в файл alert.log будет выдано сообщение следующего вида.

Thread 1 cannot allocate new log, sequence 82315 
Checkpoint not complete

Такие случаи можно предотвратить либо за счет оптимизации работы процессов DBWn, либо за счет существенного увеличения пространства в каждом из журналов повторного выполнения (чтобы они были в несколько раз больше, чем объем буферного кэша). Конечно, для максимальной защиты надо сделать и то, и другое.

Я недавно обнаружил, что, начиная с Oracle8i в таблице X$TARGETRBA хранится запись о максимальной продолжительности обработки контрольной точки любой из нитей, выраженная в количестве блоков журнала. Эта информация очень полезна для определения того, насколько близко вы были от описанной ситуации в ходе работы экземпляра. Сравнивая максимальную продолжительность обработки контрольной точки с интервалом запросов обработки контрольной точки, который в блоках измеряется как суммарный объем всех журнальных файлов, кроме одного, можно определить, какой запас в процентах имела наиболее медленно обрабатывшаяся контрольная точка. Если запас составляет менее 100%, значит, либо надо повышать производительность работы процессов DBWn, либо увеличивать размер файлов журнала повторного выполнения, либо делать и то, и другое. На сайте Ixora представлен новый сценарий, который выполняет это вычисление.

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

В.К.  

Хватит ли места при архивировании журнала...

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

Для большинства экземпляров необходимо три и более журнальных файла. Иначе, если их будет только два, A и B, и если средство/сценарий резервного копирования попытается переключиться с B на A вскоре после обычного переключения журналов с A на B, или если всплеск генерации информации повторного выполнения cвызовет переключение с A на B, и затем быстро заполнить весь журнальный файл B, то процесс ARCn может не успеть завершить архивирование журнального файла A.

Есть множество причин, почему процесс LGWR может заполнять журнальный файл быстрее, чем процесс ARCn будет архивировать журнальный файл такого же размера. Процесс LGWR читает данные из памяти, а процесс ARCn - с диска. Кроме того, LGWR может записывать в журналы на неформатированных устройствах, а ARCn - в файловую систему. Это часто означает, что процесс LGWR может выполнять запись асинхронно, а ARCn нет. Далее, процесс LGWR перезаписывает существующий файл, тогда как процессу ARCn постоянно приходится увеличивать записываемый файл. Для этого требуются существенные дополнительные накладные расходы на управление пространством в файловой системе, что более чем в два раза увеличивает время записи файла. Так что когда информация повторного выполнения генерируется достаточно быстро, процесс LGWR вполне может записывать быстрее, чем процесс ARCn будет копировать, даже если копирование это процесс ARCn выполняет только в одном экземпляре. Нагрузка на процесс ARCn может быть еще больше, если архивировать журнальные файлы надо в несколько мест. Дело в том, что журнальный файл копируется во все места одним процессом ARCn, даже если имеется несколько таких процессов.

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

Thread 1 cannot allocate new log, sequence 82324 
All online logs needed archiving

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

На сайте Ixora появился еще один новый сценарий, сравнивающий время, затраченное на архивирование каждого журнального файла (которое берется из представления V$ARCHIVED_LOG), с временем до переключения журнала на этот файл, и выдающий процент запаса для самой продолжительной из выполненных операций архивирования. Если запас составляет менее 50%, надо либо настраивать производительность архивирования, либо увеличивать количество журнальных файлов, либо делать и то, и другое.

Этот сценарий, с переведенными комментариями и удаленными стандартными для Адамса вызовами, представлен также ниже:

-------------------------------------------------------------------------------
--
-- Сценарий: archival_headroom.sql
-- Назначение: показать, сколько запаса по времени остается при самом
-- продолжительном архивировании
-- Версии: 8.0 и далее
--
-- Copyright: (c) Ixora Pty Ltd
-- Автор: Steve Adams
--
-- Описание: Сравнивает время, потраченное на каждое архивирование журнала,
-- со временем до переключения журнала, приводящего к перезаписи файла,
-- и выдает наименьший запас.
--
-------------------------------------------------------------------------------
select
  substr(to_char(100 * headroom, '9999999999999.00'), 2) || '%'  min_headroom,
  round(arch_time * 24 * 60, 2)  archival_minutes,
  round(arch_window * 24 * 60, 2)  archival_window
from
  ( select
      b.next_time - a.next_time        arch_window,
      a.completion_time - a.next_time  arch_time,
      (b.next_time - a.next_time) / (a.completion_time - a.next_time) - 1
        headroom
    from
      sys.v_$thread  t,
      sys.v_$archived_log  a,
      sys.v_$archived_log  b
    where
      a.completion_time > a.next_time and
      b.sequence# = a.sequence# + t.groups - 1
    order by
      3
  )
where
  rownum = 1
/

Его использование я прокомментирую в одном из последующих выпусков

В.К.  

В следующем выпуске

Следующий выпуск будет посвящен очередным ответам дяди Тома на вопросы неугомонных ораклоидов. Следите за новостями на сайте проекта Open Oracle.

С наилучшими пожеланиями,

  В.К.

http://subscribe.ru/
E-mail: ask@subscribe.ru 		Отписаться
Убрать рекламу
В избранное