DeepEdit!

Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Оптимизация записи


Ядро Oracle спроектировано так, что задачи записи сконцентрированы в небольшом количестве специализированных фоновых процессов. Большую часть операций записи Oracle осуществляют процессы DB-WR, LGWR и ARCH. В большинстве баз данных в основном выполня­ется чтение, а не запись. Однако многие системы подчиняются серьез­ным соглашениям об уровне обслуживания бизнес-функций, которые требуют обеспечения высокой эффективности записи. И даже в системах, в которых запись играет второстепенную роль по отношению к чтению, медленные операции записи могут косвенно подпортить производительность чтения. Например, низкая производительность процесса DBWR может проявиться во времени отклика запроса появ­лением событий free buffer waits. Избыточные операции записи могут оказаться в очереди к устройствам хранения впереди законных опера­ций чтения, что приведет к ухудшению производительности db file se­quential read, db file scattered read или direct path read.
Существует несколько способов повышения производительности запи­си DBWR, LGWR и ARCH за счет оптимизации рабочей нагрузки. Ча­ще всего необходимая оптимизация заключается в избавлении от не­нужных операций LIO (см. раздел «Оптимизация логического ввода/ вывода»). Лишние операции LIO могут привести к появлению ненуж­ных вызовов чтения операционной системы, которые могут занять в очереди место перед вызовами записи DBWR, что может привести к более длительным, чем ожидалось, задержкам для операций db file single write и db file parallel write, исполняемых процессом DBWR.
Следует убедиться, что все операции записи, выполняемые приложе­нием, на самом деле необходимы. Существует множество коварных причин, по которым приложение может генерировать больше вызовов записи, чем нужно, например:
Ядро Oracle формирует данные отката/восстановления для каждого индексного блока, изменяемого командой INSERT, UPDATE или DELETE, поэтому наличие лишних индексов может привести к формирова­нию множества ненужных данных отката в системах обработки транзакций. Например, вставка в таблицу с тремя индексами созда­ет приблизительно в десять раз большую нагрузку, чем вставка в не-индексированную таблицу [Ensor and Stevenson (1997a), 147].
Некоторые приложения формируют ненужные данные отката, уста­навливая значения столбцов в их текущие значения. Например, убедитесь, что в команде SQL, которая изменяет значение статуса с N на Y на основании проверки некоторых условий, инструкция WHERE содержит предикат AND STATUS='N'. Автоматические генерато­ры приложений часто заменяют значения столбцов на уже имею­щиеся. Это происходит при формировании команды UPDATE, которая обновляет каждый столбец, имеющий значение, приведенное на те­кущем экране. Значениями с экрана следует обновлять значения лишь тех столбцов, которые были изменены пользователем, а не всех столбцов.
Пользователи приложений и администраторы базы данных могут выполнять операции для таблиц и индексов, по умолчанию поме­ченные как LOGGING, хотя могли бы работать так же хорошо, будучи помечены как NOLOGGING. (Ключевые слова LOGGING и NOLOGGING заме­няют устаревшие RECOVERABLE и UNRECOVERABLE.)
Если действительно необходимо, чтобы операцию можно было восстановить, то не надо задавать значение NOLOGGING. Допустим, вы не хотите использовать операции, помеченные как NOLOGGING, для базы данных, включенной в конфигурацию постоянного ре­зервирования (hot standby architecture). Oracle9i предлагает ре­жим FORCE LOGGING как замену параметра NOLOGGING.
Выбор конфигурации системы также влияет на степень ее загружен­ности. Например, дисковые конфигурации RAID уровня 5 особенно уязвимы для ожиданий, вызванных операциями записи. Каждая за­пись, выполняемая процессом Oracle DBWR - это поблочная запись, которую массив RAID уровня 5 обрабатывает чрезвычайно неэффек­тивно, если только он не был сконфигурирован с достаточным объе­мом кэша. Когда при интенсивной непрерывной записи оказывается, что объем кэша недостаточен, производительность дискового массива RAID уровня 5 ухудшается приблизительно в четыре раза по сравне­нию с ожидаемой. Лучшее решение состоит в том, чтобы избавиться от такого объема лишней нагрузки, снизив скорость постоянного ввода/ вывода до приемлемого уровня. Если это невозможно, то можно вы­брать один из предлагаемых ниже путей:
Увеличить размер кэша (на самом деле это лишь отложит возник­новение проблемы, но не исключено, что удастся отложить ее как раз на столько, чтобы преодолеть время пиковой нагрузки ввода/ вывода приложения).
Увеличить количество дисковых групп RAID уровня 5, предназна­ченных для обслуживания запросов ввода и вывода приложения.
Выбрать другой RAID-массив, обеспечивающий более высокую производительность ввода/вывода без приобретения дополнитель­ных дисков или памяти. Можно, например, применить чередование данных (striping) и зеркалирование (mirroring).

 









jAntivirus