"не торопясь"? ну типа пожевали мегабайт, подождали немного, пожевали ещё... чтобы IO и прочие ресурсы не занимать. А то что времени много займёт — ну типа ладно ,подождём.
Обычно большие таблицы секционированы и есть в dbms_stats параметр granulatrity.
granularity вроде только говорит, собирать по партициям или общую статистику или обе. Хотя если как-то можно собирать по одной партиции (сейчас первую, через полчаса вторую), то было бы уже дело.
В большинстве случаев статистику по старым секциям вобще можно залочить и не собирать. Опять же, можно джоб напилить и собирать с любой паузой )
а gather_table_stats само не догадается, что старые партиции не менялись и их можно не трогать?
Если stale stats по партиции в dba_tab_statistic не наступило, то обычно эти партиции пропускаются .
Чудес то не бывает, чтобы узнать что ничего не менялось надо посмотреть. Опять же, ручной запуск, например
вы реальную проблему решаете или просто заблаговременно интересуетесь?
проблема реальная, но она не совсем моя :) так что я в данном случае просто интересуюсь. Некоторые товарищи по неизвестным причинам не собирали статистику по партициям, а потом решили включить. Боятся отожрать все ресурсы, если запустить просто gather_table_stats.
Он уступает ресурсы. Degree просто выставить аккуратно и всё будет более менее норм. Ну за исключением поехавших планов
для этого есть икрементальная статистика
DBA_TAB_MODIFICATIONS
Обсуждают сегодня