[ТЕМА ЗАКРЫТА]
21.04.2009 17:52
OlegON
 
Все нижесказанное мое ИМХО, испытанное той практикой, которую прошел я.
Значит первое, что я хочу посоветовать, несмотря на уважение к Тому Кайту, это чтобы пользователи версий Оракла ниже 10g не трогали пакет DBMS_STAT. Спорить не буду. 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);
последний параметр и выручает...
21.04.2009 18:04
OlegON
 
Немного о сборе системной статистики, которая достаточно важна для 10ки (в 9ке я кроме глюков ничего не уловил).
Собирается просто:
Код:
dbms_stats.gather_system_stats(gathering_mode=>'interval',interval=>600);
в качестве параметра - минуты. Собирать надо во время обычной нагрузки базы. Бывает, что глюкает, просто сообщая, что не может расчитать статистику. Для решения этой болячки просто руками запускаем и стопим сбор:
Код:
dbms_stats.gather_system_stats('Start');
dbms_stats.gather_system_stats('Stop');
Впрочем, можно собирать и вручную сразу...
02.09.2009 18:08
Mr_Vito
 
а как часто нужен сбор системной статистики?
02.09.2009 22:32
OlegON
 
Зависит от изменения нагрузки на базу и от возможного изменения железа/перекладывания по разным винтам и пр. аналогичное. Я не стал заморачиваться - на самой сложной базе воткнул по понедельникам с 11 до 13, это самый показательный период. Если что-скажут сразу после этого...
03.09.2009 13:38
Mr_Vito
 
т.е. ты воткнул с интервал = 120 (2 часа)?
600 это ведь 10 часов
03.09.2009 13:59
OlegON
 
Именно так. В примере выше другая ситуация была.
17.05.2010 16:31
leonid
 
На 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%'
21.05.2010 07:16
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 - рулит.
21.05.2010 10:28
John Doe
 
Я бы вообще на 9 не стал бы пользоваться DBMS_STATS, оно там глючило по черному.
В причинах тормозов не пытались разобраться? Системная статистика собрана? Хотя и ее бы я на 9 не стал собирать.
21.05.2010 14:33
kadr
 
Цитата:
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. Ну и проверить наличие статистики на временных таблицах, если есть - грохнуть
25.05.2010 07:15
slava
 
Цитата:
kadr по первому выделению я бы использовал 100% для полного сбора
второе выделение вообще выкинуть, если есть особая необходимость, то для конкретных таблиц указывать конкретные столбцы и размерность


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

по первому выделению: 100% уже Compute и время сбора на порядок больше.
по второму как определить ту самую необходимость и размерность для конкретных столбцов?
25.05.2010 07:18
slava
 
Цитата:
John Doe Я бы вообще на 9 не стал бы пользоваться DBMS_STATS, оно там глючило по черному.
В причинах тормозов не пытались разобраться? Системная статистика собрана? Хотя и ее бы я на 9 не стал собирать.
Можно подробности. Пока нам непонятна методика определения DENSITY у столбцов при сборе гистограмм.

Системная статистика не собиралась.
29.11.2011 13:25
Mr_Vito
 
захотелось поднять вопрос по сбору статистики, т.к. я не очень понимаю как все работает, но зато очень хорошо вижу на сколько с ней база начинает летать.

статистику я собираю через:

SQL> select to_char(sysdate,'DD.MM.YYYY HH:MI:SS') from dual;
29.11.2011 07:00:00 1 row selected.
SQL> exec DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SUPERMAG', tabname => 'FFMAPREP', Estimate_Percent => 100, cascade=> TRUE);
PL/SQL procedure successfully completed.
SQL> select to_char(sysdate,'DD.MM.YYYY HH:MI:SS') from dual;
29.11.2011 13:10:54 1 row selected.
SQL> SPOOL off

при том, по табличкам отдельно, но по ffmaprep и smspec (по каждой отдельно) расчет идет 4-6 часов (по разному) как можно процесс ускорить (хотя расчет запаралелил)?
или это время нормальное?

Олег, прости, но после оптимайзера база практически встаёт (поэтому я им не считаю :( ) как то поднимал этот вопрос, но вразумительного я ничего не добился, может сейчас получится что либо выяснить.

Может проблема в базе я не знаю, но время сбора статистики существенно увеличилось, раньше считалось за 3 часа всё

база 10.2.0.4
записей в ffmaprep 54071888
в smspec 66641761
29.11.2011 15:02
OlegON
 
Цитата:
Mr_Vito Олег, прости, но после оптимайзера база практически встаёт (поэтому я им не считаю :( )
У всех считает нормально, у тебя встает... Предлагаю тебе разобраться в разнице, думаю это и будет шагом к улучшению производительности при текущем уровне знаний (без обид).
Опции темы


Часовой пояс GMT +3, время: 13:41.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.