Сбор статистики : Oracle

OlegON · █ 21.04.2009 17:52

Все нижесказанное мое ИМХО, испытанное той практикой, которую прошел я.
Значит первое, что я хочу посоветовать, несмотря на уважение к Тому Кайту, это чтобы пользователи версий Оракла ниже 10g не трогали пакет DBMS_STATS. Спорить не буду. analyze ... compute statistics рулит, как говорится, не по детски. На десятке столкнулся с таким очень неприятным явлением, что по секционированной FFMAPREP DBMS_STAT уходил в глубокую задумчивость, втыкаясь на несколько суток. Лечение подсказали:

Код:

SYS.DBMS_STATS.GATHER_SCHEMA_STATS ( OWNNAME=>'SUPERMAG',method_opt=> 'for all indexed columns size auto', CASCADE=>TRUE, ESTIMATE_PERCENT=>100);

последний параметр и выручает...

OlegON · █ 21.04.2009 18:04

Немного о сборе системной статистики, которая достаточно важна для 10ки (в 9ке я кроме глюков ничего не уловил).
Собирается просто:

Код:

dbms_stats.gather_system_stats(gathering_mode=>'interval',interval=>600);

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

Код:

dbms_stats.gather_system_stats('Start');
dbms_stats.gather_system_stats('Stop');

Впрочем, можно собирать и вручную сразу...

Mr_Vito · █ 02.09.2009 18:08

а как часто нужен сбор системной статистики?

OlegON · █ 02.09.2009 22:32

Зависит от изменения нагрузки на базу и от возможного изменения железа/перекладывания по разным винтам и пр. аналогичное. Я не стал заморачиваться - на самой сложной базе воткнул по понедельникам с 11 до 13, это самый показательный период. Если что-скажут сразу после этого...

Mr_Vito · █ 03.09.2009 13:38

т.е. ты воткнул с интервал = 120 (2 часа)?
600 это ведь 10 часов

OlegON · █ 03.09.2009 13:59

Именно так. В примере выше другая ситуация была.

leonid · █ 17.05.2010 16:31

На Oracle 10G при объеме FFMAPREP ~ 11G

Код:

ANALYZE TABLE SUPERMAG.FFMAPREP COMPUTE STATISTICS

вообще ничего не собирает,

Код:

SYS.DBMS_STATS.GATHER_SCHEMA_STATS ( OWNNAME=>'SUPERMAG',method_opt=> 'for all indexed columns size auto', CASCADE=>TRUE, ESTIMATE_PERCENT=>100);

- ночи не хватило,

Пробую сделать так:

Код:

exec SYS.DBMS_STATS.gather_table_stats( OWNNAME=>'SUPERMAG', tabname => 'FFMAPREP',method_opt=> 'for all indexed columns size auto', CASCADE=>TRUE, ESTIMATE_PERCENT=>30);

Посмотреть примерно ход выполнения можно так:

Код:

select l.sofar, l.totalwork, l.last_update_time, l.message
from v$session_longops l
where
 l.target_desc like '%FFMAPREP%'

slava · █ 21.05.2010 07:16

У нас база на 9i стала резко тормозить после

DBMS_STATS.gather_table_stats(ownname => 'SUPERMAG',
tabname => TableToAnalyzeRow.Table_Name, -- таблицы из USER_TABLES
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
block_sample => TRUE,
method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO',
degree => DBMS_STATS.DEFAULT_DEGREE,
granularity => 'ALL',
cascade => FALSE);

DBMS_STATS.GATHER_INDEX_STATS (
ownname => 'SUPERMAG',
indname => IndxToAnalyzeRow.index_name, -- Индексы по таблице
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
degree => DBMS_STATS.DEFAULT_DEGREE,
granularity => 'ALL'
);

Вся беда по нашим оценкам DBMS_STATS.AUTO_SAMPLE_SIZE,
а вот DBMS_STATS.DEFAULT_DEGREE - рулит.

John Doe · █ 21.05.2010 10:28

Я бы вообще на 9 не стал бы пользоваться DBMS_STATS, оно там глючило по черному.
В причинах тормозов не пытались разобраться? Системная статистика собрана? Хотя и ее бы я на 9 не стал собирать.

kadr · █ 21.05.2010 14:33

Цитата:

slava ➤ У нас база на 9i стала резко тормозить после

DBMS_STATS.gather_table_stats(ownname => 'SUPERMAG',
tabname => TableToAnalyzeRow.Table_Name, -- таблицы из USER_TABLES
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
block_sample => TRUE,
method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO',
degree => DBMS_STATS.DEFAULT_DEGREE,
granularity => 'ALL',
cascade => FALSE);

DBMS_STATS.GATHER_INDEX_STATS (
ownname => 'SUPERMAG',
indname => IndxToAnalyzeRow.index_name, -- Индексы по таблице
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
degree => DBMS_STATS.DEFAULT_DEGREE,
granularity => 'ALL'
);

Вся беда по нашим оценкам DBMS_STATS.AUTO_SAMPLE_SIZE,
а вот DBMS_STATS.DEFAULT_DEGREE - рулит.

по первому выделению я бы использовал 100% для полного сбора
второе выделение вообще выкинуть, если есть особая необходимость, то для конкретных таблиц указывать конкретные столбцы и размерность

P.S. Ну и проверить наличие статистики на временных таблицах, если есть - грохнуть