DeepEdit!

Чем больше буфер журнала обновлений, тем лучше. Если он имеет размер 1 Мбайт - это хорошо, но буфер размером 8 Мбайт будет еще лучше.

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

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

размеров следует избегать. Это связано с тем, что продолжение увеличения зна­чения параметра LOGBUFFER в конечном счете само по себе становится проб­лемой. Если размер этого буфера слишком велик, управление им получается

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

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

Хотя в большинстве приложений от сторонних фирм операторы SQL погребе­ны в таких глубинах, что являются недоступными для большинства АБД, все- та­ки имеются некоторые возможности настройки на уровне экземпляра, возникшие в Огас1е8, которые делают эти приложения более поддающимися на­стройке. До Огас1е8 возможности настройки таких приложений были ограни­чены созданием, модификацией (добавлением одного или нескольких столбцов или изменением типа, например переходом от 

В*-дерева к 

двоичным индексам) и удалением существующих индексов, что приводило только к ограниченному влиянию на поведение приложения. В Огас1е8 появление некоторых специфи­ческих параметров инициализации, связанных с оптимизатором, позволило

АБД контролировать поведение оптимизатора Oracle более гибким образом.

Не стоит и говорить, что такие параметры, прежде чем можно будет перенести
их в промышленную систему, должны быть тщательно проверены в вашей
домной среде.                '        

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

log writer), архиватора (ARCH) и контрольных точек. Кроме того, мы собираем­ся искать направления настройки приложений от третьих фирм, для которых

обычно недоступны тексты операторов SQL. Такого эффекта можно добиться, настраивая оптимизатор Oracle. Перейти к "оптимизации оптимизаторов" (зна­комый термин, не правда ли; но в нашем контексте он означает всего лишь на­стройку оптимизатора Oracle. - 

Прим. пер.) 

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