Хочется обратить внимание коллег, что по крайней мере все мои инсталяции SAP собирают статистику некорректно.(буду рад услышать, что в новых версиях все исправили и все работает, если кто знает - поделитесь знанием).

На данный момент на сайте саппорта САП появились уже патчи для 10g, это значит что есть и инсталяции на 10g. А в 10g вообще не поддерживается Rule Based Optimizer, а есть только Cost Based Optimizer, которому нужна статистика как хлеб.

Так вот. Все эти analyze table и analyze index, которые активно использует SAP не собирают статистику для оптимизатора:




Итак, задача - использовать DBMS_STATS для сбора статистики.
Тут есть проблема. Статистика собирается очень долго.

Что надо сделать, чтобы дать серверу умереть?

1. Так или иначе необходимо сделать полный сбор статистики схемы в первый раз функцией GATHER_SCHEMA_STATS.
2. Включить мониторинг таблиц схемы функцией ALTER_SCHEMA_TABLE_MONITORING пакета DBMS_STATS. При этом Oracle будет учитывать количество изменений(update/insert/delete) для таблиц схемы
3. В дальнейшем собирать статистику с опцией GATHER STALE. Это позволит пересобирать статистику только для таблиц, в которых количество изменений больше чем 10% от кол-ва строк

На данный момент у меня время сбора статистики на базах размером около 260Гб занимает от 2 до 10 минут.

Только заклинаю, применять это плавно и осторожно. Возможно сначала собирая статистику только по проблемным таблицам, а не сразу схемы. Я лично не использовал в сборе статистики гистограммы, ибо SAP не делает ни одного запроса без связанных переменных.

Если что-то начнет работать криво - можно удалить статистику функциями DELETE_XXX_STATS того же пакета.

Буду рад, если эта информация кому-нибудь поможет. Хотя вероятно большинство из местных админов так или иначе с этим сталкивались, и это всё уже знает.

Ñòðàííî - âñåãäà äóìàë, ÷òî ñòàòèñòèêà ñîáèðàåòñÿ íîðìàëüíî... Ïî-êðàéíåé ìåðå áûëî çàìå÷åíî, ÷òî ñèñòåìà ñ äàâíî íå ñîáèðàåìîé ñòàòèñòèêîé çàìåòíî óñêîðÿëàñü ïðè ñáîðå îíîé ïîñðåäñòâîì ñðåäñòâ SAP (brtools).

Да, такой эффект есть. В Oracle немного хитрят, когда пишут, что ANALYZE не собирает статистику для CBO. Просто она не полная, а в дальнейшем возможно и вообще не будет использоваться CBO.

Интересное сообщение!
Но все-таки ANALYZE статистику собирает, и собирает ее корректно.
Вот что пишет по этому поводу SAP (нота 588668) -
DBMS_STATS is a more recent method for creating statistics that is expected to replace ANALYZE in the long term. You can observe the following differences when using DBMS_STATS instead of ANALYZE

Advantages of DBMS_STATS:
-It is possible to use histograms for global statistics of partitioned objects
-Table-internal parallel processing is possible (Note 408532)
-Correct statistics even for columns with identical character strings in the first 32 characters (Note 365480)
-You can transport statistics to other systems
-You can back up and reactivate statistics
Disadvantages of DBMS_STATS:
-DBMS_STATS only determines statistical data that is relevant to CBO. It does not include useful columns that are useful for monitoring purposes, such as AVG_SPACE (See Note 821687), EMPTY_BLOCKS (again, see Note 821687), AVG_SPACE_FREELIST_BLOCKS or NUM_FREELIST_BLOCKS. As a result, you cannot make assertions about space utilization and fragmentation on the basis of DBMS_STATS statistics, for example, or you can only partially do so.
-No statistics for cluster tables
-Oracle 8i: Histograms cannot be created when you use parallel processing.

Аналогично Oracle ничего не пишет про то, что ANALYZE собирает статистику неправильно. Так что DBMS_STATS метод, несомненно, более прогрессивный, но и в ANALYZE ничего некорретного нет.

Интересное сообщение!
Но все-таки ANALYZE статистику собирает, и собирает ее корректно.
Вот что пишет по этому поводу SAP (нота 588668) -
DBMS_STATS is a more recent method for creating statistics that is expected to replace ANALYZE in the long term. You can observe the following differences when using DBMS_STATS instead of ANALYZE

