gbms_stats.gather_system_stats

Давно это было ...
Был такой случай - после миграции СУБД с 9 на 10 стал медленно работать SAP.
Продуктив - около 1Тб, 15 тыс пользователей, 500 активных сессий.

В процессе уяснения для себя проблемы вяснилось, что многие планы "поплыли", и выражения стали выполняться полным сканированием. Для анализа включили event 10053 для какого-то простенького выражения. Когда пришел трейс, то обнаружилось, что значение db_file_multiblock_read_count установлено в какое-то необычно большое значение.
Поэтому решили собрать системную статистику ...
После сбора статистики ситуация с планами пришла в норму.

Но данная проблема актуальна до сих пор.
Поэтому сегодня - о важности сбора системной статистики:

dbms_stats.gater_system_stats('start');
dbms_stats.gater_system_stats('stop');

Итак, для чего же ее надо собирать?

Рассмотрим, как Оракл вычисляет стоимость. Для это в документации приведена формула :

Cost =  (#SRds * sreadtim + 
         #MRds * mreadtim + 
         #CPUCycles / cpuspeed ) / sreadtim

http://docs.oracle.com/cd/B10501_01/server.920/a96533/ex_plan.htm#19598

sreadtim - время чтения одного блока

mreadtim - время многоблочного чтения

cpuspeed - скорость работы ЦПУ

Все серверы разные - скорость дисковой системы, скорость ЦПУ, доступ к памяти.
Поэтому и скорость доступа к блокам БД, находящимся в  SGA или на дисках - разная.
Отсюда и стоимость вычисления одного и того же SQL на разных системах должна отличаться.
Поэтому очень желательно, чтобы Оракл точно знал технические характеристики системы в которой он работает. Сбор системной статистики фактически производит калибровку ЦПУ, памяти и системы в/в подавая на вход оптимизатору реальные физические значения вашего сервера. При наличии системной статистики ошибаться оптимизатор будет гораздо реже!

Пересобирать системную статистику надо после физических изменений в сервере и системе в/в.

Ну а параметр db_file_multiblock_read_count из инит файла надо удалить.