Checkpoint oracle что это

Обновлено: 06.07.2024

Контрольная точка создает известную надежную точку, с которой Компонент SQL Server Database Engine может начать применение изменений, содержащихся в журнале, во время восстановления после непредвиденного отключения или аварии.

Обзор

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

Компонент Database Engine поддерживает несколько типов контрольных точек: автоматические, косвенные, ручные и внутренние. Следующая таблица содержит сводку типов контрольных точек.

Параметр расширенной настройки -k SQL Server позволяет администратору базы данных регулировать поведение ввода-вывода контрольной точки с учетом пропускной способности подсистемы ввода-вывода для некоторых типов контрольных точек. Параметр настройки -k применяется к автоматическим контрольным точкам и любым другим регулируемым ручным и внутренним контрольным точкам.

Для автоматических, ручных и внутренних контрольных точек в процессе восстановления базы данных следует произвести накат только тех изменений, которые выполнены после последней контрольной точки. Это способствует сокращению времени, необходимому для восстановления базы данных.

Длительные незафиксированные транзакции увеличивают время восстановления для всех типов контрольных точек.

Взаимодействие параметров TARGET_RECOVERY_TIME и «recovery interval»

Следующая таблица описывает связь между параметром сервера sp_configure' recovery interval ' и соответствующим базе данных параметром ALTER DATABASE . TARGET_RECOVERY_TIME .

target_recovery_time	«recovery interval»	Тип используемой контрольной точки
0	0	автоматические контрольные точки, для которых целевой интервал восстановления равен 1 минуте.
0	> 0	Автоматические контрольные точки, целевой интервал восстановления которых указан с помощью пользовательского параметра sp_configure 'recovery interval' .
> 0	Неприменимо.	Косвенные контрольные точки, для которых целевое время восстановления определяется параметром TARGET_RECOVERY_TIME, выраженным в секундах.

Автоматические контрольные точки

Автоматическая контрольная точка создается каждый раз, когда число записей в журнале достигает значения, определенного Компонент Database Engine в качестве предельного количества записей, которое может быть обработано за время, заданное параметром конфигурации сервера recovery interval . Дополнительные сведения см. в статье Configure the recovery interval Server Configuration Option.

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

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

В простой модели восстановления применение автоматической контрольной точки приводит к усечению неиспользуемого раздела журнала транзакций, если усечение журнала не откладывается под действием какого-то фактора. В отличие от этого, в полной модели восстановления и модели восстановления с неполным протоколированием после установления цепочки резервных копий журнала применение автоматических контрольных точек не вызывает усечение журнала. Дополнительные сведения см. в статье Журнал транзакций (SQL Server).

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

Влияние интервала восстановления на производительность восстановления

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

Например, если в длительной транзакции потребовалось бы два часа для проведения обновлений до того, как экземпляр сервера станет недоступным, то для фактического восстановления потребуется значительно больше времени, чем обозначено параметром recovery interval , на восстановление этой длительной транзакции. Дополнительные сведения о влиянии длительных транзакций на время восстановления см. в статье Журнал транзакций (SQL Server). Дополнительные сведения о процессе восстановления см. в статье Обзор процессов восстановления (SQL Server).

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

Если восстановление обычно занимает намного больше 1 минуты при отсутствии отката длительных транзакций.

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

Если принято решение увеличить параметр recovery interval , то рекомендуется увеличивать его постепенно с небольшими приращениями и оценивать влияние каждого приращения на производительность восстановления. Этот подход важен, потому что при увеличении значения параметра recovery interval время восстановления базы данных увеличивается пропорционально указанному значению. Например, если изменяется значение параметра recovery interval , равное 10 минутам, то время выполнения восстановления увеличится приблизительно в 10 раз по сравнению со значением recovery interval , установленным равным 1 минуте.

Косвенные контрольные точки

Косвенные контрольные точки, которые были впервые введены в SQL Server 2012 (11.x), предоставляют настраиваемую на уровне баз данных альтернативу автоматическим контрольным точкам. Их можно настроить, задав параметр конфигурации базы данных целевое время восстановления. Дополнительные сведения см. в разделе Изменение целевого времени восстановления базы данных (SQL Server). В случае сбоя системы косвенные контрольные точки обеспечивают восстановление за потенциально меньшее и более предсказуемое время, чем автоматические контрольные точки. Косвенные контрольные точки имеют следующие преимущества.

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

