DeepEdit!

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

Конфигурирование подходящих сегментов отката важно для хорошо работа­ющей базы данных в любой среде - будь то DSS или OLTP. При отсутствии доста­точного количества сегментов отката правильно подобранного размера может пострадать производительность всей деятельности DML. Программистам и ад­министраторам баз данных неоднократно приходилось сталкиваться с ошиб­кой ORA-01555. В том, что нет достаточного количества больших сегментов отката, позволяющего избежать возникновения подобной ситуации, может и не быть вины АБД. Но много раз причиной появления ошибки оказывался способ написания кода. Попытка разрешить подобную ситуацию только с точки зрения базы данных также имеет свои ограничения. Иногда приходится изменять код.

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

избежать конкуренции за ресурсы. Когда имеют место сортировки на диске, вы­деление и высвобождение экстентов будет вызывать конкуренцию за ресурс по­становки в очередь транзакции управления памятью (ST enqueue) в загруженной работой базе данных. Правильно выбранные значения парамет­ров файла init.ora SORT_AREA_SIZE И SORT_AREA_RETAINED_SIZE миними­зируют необходимость задействования в сортировках дисковой памяти. Когда

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

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

комбинация будет служить гарантией минимальной необходимости примене­ния ресурса ST enqueue.

Нет ничего магического в управлении защелками или настройке конкуренции за них. Не такая уж это важная штука, чтобы о ней заботиться. Но, тем не
менее, ей уделяется много внимания. Совсем как скрипучее колесо! Люди буква-
льно с ума сходят, пытаясь настроить свои защелки, вместо того, чтобы определить, что же вызывает конкуренцию. Если проследить наметившуюся
тенденцию, которой следует Oracle, многие из защелок медленно, но верно пре-
вращаются в недокументированные параметры. Это означает, что пользователи не должны их трогать, пока не будет специальных рекомендаций. АБД имеет
возможность настраивать всего несколько защелок. К счастью, имеются соответствующие параметры инициализации Oracle, так что установите их соответственно и забудьте о конкуренции за защелки (по крайней мере, с точки зрения
количества        Кроме того, почти во всех случаях конкуренция за защелки является симптомом серьезной проблемы приложения, когда выполнено слишком много приведений к последовательному режиму. Придерживайтесь методологии настройки - и не думайте о конкуренции за защелки! Есть много других интересных вещей, которые требуют нашего внимания.