Ядро Oracle спроектировано так, что задачи записи сконцентрированы в небольшом количестве специализированных фоновых процессов. Большую часть операций записи Oracle осуществляют процессы DB-WR, LGWR и ARCH. В большинстве баз данных в основном выполняется чтение, а не запись. Однако многие системы подчиняются серьезным соглашениям об уровне обслуживания бизнес-функций, которые требуют обеспечения высокой эффективности записи. И даже в системах, в которых запись играет второстепенную роль по отношению к чтению, медленные операции записи могут косвенно подпортить производительность чтения. Например, низкая производительность процесса DBWR может проявиться во времени отклика запроса появлением событий free buffer waits. Избыточные операции записи могут оказаться в очереди к устройствам хранения впереди законных операций чтения, что приведет к ухудшению производительности db file sequential 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).
< Предыдущая | Следующая > |
---|