Параметр конфигурации recovery interval использует количество транзакций для определения времени восстановления вместо косвенных контрольных точек, которые основываются на количестве "грязных" страниц. Если косвенные конечные точки включены в базе данных, получающей большое число операций DML, средство фоновой записи может начать агрессивно сбрасывать «грязные» буферы обмена на диск, чтобы гарантировать, что время, необходимое для выполнения восстановления, находится в пределах целевого периода восстановления базы данных. Это может вызвать дополнительную активность операций ввода-вывода в определенных системах, что способно привести к созданию узких мест с точки зрения производительности, если подсистема диска превысила пороговое значение операций ввода-вывода или приближается к нему.

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

При использовании косвенных контрольных точек снижаются пиковые объемы ввода-вывода, вызванные выполнением контрольных точек, поскольку измененные незафиксированные страницы постоянно записываются на диск в фоновом режиме.

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

Косвенные контрольные точки используются по умолчанию для всех новых баз данных (включая шаблоны и TempDB), созданных в SQL Server 2016 (13.x);.
Базы данных, которые были обновлены по месту или восстановлены из предыдущих версий SQL Server, будут использовать прежний режим автоматических контрольных точек, пока он не будет явно изменен на режим косвенных контрольных точек.

Улучшена масштабируемость косвенных контрольных точек.

В версиях до SQL Server 2019 (15.x) пользователи могут сталкиваться с ошибками невыполнения в планировщике при наличии базы данных, которая создает большое количество "грязных" страниц, такой как tempdb . SQL Server 2019 (15.x) предоставляет улучшенную масштабируемость косвенных контрольных точек, что должно помочь избежать подобных ошибок в базах данных с высокой рабочей нагрузкой вида UPDATE / INSERT .

Внутренние контрольные точки

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

При добавлении или удалении файлов баз данных с использованием инструкции ALTER DATABASE.

При создании резервной копии базы данных.

Явное или внутреннее создание моментального снимка базы данных для команды DBCC CHECKDB.

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

Экземпляр SQL Server останавливается путем остановки службы SQL Server (MSSQLSERVER). В результате этого действия будет создана контрольная точка для каждой базы данных в экземпляре SQL Server.

Перевод экземпляра отказоустойчивого кластера SQL Server (FCI) в режим «вне сети».

Related tasks

Изменение интервала восстановления на экземпляре сервера

Настройка косвенных контрольных точек в базе данных

Выдача команды на создание контрольной точки в базе данных вручную

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

Получить информацию о процессах в Linux, можно выполнив команду:

Посмотреть все доступные фоновые процессы Oracle можно, выполнив запрос к представлению v$BGPROCESS

Есть обязательные процессы, без которых oracle работать не сможет и необязательные. Процесс отвечающий за подключение к базе данных и для работы пользователя с ней - не является обязательным.

Обязательные процессы запускаются при старте экземпляра и остаются активными на все время его жизни.

Далее перечислим наиболее важные процессы (остальных как-то совсем не приходилось касаться):

DBWn (DataBase Writer) - записывает модифицированные данные из буферного кэша в файлы данных
LGWR (Log Writer) - записывает содержимое redolog буфера в redolog файлы.
ARCn (Archiver) – архивирует заполненные redolog журналы если такая опция включена. Не является обязательным. Жрет доп. ресурсы. Зато можно восстановить базу к любому времени когда эта опция включена. (упрощенно)
CKPT (checkpoint) – отвечает за создание контрольных точек
PMON (Process Monitor) – мониторит процессы и восстанавливает работу процессов в случае их сбоя
SMON (System Monitor) – отвечает за восстановление системы в случае сбоев
MMON (manageability monitor) - сбор статистики
.

DBWn (DataBase Writer) - записывает изменения в файлы данных

Процесс DBWn пишет изменения в данные файлы.

Но делает это при выполнении следующих условий:

Каждые 3 секунды
При создании контрольной точки
Когда некуда записывать изменения.

LGWR (Log Writer) - записывает изменения в redolog файлы

При изменениях в таблице базы данных (INSERT, UPDATE, DELETE), Oracle записывает зафиксированные и незафиксированные изменения в redo буфер в памяти.

После LGWR записывает эти изменения в redolog файлы.

Но делает это не сразу а при выполнении следующих условий:

