DeepEdit!

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

Прим. пер.) 

мы бу­дем иметь дело не только с 

экземпляром Oracle, 

но и с 

базой данных Oracle. 

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

торые Oracle проверяет, все ли у него в хозяйстве синхронизировано. Естест­венно, что они регулярно выполняются в те моменты, когда происходит переключение журналов, а также в любой из моментов, когда АБД выдает команду alter system checkpoint. При этом в базе данных создаются и записыва­ются известные точки синхронизации, что существенно облегчает восстановле­ние в случае сбоя экземпляра или носителя информации. Случайно оказалось, что полезно выполнять их более часто, чем предполагалось. Чтобы увеличить частоту выполнения контрольных точек, следует использовать параметры ини-

циализации Oracle        или

TIMEOUT. Первый из них ориентирован на ввод/вывод и устанавливается рав­ным числу блоков ОС с информацией, которую нужно записать в буфер журнала обновлений, прежде чем стартует контрольная точка. Второй привязан ко времени и неявно контролирует продолжительность периода, в течение которого

грязные (модифицированные) блоки могут находиться в кэше буфера базы дан-

ных. В        определение параметра        было изменено.

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

во время 

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

перед 

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

В своей производственной деятельности нам приходилось конфигурировать
параметр        либо на достаточно большое число,

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

чанию (0 во всех версиях, кроме        где он равен 1800), чтобы настраивае-

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

В версии 7.3 (и более ранних) можно попытаться получить помощь в вопро­се о контрольных точках и повысить их эффективность, установив CHECKPOINT PROCESS=TRUE. При этом стартует процесс СКРТ, который выполняет некоторые операции, связанные с контрольными точками, и умень­шает рабочую нагрузку на LGWR. Следует отметить, что процесс СКРТ только

обновляет заголовки файлов данных, файлов журналов обновлений и управля-
ющих файлов, но не выполняет самого процесса контрольной точки (выталки-
вание на диск грязных блоков всегда выполняется процессом        В
СКРТ является одним из обязательных процессов. Но это не что можно
не беспокоиться об эффективности контрольных точек в Огас1е8 и более позд-
них версиях. Следует обратить внимание на то, сколько времени требуется для
завершения контрольной точки. Это особенно важно, если у настраиваемой БД
бывают периоды высокой активности операций DML. При этом могут более ча-
сто переключаться файлы журналов и чаще выполняться контрольные точки.
Для того чтобы регистрировать время начала и окончания контрольных точек
в журнале предупреждений системы, установите равным TRUE параметр
LOG_CHECKPOINTS_TO_ALERT. Такая информация подскажет, какова часто-
та выполняющихся в системе контрольных точек и продолжительность каждой
из них.

Начиная с процесс СКРТ через каждые три секунды посылает в управляющий файл контрольные сообщения. Кроме того, СКРТ записывает в управляющий файл информацию о развитии процесса контрольной точки.

В тех случаях, когда с процессом контрольной точки        происходит,

Oracle генерирует сообщение в журнале предупреждений. Многие АБД видели фразу "checkpoint not complete" (не завершена контрольная точка) и задумыва­лись, что же это значит и что им делать, чтобы урегулировать ситуацию. Такое предупреждение генерируется в те моменты, когда Oracle готов переписать журнал сообщений (т. е. затереть его старое содержание новой информацией. -

Прим. пер.), 

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