Базы данных Oracle - статьи


Меры по уменьшению нагрузки на ЦП - часть 2


План выполнения:

Rows Row Source Operation --------- --------------------------------------------------- 49152 HASH JOIN 3 VIEW 3 SORT GROUP BY 114688 TABLE ACCESS FULL EMP 114688 TABLE ACCESS FULL EMP

Rows Execution Plan -------- --------------------------------------------------- 0 SELECT STATEMENT GOAL: CHOOSE 49152 HASH JOIN 3 VIEW 3 SORT (GROUP BY) 114688 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'EMP' 114688 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'EMP'

Замечание:

Для небольшой таблицы в базе данных 8.1.7 моего настольного компьютера с Windows NT 4.0 с одним одновременно работающим пользовательским сеансом фактически сбережено 3 секунды времени ЦП (14.96 - 11.96). Теперь пересчитайте это для вашей промышленной базы данных с большим количеством одновременно работающих пользователей. После переписывания коррелированных подзапросов, используя встраиваемые представления, вы получите, по крайней мере, два результата:

  1. вы написали существенно лучший и масштабируемый код; вы обнаружите, что по мере роста размеров таблиц уменьшение производительности будет линейным;
  2. в зависимости от размера таблиц, с которыми работают коррелированные подзапросы, и количества пользователей, одновременно выполняющих эти запросы, вы сбережете значительный объем ресурсов ЦП.

  • Для всех объектов в ваших табличных пространствах используйте экстенты одинакового размера, это позволит предотвратить объединение свободного пространства, выполняемое SMON. Для этих же целей в параметре хранения по умолчанию PCTINCREASE устанавливайте 0.
  • Используйте локально управляемые табличные пространства (в Oracle8i и выше), это позволит предотвратить объединение свободного пространства, выполняемое SMON.
  • Выключите автоматическое объединение свободного пространства, выполняемое SMON. Для этого вы можете установить соответствующее событие в init.ora. Дополнительную информацию поищите в Metalink или обратитесь в службу поддержки Oracle. Делайте это только после реализации экстентов одинакового размера для всех объектов в вашей базе данных.
  • Избегайте использовать в сегментах отката опцию OPTIMAL, регулярно выполняйте ручное сокращение (shrinking) сегментов отката, если обнаруживаете недостаточность дискового пространства.




Начало  Назад  Вперед