Как часто следует запускать статистику базы данных Oracle?

Question

По вашему опыту, как часто следует запускать статистику базы данных Oracle? Наша команда разработчиков недавно обнаружила, что статистика не запускалась на нашем производственном сервере более 2 1/2 месяцев. Для меня это звучит долго, но я не администратор.

Answer 1

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

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

• WEEKNIGHT_WINDOW начинается в 22:00. и заканчивается в 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;

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

Там написано:

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

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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