Каждые 3 секунды
Сразу после фиксации транзакции
Когда redolog буфер заполнен на треть (. так написано, я сам хз.)
DBWn (DataBase Writer) - сообщает о необходимости записи redolog журнала на диск. DBWn сигнализирует LGWR, чтобы тот сначала записал свою информацию, чтобы потом DBWn мог записать на диск свою собственную информацию.
Пользователь вводит команды вроде: alter system switch logfile для переключения группы

Запись выполняется во все файлы входящие в группу. Обычно делают 3 группы по 2 файла.

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

Если непонятно написано, см. пример установки oracle. Там и добавление файлов в группы и переключение и д.р.

ARCn - записывает изменения в archivelog файлы (если включен)

При включенном режиме работы Archivelog, копия redolog журнала сохраняется на диске и при этом еще и архивируется.

Вот собственно этот процесс и занимается этим.

CKPT (checkpoint)

Отвечает за синхронизацию информации буферного кэша с информацией на диске.

CKPT сообщает DBWn, что ему следует записывать «грязные» данные в файлы на диск.

После этого он обновляет заголовки файла данных и control файла, внося туда детали контрольной точки.

Каждая запись контрольной точки состоит из списка всех активных транзакций и адреса последней записи журнала для этих транзакций.

Что происходит при создании контрольной точки:

Запись содержимого буферов redolog в redolog файлы
Внесение записи контрольной точки в redolog файл
Запись буферного кэша в файл данных
Обновление заголовков файла данных и control файлов после завершения контрольной точки.

Контрольную точку можно создать самостоятельно и при необходимости откатиться на нее.

могут влиять на то, как быстро redo log переходит из состояния ACTIVE в INACTIVE?

1. Разобраться с redo - такой постоянный поток информации в журналы не нормален, если только вы, к примеру, не сотовый оператор Нью-Йорка и сегодня не 11 сентября;
2. Раскидать информацию по нескольким дискам, запустить несколько процессов DBWR (если на компе несколько процев);
3. Каждый файл из журнальной группы должен лежать на отдельном физическом диске; если диск один, то почти нет смысла иметь больше одного файла в журнальной группе, а с точки производительности это очень плохо;
4. Если у вас такой поток данных идет, к примеру, только днем, то можно создать побольше журнальных групп из файлов КАК МОЖНО БОЛЬШЕГО размера. Цель - сделать так, чтобы в течение времени интенсивной нагрузки Oracle не успел дойти до записи в ту журн. группу, с которой эта нагрузка началась. Кстати, если добиться этого и делать ежедневный backup, то режим архивирования можно не включать (то есть, добиться того, чтобы между двумя бэкапами не происходила перезапись ни одной из журнальной группы);
5. Установить log_checkpoint_interval =0, log_checkpoint_timeout =0 чтобы не было дополнительных контрольных точек. Если будет делаться пункт 4, то это обязательно;
6. Установить в init.ora параметр Transction_auditing=false (в названии могу немного ошибиться - сижу дома, Oracle дома еще не поставил :-) Это слегка уменьшит объем redo

спасибо большое за подробные объяснения.

