it-swarm-ru.tech

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

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

21
user290

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

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

13
user11318

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

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

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

13
Jonathan Rupp

С 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;
13
grokster

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

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

Это говорит:

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

5
David Medinets

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

2
MichaelN

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

2
Joe Skora

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

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

1
Justin Cave

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

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

0
Chion

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

0
David Aldridge