Как часто должна выполняться статистика базы данных Oracle?

Ответ 1

На моей последней работе мы запускали статистику раз в неделю. Если я правильно помню, мы запланировали их в четверг вечером, а в пятницу администраторы баз данных были очень осторожны, чтобы отслеживать самые длинные запущенные запросы для чего-то неожиданного. (Пятница была выбрана потому, что она часто была сразу после выпуска кода и имела тенденцию быть довольно низким днем ​​трафика.) Когда они увидели плохой запрос, они нашли бы лучший план запроса и сохранили бы это, чтобы он не изменился неожиданно неожиданно, (У Oracle есть инструменты, чтобы сделать это для вас автоматически, вы скажете, что запрос будет оптимизирован, и он это делает.)

Многие организации избегают запускать статистику из опасения, что неудачные планы запросов неожиданно появятся. Но это обычно означает, что их планы запросов ухудшаются и ухудшаются с течением времени. И когда они запускают статистику, они сталкиваются с рядом проблем. Получающаяся в результате схватка для устранения этих проблем подтверждает их опасения по поводу опасности запуска статистики. Но если они регулярно запускали статистику, использовали инструменты мониторинга, как они предполагали, и исправляли проблемы по мере их появления, тогда у них было бы меньше головных болей, и они не встретили бы их всех сразу.

Ответ 2

Всякий раз, когда данные меняются "значительно".

Если таблица идет от 1 строки до 200 строк, это существенное изменение. Когда таблица идет от 100 000 строк до 150 000 строк, это не очень серьезное изменение. Когда таблица идет из 1000 строк, все с одинаковыми значениями в обычно запрашиваемом столбце X до 1000 строк с почти уникальными значениями в столбце X, это значительное изменение.

Статистика хранит информацию о подсчетах элементов и относительных частотах - вещи, которые позволят ему "угадать", сколько строк будет соответствовать заданным критериям. Когда он ошибается, оптимизатор может выбрать субоптимальный план запроса очень.

Ответ 3

Поскольку статистика Oracle 11g автоматически собирается по умолчанию.

Два окна планировщика предопределены при установке базы данных Oracle:

• WEEKNIGHT_WINDOW начинается с 10 вечера. и заканчивается в 6 утра каждый понедельник до пятницы.
• WEEKEND_WINDOW охватывает дни недели и субботу.

Когда статистика была собрана в последний раз?

SELECT owner, table_name, last_analyzed FROM all_tables ORDER BY last_analyzed DESC NULLS LAST; --Tables.
SELECT owner, index_name, last_analyzed FROM all_indexes ORDER BY last_analyzed DESC NULLS LAST; -- Indexes.

Состояние сбора автоматической статистики?

SELECT * FROM dba_autotask_client WHERE client_name = 'auto optimizer stats collection';

Группы Windows?

SELECT window_group_name, window_name FROM dba_scheduler_wingroup_members;

Расписания окон?

SELECT window_name, start_time, duration FROM dba_autotask_schedule;

Вручную собрать статистику базы данных в этой схеме:

EXEC dbms_stats.gather_schema_stats(ownname=>NULL, cascade=>TRUE); -- cascade=>TRUE means include Table Indexes too.

Вручную собрать статистику базы данных во всех схемах!

-- Probably need to CONNECT / AS SYSDBA
EXEC dbms_stats.gather_database_stats;

Ответ 4

Какую версию Oracle вы используете? Проверьте эту страницу, которая относится к Oracle 10:

http://www.acs.ilstu.edu/docs/Oracle/server.101/b10752/stats.htm

В нем говорится:

Рекомендуемый подход к сбору статистики - позволить Oracle автоматически собирать статистику. Oracle собирает статистику по всем объектам базы данных автоматически и сохраняет эти статистические данные в регулярном задании на техническое обслуживание.

Ответ 5

Когда я руководил большой многоплановой системой планирования, поддерживаемой Oracle, наш администратор базы данных имел еженедельную работу, которая собирала статистику. Кроме того, когда мы выкатили значительное изменение, которое может повлиять на статистику или повлиять на нее, мы заставили бы эту работу выходить из цикла, чтобы уловить ситуацию.

Ответ 6

С версией оракула 10g и выше обновленная статистика по таблицам и индексам необходима оптимизатору для принятия "хорошего" решения плана выполнения. Как часто вы собираете статистику, это сложный вызов. Это зависит от вашего приложения, схемы, скорости передачи данных и деловой практики. Некоторые сторонние приложения, написанные для обратной совместимости со старой версией oracle, плохо работают с новым оптимизатором. Эти приложения требуют, чтобы таблицы не имели статистики, чтобы db возвращался к плану выполнения базы правил. Но в среднем оракул рекомендует собирать статистику на таблицах с устаревшей статистикой. Вы можете установить таблицы для мониторинга и проверки их состояния и проанализировать их, если/когда они устарели. Часто этого достаточно, иногда это не так. Это действительно зависит от вашей базы данных. Для моей базы данных у нас есть набор таблиц OLTP, которые нуждаются в ночной статистической коллекции для поддержания производительности. Другие таблицы анализируются один раз в неделю. В нашей большой базе данных dw мы анализируем по мере необходимости, поскольку таблицы слишком велики для регулярного анализа, не затрагивая общую нагрузку и производительность db. Поэтому правильный ответ: это зависит от приложения, изменения данных и потребностей бизнеса.

Ответ 7

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

Представьте, что у вас есть база данных ошибок с таблицей ISSUE и столбцом CREATE_DATE, где значения в столбце становятся более или менее монотонно. Теперь предположим, что в этом столбце есть гистограмма, которая сообщает Oracle, что значения для этого столбца равномерно распределены между 1 января 2008 года и 17 сентября 2008 года. Это позволяет оптимизатору разумно оценить количество строк, которые будут если вы искали все выпуски, созданные на прошлой неделе (т.е. с 7 по 13 сентября). Если приложение по-прежнему используется и статистика никогда не обновляется, эта гистограмма будет менее и менее точной. Таким образом, оптимизатор ожидает, что запросы для "проблем, созданных на прошлой неделе" будут менее и менее точными с течением времени и могут в конечном итоге привести к тому, что Oracle изменит план запроса отрицательно.

Ответ 8

В случае системы складского типа данных можно рассматривать не собирать никакой статистики на всех, и опираясь на динамической выборки (установка optimizer_dynamic_sampling до уровня 2 или выше).

Ответ 9

Как правило, не рекомендуется собирать статистические данные, которые так часто встречаются во всей базе данных, если у вас нет сильного обоснования для этого, например, массовая вставка или большие изменения данных часто происходят в базе данных. сбор статистики по базе данных на этой частоте МОЖЕТ изменить план выполнения запросов на новые плохие планы выполнения, это может стоить вам много времени, пытаясь настроить каждый запрос, затронутый новыми плохими планами, поэтому вы должны проверить влияние сбора новые статистические данные в тестовой базе данных, или если у вас нет времени или силы для этого человека, по крайней мере, вы должны сохранить резервный план, создав резервную копию исходной статики перед тем, как собрать новые, поэтому, если вы соберете новой статистики, а затем запросы не выполнялись должным образом, вы можете легко восстановить исходную статистику.

Существует очень полезный script, который поможет вам создать резервную копию исходной статистики и собрать новые и предоставить вам команду SQL, которую вы можете использовать для восстановления исходной статики в случае, если вещь не пойдет так, как ожидалось, после сбора новой статистики, Вы можете найти script по этой ссылке: http://dba-tips.blogspot.com/2014/09/script-to-ease-gathering-statistics-on.html