DBMS_STATS или ANALYZE? (1)

И dbms_stats и analyze используются для сбора статистики, которая используются стоимостным оптимизатором (Cost-Based Optimizer) для построения планов выполнения. То есть их правильное использование оказывает очень большое влияние на производительность всей системы.
Но почему Oracle "настоятельно" рекомендует использовать пакет dbms_stats для сбора статистики вместо analyze?
Из документации Oracle:

"Oracle Corporation strongly recommends that you use the DBMS_STATS package rather than ANALYZE to collect optimizer statistics."

Так что же может dbms_stats, чего не может analyze:
- с помощью dbms_stats можно собирать системную статистику (analyze нет такой возможности)
(о системной статистике напишу отдельно, но "Oracle Corporation highly recommends that you gather system statistics.")
- с помощью dbms_stats можно собирать статистику в удаленной базе данных (через дблинк)

SQL> exec dbms_stats.gather_table_stats@remotedb('REMOTEUSER','REMOTETABLE',cascade=>true);

и еще:

"That package lets you collect statistics in parallel, collect global statistics for partitioned objects, and fine tune your statistics collection in other ways."

Кажется, что если Oracle рекомендует использовать dbms_stats для сбора статистики и имеет ряд преимуществ перед analyze, то зачем нужен analyze?

Здесь Том Кайт объясняет, что dbms_stats собирает статику только для оптимизатора (CBO).
А такие статистические данные, как количество перенесенных строк (chained rows), средний объем свободного места в блоке, количество неиспользованных блоков можно собрать только с помощью analyze.
Из документации Oracle :

"... you must use the ANALYZE statement rather than DBMS_STATS for statistics collection not related to the cost-based optimizer, such as:
To use the VALIDATE or LIST CHAINED ROWS clauses
To collect information on freelist blocks"

Если dbms_stats и analyze собирают одну и ту же статистику по объектам, то они собирают одинаковые данные?
Или эти данные отличаются?
Если отличаются, то кому из них верить?

Updated: 20 февраля, 2009
Попытаюсь ответить на эти вопросы: Некоторые столбцы/компоненты статистики, собранные dbms_stats-ом отличаются от той, которые собраны командой analyze.
Например кол-во строк (num_rows), высота индекса (blevel), конечно же НЕ отличаются.
А такие столбцы как avg_row_len, avg_col_len - отличаются: dbms_stat добавляет 1 байт за хранение длины столбца, а analyze - не учитывает байт, в котором хранится длина столбца. Вот что пишет Джонатан Льюис об этом:

As a general rule, the figures for bytes in execution plans are derived from the avg_col_len columns of user_tab_columns. The deprecated analyze command excludes the length byte(s) for the column, but the call to dbms_stats.gather_table_stats includes the length byte(s). Since the choice of build table in a hash join is affected by the size of the data sets involved, a switch from analyze to dbms_stats could (in principle) change the order of a hash join, or even cause the optimizer to use a different join mechanism.

В-общем, он говорит, что, в принципе, из-за этой разницы в статистике, оптимизатор может изменить план выполнения в зависимости от метода сбора статистики, так как статистика немного отличается.
Ответ на последний вопрос "Если отличаются, то кому из них верить?": Думаю достаточно иметь ввиду, что некоторые столбцы/компоненты статистики собранные dbms_stats-ом отличаются от той, которая собрана командой analyze. И, к тому же статистика нужна только оптимизатору, а вам она не нужна. Поэтому долго не думайте и собирайте статистику dbms_stats-ом, а чтоб увеличить скорость сбора, распараллельте или же собирайте с небольшим estimate-ом.

Здесь я написала о том, как определить, каким образом была собрана статистика: пакетом dbms_stats или оператором analyze.