Advantages of DBMS_STATS:
-It is possible to use histograms for global statistics of partitioned objects
-Table-internal parallel processing is possible (Note 408532)
-Correct statistics even for columns with identical character strings in the first 32 characters (Note 365480)
-You can transport statistics to other systems
-You can back up and reactivate statistics
Disadvantages of DBMS_STATS:
-DBMS_STATS only determines statistical data that is relevant to CBO. It does not include useful columns that are useful for monitoring purposes, such as AVG_SPACE (See Note 821687), EMPTY_BLOCKS (again, see Note 821687), AVG_SPACE_FREELIST_BLOCKS or NUM_FREELIST_BLOCKS. As a result, you cannot make assertions about space utilization and fragmentation on the basis of DBMS_STATS statistics, for example, or you can only partially do so.
-No statistics for cluster tables
-Oracle 8i: Histograms cannot be created when you use parallel processing.

Аналогично Oracle ничего не пишет про то, что ANALYZE собирает статистику неправильно. Так что DBMS_STATS метод, несомненно, более прогрессивный, но и в ANALYZE ничего некорретного нет.

Ну в 10 уже пишет.
Плюс к тому, я не видел ни одной кластеризированной таблицы в SAP




Кстати, на засыпку. Покажите-ка свой параметр из init.ora
optimizer_index_cost_adj

Пробовал собирать статистику напрямую. Бесполезно, САП удаляет такую статистику по ряду объектов. Т.е. САП признает только свою... хранит информацию о ней и пересобирает тока при определенных условиях.

Так же, при прямом(это когда непосредственно в аракле) анализе индексов выяснилось, что приблизительно 10% индексов имеют рыхлость от 20 до 100% !!! Но это сугубо на моей системе...

Примерно, в R3 30 000 индексов и из них 3500 были очень сильно рыхлые.

А про высокие индексы я вообще молчу! Их масса!

Правда анализ шел день! База > 100Gb Потом перестройка + analyze... estimate statistics; Еще день...

Но когда база большая, то на рыхлых индексах пользователям работать не уютно.

Так что, если кто хочет - может сам проверить.

Не совсем согласен с автором топика. Дело в том, что в 8i DBMS_STATS не совсем хорош, а в 10-ке, да там уже тока рулит костбазед и пакет отрабатывает корректно. Поэтому то в 8i многие писали сбор статистики в оракле руками и в основном использовали analyze(аракл сам писал, что analyze более корректен). В 9-ке руля поддерживаются для совместимости, а в 10-ке уже нет.

Напрямую это как?
Притом, вам не пофиг, что там SAP признает или нет? Выполнять запрос будет ведь Oracle. Статистику, собранную DBMS_STATS SAP слава богу не трогает



Товарищам с 8i могу только посочувствовать и пожелать скорейшего мигрирования.

Для восьмерки да, я бы ничего делать не стал

По поводу использования DBMS_STATS есть ноты (например, 408532). Судя по всему все САП собирает и прекрасно использует. Но не проверял )
По поводу цитаты, которую приводит уважаемый hell. В ней написано, что ANALYZE - устаревший метод и в конце концов от него откажутся. Но ничего не написано про то, что он работает некорректно и собирает не ту статистику. Это я и имел в виду.
Парамер optimizer_index_cost_adj - 10.

Во всяком случае, даже при использовании ANALYZE, SAP собирает ее по одному ему известному алгоритму Не по всей схеме - это явно.

Плюс. Я не зря спросил про параметр. Нормальное его значение при собранной системной статистике - 100. Системную статистику можно собрать только DBMS_STATS.

BRCONNECT "как-то там" умеет DBMS_STATS. Но мне кажется, что намного удобнее делать это без искуственного интеллекта сапа.

Плюс к тому, разница во времени при сборе DBMS_STATS может доходить до 4-5 раз, в зависимости от опций, с которыми ее собирать.

Собственно, чего хотел сказать - не надо доверять САПу никаких действий с базой, кроме может бэкапа(если он вас устраивает). Ибо все гораздо эффективней и гибче реализовать без всяких прослоек.

Самая полная нота по этому всему - 588668