1. под это дело в понедельник поставлю LogMiner. так мы и думали, что все из-за Бен-Ладена, давно под подозрением ходит:))
2. ситуация такая: в сервере стоит 2 процессора и (пока) один винчестер, есть ли смысл в такой ситуации запускать 2 DBWR процесса?
3. согласен, но реальность такова, что даже индексы и данные не всегда получается разделить по дискам. (
4. согласен. думаю в понедельник уменьшить частоту переключений redo logs до 1 раза в 15-20 мин.
5. тут возник побочный вопрос (некоторое сомнение) - checkpoints которые генерятся из-за параметров log_checkpoint_interval и log_checkpoint_timeout - они генерятся отсчитываясь от последнего checkpoint'а (вне зависимости от того какое событие вызвало последний checkpoint), произошедшего в системе? (то есть если положим у меня происходит переключение redo logs каждую минуту, а log_checkpoint_timeout=30 минутам, то будет ли каждые 30 минут происходит дополнительный checkpoint?)
..вообще сейчас понял, что понять это надо будет просто поставить LOG_CHECKPOINTS_TO_ALERT в true и посмотреть alert.log.

6. я так понимаю, это нужно более для подробного анализа с помощью LogMiner, а не для уменьшения объема redo?

2. Если есть только 1 HDD, то ничего существенно но поможет, кроме уменьшения кол-ва redo в разы. Надо делать upgrade, добавлять диски. А до обновления сервера у вас то же самое было? Уменьшение redo - процесс нелегкий, все зависит от приложений. Например, помогает вынос commit за пределы цикла FOR LOOP, удаление не очень нужных индексов и т.д.

What you wrote is mainly correct, but .

<quote>
В момент переключения происходит запуск выполнения контрольной точки (checkpoint), а Oracle начинает писать в новую журнальную группу, если она НЕ Active. Выполнение контрольной точки - большая пиковая нагрузка на сервер. При ее выполнении на диски сбрасываются ВСЕ "грязные" блоки данных, в заголовки файлов данных пишется SCN на момент выполнения контрольной точки, пишется информация в управляющий файл
</quote>

This is not quite what happens with respect to checkpointing. The description is almost correct regarding Oracle 7's interval checkpointing (with some caveats): accumulated dirty blocks resulted in excessive I/O spikes during interval checkpoints.

Starting with version 8.0.x, Oracle decided to spread checkpoint I/O load more evenly by trickling dirty blocks to a disk more aggressively. The new approach is called incremental checkpointing wherein ckeckpointing occurs continuously and its ratio is controlled (in addition to some other factors) by log_checkpoint_interval and log_checkpoint_timeout.

<quote>
5. Установить log_checkpoint_interval =0, log_checkpoint_timeout =0 чтобы не было дополнительных
</quote>

This recommendation is debatable (by the way, the same effect can be achieved by removing the parameters from init.ora altogether).

Essentially, what you are trying to achive is to revert to the old Oracle 7's behaviour -- instead of spreading checkpointing more or less evenly in time between log switches you'd like to have spikes during redo log switches. It may make sense, say, if you switch a couple times, at night, to avoid checkpoint I/O load performance impact. I am not sure whether this scenario is realistic so, in my opinion, spreading I/O by judicious use of the above two parameters makes more sense.

Besides, you cannot entirely avoid incremental checkpointing in 8i/9i by disabling those two parameters. With log_checkpoint_interval and log_checkpoint_timeout disabled, Oracle would use the fast_start_* parameters (see Reference). Only by disabling the fast_start_* parameters, would you achieve a semblance of old Oracle 7's behaviour.

<quote>
5. тут возник побочный вопрос (некоторое сомнение) - checkpoints которые генерятся из-за параметров log_checkpoint_interval и log_checkpoint_timeout - они генерятся отсчитываясь от последнего checkpoint'а (вне зависимости от того какое событие вызвало последний checkpoint), произошедшего в системе? (то есть если положим у меня происходит переключение redo logs каждую минуту, а log_checkpoint_timeout=30 минутам, то будет ли каждые 30 минут происходит дополнительный checkpoint?)
</quote>

1. with log_checkpoint_timeout=600, you tell Oracle (version>=8) that no block shoud remain unwritten if the change happened more than 10 min ago.

The lower both of those parameters are, the more aggressive incremental checkpointing is. Zero, however, disables these parameters entirely.

<quote>
..вообще сейчас понял, что понять это надо будет просто поставить LOG_CHECKPOINTS_TO_ALERT в true и посмотреть alert.log.
</quote>

(Un)fortunately, Oracle does not log incremental checkpointing.

<quote>
верно ли то, что 10 redo logs перейдут из состояние ACTIVE в INACTIVE?
</quote>

A filled redo log becomes inactive only when the checkpoint it is covering
completes. Then, the log file is not needed any more and thus becomes inactive because all the blocks it was protecting have been written to the disk.

As a practical recommendation, the first thing one should do would be to separate redo from the datafiles as you're experiencing heavy contention between LGWR and DBWR.

Of course, you need to figure ou why so much redo is generated in the first place.

2 vc123
просто в дополнение: еще раз внимательно перечитал документацию про LOG_CHECKPOINT_INTERVAL:

Regardless of this value, a checkpoint always occurs when switching from one online redo
log file to another. Therefore, if the value exceeds the actual redo log file size, checkpoints
occur only when switching logs.

<quote>
просто в дополнение: еще раз внимательно перечитал документацию про LOG_CHECKPOINT_INTERVAL:

This is not true if we are talking about Oracle >=8i. As I said before, in order to disable incremental checkpointing between log switches, one has to disable _all_ of these:

LOG_CHECKPOINT_INTERVAL
LOG_CHECKPOINT_TIMEOUT
FAST_START_*

Also, if "LOG_CHECKPOINT_INTERVAL. exceeds the actual redo log file size", Oracle will cap it at 90% of the smallest log to ensure that the checkpoint happens _before_ the log switch. I think it's a bug in the documentation..

<quote>
еще такой вопрос, важный для понимания, остался: вы не знаете, если в момент выполнения checkpoint'а приходит задание выполнить еще один checkpoint, то как ведет себя Oracle - ставит последний checkpoint в очередь или бросает первый недоделанный chekpoint и начинает выполнять второй?
</quote>

Under Oracle 7, the current checkpoint was indeed aborted and a new one was initiated (if the old checkpoint did not complete on time). Under 8i, because of the way the dirty blocks are linked in a checkpoint queue (in order), this is no longer necessary and a new checkpoint simply takes over from the place the old one left off.

One also should remember that DBWR writes not only during checkpoints. It fires off:

1. If there is too many dirty buffers.
2. If there is too few free buffers.
3. Every 3 seconds to check if there is enough dirty buffers to flush.
4. At a checkpoint.

1. I would not try to tune the database in during 'abnormal' situation but would try to understand/resolve the problem first.
2. In my experience, disabling incremental checkpointing usually caused performance degradation. Of course, benchmarking is the final arbiter.

Производительность процесса LGWR является критической для скорости работы OLTP-систем и процедур загрузки данных которые не используют возможность работы в режиме «без восстановления» (unrecoverable). В средах, где не выполняются интенсивные изменения в базе данных с помощью стандартных операторов SQL, LGWR не испытывает значительной нагрузки. Деградация производительности и/или увеличение времени простоя будут наблюдаться главным образом в высокоинтенсивных OLTP-системах; именно поэтому задача конфигурирования журнальных файлов является темой этого раздела.

4.1 Баланс производительности и доступности

Борьба между производительностью и надежностью особенно ярко проявляется на примере журнальных файлов. Для оптимизации производительности Вам необходимо конфигурировать LGWR и DBWR так, чтобы операции записи выполнялись как можно реже. Однако для минимизации времени, необходимого для выполнения доката данных (roll-forward) при восстановлении инстанции, Вам необходимо конфигурировать LGWR и DBWR так, чтобы операции записи производились как можно чаще. Решение этой проблемы заключается в достаточном понимании технологий для того, чтобы выбрать значение параметра log_checkpoint_interval, которое было бы и достаточно большим и достаточно малым для удовлетворения обоих требований.

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

4.2 Контрольные точки сервера Oracle

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

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

4.3 Восстановление инстанции сервера Oracle

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

Реализация отложенного, «по требованию», отката в Oracle 7.3 делает период недоступности кластера зависящим, в основном, от времени которое необходимо для реконструкции буферного кэша. Диаграмма, сравнивающая время восстановления после отказа в Oracle 7.3 и Oracle 7.2, приведена на рисунке 2.

Рис. 2. Временная диаграмма восстановления после отказа для параллельного сервера Oracle 7.2 и 7.3. OPS 7.3 откладывает откат транзакций для минимизации периода недоступности кластера при отказе узла, что дает улучшение производительности восстановления по сравнению с OPS 7.2 или ниже. В OPS 7.3 время завершения отката инстанции не связано с доступностью приложений, поскольку все откаты запускаются «по требованию», на уровне транзакций.

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

На первый фактор, в основном, влияет скорость генерации redo-информации и частота выполнения контрольных точек. Уменьшение объема генерируемой redo-информации является задачей разработчика приложения и связано с минимизацией «веса» транзакций, минимизацией числа транзакций, необходимых для достижения требований бизнеса и использованием там, где это допустимо, режима работы без восстановления. Уменьшение частоты выполнения контрольных точек достигается изменением параметра, определяющего интервал между контрольным точками или, возможно, увеличением размера журнального файла.

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

Меняя параметр log_checkpoint_interval в диапазоне от нескольких килобайт до нескольких сотен мегабайт (в блоках операционной системы) можно достичь приемлемого компромисса с производительностью в OLTP-среде. Скорость доката при восстановлении варьируется почти также как кардинально, как и требования к скорости доката 12 . В средах с жестко заданными требованиями к производительности и надежности малое изменение log_checkpoint_interval может привести к значительному изменению времени восстановления инстанции. Вследствие этого поиск оптимального значения log_checkpoint_interval часто требует тестирования в среде эксплуатации.

4.4 Размещение журнальных файлов

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

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

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

Надежность лучше — ленточный накопи тель существенно менее надежен, чем диск. Оставлять лишь одну копию критически важного файла на ленточном носителе является не очень хорошим решением.
Пропускная способность лучше — вы должны помнить, что ARCH-процесс не является чисто потоковым процессом копирования, но выполняется лучше на устройствах с возможностью произвольного доступа (random I/O). Архивирование на диск выполняется намного быстрее чем на ленточный накопитель, что в свою очередь снижает вероятность возникновения ненужного «узкого места».
Управление ошибками лучшее — управление дисковыми устройствами, при переполнении, много надежней, чем ленточными устройствами. Управление пространством для дисков может быть автоматизировано с помощью программного обеспечения, в то время как для ленточных устройств требуется вмешательство человека.
Время восстановления быстрее — многие администраторы БД хранят максимально возможное число архивных журнальных файлов на дисках, которые могут быть необходимы для восстановления с момента последнего «горячего» копирования. Такая техника уменьшает продолжительность процесса восстановления на время необходимое для нахождения требуемой ленты, ее монтирования и чтения с нее архивных журнальных файлов на диск.

4.5 Размер журнального файла

Определите требования к времени восстановления после краха. Обозначим это время, заданное в секундах, как t.
Рассчитайте скорость, с которой система применяет redo-информацию при восстановлении инстанции. Обозначим эту скорость, заданную в байтах в секунду, как r.
Установите значение параметра log_checkpoint_interval в r × t/b, где b — размер блока ввода/вывода в байтах в Вашей операционной системе.
Создайте журнальные файлы размером f = k × r × t, для некоторого целого k (т.е. f кратно r × t).
Если новые контрольные точки накапливаются без завершения предыдущих, то Вы должны увеличить значение log_checkpoint_interval. Вы можете определить частоту возникновения таких ситуаций сравнив значения статистик background_checkpoints_started и background_checkpoints_completed из v$sysstat. Если значения отличаются более чем на 1, значит контрольные точки не завершались к тому моменту, когда начинались новые.
Установите log_buffer в l = 3×n×s, где n — число дисков в массиве, хранящем журнальные файлы и s — размер сегмента чередования массива в байтах. Наибольший размер операции записи, генерируемый LGWR, будет примерно равен l/3 = n × s13 .

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

снижение стоимости отказа, связанной с потерей всех копий активного журнального файла 14 ;
улучшение гибкости в предотвращении ситуации переполнения файловой системы, хранящей архивные журнальные файлы;
снижение потерь данных в конфигурациях с резервной (standby) БД.

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

4.6 Число журнальных файлов

Ожидания занятой контрольной точки (checkpoint busy wait) — ожидание занятой контрольной точки возникает, когда LGWR пытается переключиться на журнальный файл до того, как связанная с этим журнальным файлом предыдущая контрольная точка была завершена.
Ожидание занятого процесса архивирования (archiver busy wait) — ожидание занятого процесса архивирования возникает, когда LGWR пытается переключиться на журнальный файл, который еще не было скопирован в архивный журнальный файл процессом ARCH.

Проверьте событие log file switch (checkpoint incomplete) в v$session_wait. Если Вы установили параметр log_checkpoints_to_alert в значение true, то Вы можете определить возникновение этой ситуации с помощью текстового вхождения «cannot allocate» в файле alert.log.
Снизить частоту возникновения события ожидания контрольной точки Вы можете:
- увеличивая число оперативных журнальных файлов для снижения вероятности того, что LGWR сможет заполнить все файлы до того, как будет завершена контрольная точка; или
- добавляя DBWR процессы для увеличения скорости выполнения контрольной точки (только если Вы используете синхронную запись); или
- увеличивая значение параметра db_block_checkpoint_batch для увеличения скорости выполнения контрольной точки; или
- уменьшая значение параметра db_block_buffers для снижения объема работы в контрольной точке; или
- снижая число и размеры сегментов отката в базе данных (описанных в нижеследующем разделе)

Событие ожидания занятого процесса архивирования обычно возникает при генерации большого числа транзакций во время пакетной обработке, когда скорость записи redo-информации LGWR превышают возможности копирования процесса ARCH. Оно также служит причиной возникновения ожидания контрольной точки — ARCH становится «узким местом» для завершения всех транзакций в системе.

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