DBMS_STATS AUTOMATIC Maintenance windows / Oracle

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Oracle [игнор отключен] [закрыт для гостей] / DBMS_STATS AUTOMATIC Maintenance windows

12 сообщений из 12, страница 1 из 1

DBMS_STATS AUTOMATIC Maintenance windows

#39859738

Nemonor

Гость

Добрый день!
После продолжительного изучения документации Oracle так и не нашёл пояснения на свой вопрос, может быть тут кто-нибудь сможет что-то подсказать. А вопрос вот в чём, в случае если отрабатывающие во время окон обслуживания задания расчёта статистики не успевают в выделенное время завершить расчёт, каким образом они завершаются? СУБД прерывает эти задания поскольку окно обслуживания закрылось и время истекло и соответственно откатывает внесённые изменения, поскольку работы не была завершена, или же они завершаются таким образом, чтобы продолжить работу в следующее окно?

У меня имеется две БД, на обоих включены автоматические задания обслуживания по расчёту статистики, и при этом на одной из них статистика прекрасно пересчитывается при штатном stale_percent=10, на второй я не вижу пересчёта аналогичных таблиц (структура части объектов у баз схожая выполняется регулярная синхронизация части данных) даже выставив stale_percent=1 (до этого также стояло сначала 10 и с тем же эффектом).

Вот и думаю, может ли это зависеть от того, что СУБД просто не успевает обработать в окно имеющиеся объёмы для пересчёта, и в итоге крупные и нужные мне объекты не пересчитываются. Инкрементальная статистика на крупных партиционированных таблицах включена, то есть полный пересчёт происходить не должен...

...

Рейтинг:

0 / 0

10.09.2019, 11:32

| Ответить | Цитировать | Написать

DBMS_STATS AUTOMATIC Maintenance windows

#39859785

KoTTT

Участник

Откуда: Екб

Сообщения: 1 513

Рейтинг: 0 / 0

Код: plsql

1.
2.
3.
4.
5.

select * from dba_optstat_operations;
select * from dba_optstat_operation_tasks;
select * from dba_autotask_job_history where client_name = 'auto optimizer stats collection';
select * from dba_tab_statistics;
select * from dba_tab_stats_history;

Nemonorполный пересчёт происходить не должен...
если synopsis уже были ранее собраны по "старым" секциям, если таблицы подходят под условия инкрементального сбора, и если другие параметры сбора статистики по этим таблицам подходят под условия инкрементального сбора

...

Рейтинг:

0 / 0

10.09.2019, 12:40

| Ответить | Цитировать | Написать

DBMS_STATS AUTOMATIC Maintenance windows

#39859858

Nemonor

Гость

select operation,START_TIME,END_TIME from dba_optstat_operations where target = '<schema>.<tab_name>' order by START_TIME desc;

unlock_table_stats 23.08.19 08.41.39,099189000 AM +03:00 23.08.19 08.41.39,986754000 AM +03:00
gather_table_stats 21.08.19 11.30.43,456700000 AM +03:00 23.08.19 02.20.26,205046000 AM +03:00
lock_table_stats 20.08.19 11.45.14,917892000 AM +03:00 20.08.19 11.45.15,195149000 AM +03:00
restore_table_stats 16.08.19 11.00.01,001960000 PM +03:00 16.08.19 11.16.37,601289000 PM +03:00
restore_table_stats 13.08.19 07.00.01,691181000 PM +03:00 13.08.19 07.09.47,859111000 PM +03:00
restore_table_stats 12.08.19 11.00.01,043751000 PM +03:00 12.08.19 11.18.07,658598000 PM +03:00
restore_table_stats 10.08.19 11.00.00,969393000 PM +03:00 10.08.19 11.04.54,375292000 PM +03:00
restore_table_stats 04.08.19 11.00.06,618320000 PM +03:00 04.08.19 11.00.50,035314000 PM +03:00
gather_table_stats 24.07.19 02.25.55,832714000 PM +03:00 24.07.19 08.19.42,913740000 PM +03:00
restore_table_stats 23.07.19 11.00.01,433463000 PM +03:00 23.07.19 11.08.14,057317000 PM +03:00
restore_table_stats 21.07.19 10.00.00,695720000 PM +03:00 21.07.19 10.14.10,954658000 PM +03:00
restore_table_stats 20.07.19 10.00.01,411339000 PM +03:00 20.07.19 10.16.01,249595000 PM +03:00
restore_table_stats 18.07.19 10.00.01,603479000 PM +03:00 18.07.19 10.13.27,267828000 PM +03:00
restore_table_stats 17.07.19 10.00.07,653989000 PM +03:00 17.07.19 10.14.20,736940000 PM +03:00
restore_table_stats 15.07.19 10.00.01,273131000 PM +03:00 15.07.19 10.14.08,419964000 PM +03:00
restore_table_stats 14.07.19 10.00.00,881528000 PM +03:00 14.07.19 10.11.26,310688000 PM +03:00
restore_table_stats 13.07.19 10.00.01,322782000 PM +03:00 13.07.19 10.13.17,539577000 PM +03:00
restore_table_stats 12.07.19 10.00.01,519602000 PM +03:00 12.07.19 10.10.24,233515000 PM +03:00
restore_table_stats 11.07.19 10.00.01,745873000 PM +03:00 11.07.19 10.14.05,377458000 PM +03:00
restore_table_stats 10.07.19 10.00.01,547532000 PM +03:00 10.07.19 10.14.42,037756000 PM +03:00
restore_table_stats 09.07.19 10.00.01,817639000 PM +03:00 09.07.19 10.09.15,919364000 PM +03:00
restore_table_stats 08.07.19 10.00.00,757484000 PM +03:00 08.07.19 10.02.15,720047000 PM +03:00
restore_table_stats 07.07.19 10.00.02,800812000 PM +03:00 07.07.19 10.14.24,275478000 PM +03:00
restore_table_stats 06.07.19 10.00.01,187627000 PM +03:00 06.07.19 10.14.53,231769000 PM +03:00
restore_table_stats 05.07.19 10.00.03,247247000 PM +03:00 05.07.19 10.15.29,099110000 PM +03:00
restore_table_stats 04.07.19 10.00.01,502669000 PM +03:00 04.07.19 10.08.59,789494000 PM +03:00
restore_table_stats 03.07.19 10.00.01,723314000 PM +03:00 03.07.19 10.13.29,506685000 PM +03:00
restore_table_stats 02.07.19 10.00.02,064203000 PM +03:00 02.07.19 10.08.13,145680000 PM +03:00
restore_table_stats 01.07.19 10.00.01,393231000 PM +03:00 01.07.19 10.09.19,616283000 PM +03:00
restore_table_stats 30.06.19 10.00.00,866198000 PM +03:00 30.06.19 10.04.02,211692000 PM +03:00
restore_table_stats 29.06.19 10.00.01,344539000 PM +03:00 29.06.19 10.13.27,351696000 PM +03:00
restore_table_stats 28.06.19 10.00.07,073076000 PM +03:00 28.06.19 10.09.59,440908000 PM +03:00
restore_table_stats 21.06.19 10.00.16,824399000 PM +03:00 21.06.19 10.05.30,951699000 PM +03:00
unlock_table_stats 20.06.19 02.50.01,631892000 PM +03:00 20.06.19 02.50.01,661540000 PM +03:00
gather_table_stats 18.06.19 09.47.32,419288000 AM +03:00 20.06.19 10.21.41,428871000 AM +03:00
lock_table_stats 18.06.19 09.45.18,377362000 AM +03:00 18.06.19 09.45.18,377936000 AM +03:00
lock_table_stats 27.05.19 02.13.04,207331000 PM +03:00 27.05.19 02.13.04,230329000 PM +03:00

Записи lock здесь - это ручная блокировка таблицы для выполнения ручного полного пересчёта, после последнего полного пересчёта и разлочивания таблицы операций никаких не было с её статой.

select * from dba_autotask_job_history where client_name = 'auto optimizer stats collection';

auto optimizer stats collection MONDAY_WINDOW 09.09.19 01.00.00,219834000 PM +03:00 +00 08:00:00.010886 ORA$AT_OS_OPT_SY_22613 STOPPED 09.09.19 01.00.04,216266000 PM +03:00 +00 07:59:57.000000 0
auto optimizer stats collection SUNDAY_WINDOW 08.09.19 05.00.00,811442000 PM +03:00 +00 05:59:59.364058 ORA$AT_OS_OPT_SY_22593 STOPPED 08.09.19 05.00.10,570919000 PM +03:00 +00 05:59:50.000000 0
auto optimizer stats collection SATURDAY_WINDOW 07.09.19 05.00.00,220304000 PM +03:00 +00 05:59:59.948550 ORA$AT_OS_OPT_SY_22573 STOPPED 07.09.19 05.00.03,101075000 PM +03:00 +00 05:59:57.000000 0
auto optimizer stats collection FRIDAY_WINDOW 06.09.19 02.00.00,036558000 PM +03:00 +00 08:00:00.189034 ORA$AT_OS_OPT_SY_22553 STOPPED 06.09.19 02.00.01,572776000 PM +03:00 +00 07:59:59.000000 0
auto optimizer stats collection THURSDAY_WINDOW 05.09.19 05.00.00,149077000 PM +03:00 +00 06:00:00.178620 ORA$AT_OS_OPT_SY_22533 STOPPED 05.09.19 05.00.03,298196000 PM +03:00 +00 05:59:57.000000 0
auto optimizer stats collection WEDNESDAY_WINDOW 04.09.19 05.00.00,173691000 PM +03:00 +00 05:59:59.951225 ORA$AT_OS_OPT_SY_22513 STOPPED 04.09.19 05.00.03,281162000 PM +03:00 +00 05:59:57.000000 0
auto optimizer stats collection TUESDAY_WINDOW 03.09.19 01.00.01,754181000 PM +03:00 +00 05:59:58.275328 ORA$AT_OS_OPT_SY_22493 STOPPED 03.09.19 01.00.39,029187000 PM +03:00 +00 05:59:22.000000 0
auto optimizer stats collection MONDAY_WINDOW 02.09.19 05.00.00,154039000 PM +03:00 +00 05:59:59.963644 ORA$AT_OS_OPT_SY_22473 STOPPED 02.09.19 05.00.03,172661000 PM +03:00 +00 05:59:57.000000 0
auto optimizer stats collection SUNDAY_WINDOW 01.09.19 05.00.00,337142000 PM +03:00 +00 05:59:59.828735 ORA$AT_OS_OPT_SY_22453 STOPPED 01.09.19 05.00.06,430776000 PM +03:00 +00 05:59:54.000000 0
auto optimizer stats collection SATURDAY_WINDOW 31.08.19 05.00.00,448760000 PM +03:00 +00 06:00:01.055707 ORA$AT_OS_OPT_SY_22433 STOPPED 31.08.19 05.00.03,908145000 PM +03:00 +00 05:59:59.000000 0
auto optimizer stats collection FRIDAY_WINDOW 30.08.19 05.00.00,228638000 PM +03:00 +00 05:59:59.920854 ORA$AT_OS_OPT_SY_22413 STOPPED 30.08.19 05.00.03,165251000 PM +03:00 +00 05:59:58.000000 0
auto optimizer stats collection THURSDAY_WINDOW 29.08.19 05.00.00,318645000 PM +03:00 +00 05:59:59.863696 ORA$AT_OS_OPT_SY_22393 STOPPED 29.08.19 05.00.02,754194000 PM +03:00 +00 05:59:58.000000 0
auto optimizer stats collection WEDNESDAY_WINDOW 28.08.19 05.00.00,260061000 PM +03:00 +00 05:59:59.816248 ORA$AT_OS_OPT_SY_22373 STOPPED 28.08.19 05.00.02,919581000 PM +03:00 +00 05:59:58.000000 0
auto optimizer stats collection TUESDAY_WINDOW 27.08.19 01.00.00,390120000 PM +03:00 +00 05:59:59.752312 ORA$AT_OS_OPT_SY_22353 STOPPED 27.08.19 01.00.03,174310000 PM +03:00 +00 05:59:58.000000 0
auto optimizer stats collection MONDAY_WINDOW 26.08.19 05.00.01,247698000 PM +03:00 +00 05:59:58.847004 ORA$AT_OS_OPT_SY_22333 STOPPED 26.08.19 05.00.03,744109000 PM +03:00 +00 06:00:10.000000 0
auto optimizer stats collection SUNDAY_WINDOW 25.08.19 05.00.02,079659000 PM +03:00 +00 05:59:58.185762 ORA$AT_OS_OPT_SY_22313 STOPPED 25.08.19 05.00.24,276821000 PM +03:00 +00 05:59:37.000000 0
auto optimizer stats collection SATURDAY_WINDOW 24.08.19 05.00.00,158872000 PM +03:00 +00 05:59:59.963647 ORA$AT_OS_OPT_SY_22293 STOPPED 24.08.19 05.00.02,733780000 PM +03:00 +00 05:59:58.000000 0
auto optimizer stats collection FRIDAY_WINDOW 23.08.19 05.00.00,166771000 PM +03:00 +00 05:59:59.995588 ORA$AT_OS_OPT_SY_22273 STOPPED 23.08.19 05.00.02,833129000 PM +03:00 +00 05:59:58.000000 0
auto optimizer stats collection THURSDAY_WINDOW 22.08.19 05.00.00,268462000 PM +03:00 +00 05:59:59.876165 ORA$AT_OS_OPT_SY_22253 STOPPED 22.08.19 05.00.03,310924000 PM +03:00 +00 05:59:57.000000 0
auto optimizer stats collection WEDNESDAY_WINDOW 21.08.19 05.00.00,172016000 PM +03:00 +00 05:59:59.970072 ORA$AT_OS_OPT_SY_22233 STOPPED 21.08.19 05.00.02,837348000 PM +03:00 +00 05:59:58.000000 0
auto optimizer stats collection TUESDAY_WINDOW 20.08.19 01.00.00,255479000 PM +03:00 +00 06:00:00.045324 ORA$AT_OS_OPT_SY_22213 STOPPED 20.08.19 01.00.07,684936000 PM +03:00 +00 05:59:53.000000 0
auto optimizer stats collection MONDAY_WINDOW 19.08.19 05.00.00,160770000 PM +03:00 +00 05:59:59.945006 ORA$AT_OS_OPT_SY_22193 STOPPED 19.08.19 05.00.03,051285000 PM +03:00 +00 06:00:01.000000 0
auto optimizer stats collection SUNDAY_WINDOW 18.08.19 05.00.00,745530000 PM +03:00 +00 05:59:59.310325 ORA$AT_OS_OPT_SY_22190 STOPPED 18.08.19 05.00.10,746606000 PM +03:00 +00 05:59:50.000000 0
auto optimizer stats collection SATURDAY_WINDOW 17.08.19 05.00.00,637499000 PM +03:00 +00 05:59:59.550298 ORA$AT_OS_OPT_SY_22170 STOPPED 17.08.19 05.00.03,599662000 PM +03:00 +00 05:59:57.000000 0
auto optimizer stats collection FRIDAY_WINDOW 16.08.19 05.00.00,465845000 PM +03:00 +00 05:59:59.631218 ORA$AT_OS_OPT_SY_22156 STOPPED 16.08.19 05.00.03,681862000 PM +03:00 +00 05:59:57.000000 0
auto optimizer stats collection THURSDAY_WINDOW 15.08.19 05.00.00,275101000 PM +03:00 +00 05:59:59.906234 ORA$AT_OS_OPT_SY_22153 STOPPED 15.08.19 05.00.03,443540000 PM +03:00 +00 05:59:57.000000 0
auto optimizer stats collection WEDNESDAY_WINDOW 14.08.19 05.00.00,307666000 PM +03:00 +00 05:59:59.883465 ORA$AT_OS_OPT_SY_22150 STOPPED 14.08.19 05.00.03,426609000 PM +03:00 +00 05:59:57.000000 0
auto optimizer stats collection TUESDAY_WINDOW 13.08.19 01.00.00,404117000 PM +03:00 +00 05:59:59.888281 ORA$AT_OS_OPT_SY_22130 STOPPED 13.08.19 01.00.05,824673000 PM +03:00 +00 05:59:55.000000 0
auto optimizer stats collection MONDAY_WINDOW 12.08.19 05.00.00,383567000 PM +03:00 +00 05:59:59.702302 ORA$AT_OS_OPT_SY_22110 STOPPED 12.08.19 05.00.04,140458000 PM +03:00 +00 05:59:56.000000 0
auto optimizer stats collection SUNDAY_WINDOW 11.08.19 05.00.01,628254000 PM +03:00 +00 05:59:58.416496 ORA$AT_OS_OPT_SY_22090 STOPPED 11.08.19 05.00.16,324916000 PM +03:00 +00 05:59:45.000000 0

select count(*)
from dba_tab_statistics
where table_name = '<tab_name>'
and stale_stats is null;

20

select count(*)
from dba_tab_statistics
where table_name = '<tab_name>'
and stale_stats='YES';

60

select partition_name,
stale_stats,
LAST_ANALYZED /* YES or NO */
from dba_tab_statistics
where table_name = '<tab_name>'
order by LAST_ANALYZED DESC;

SYS_P1073873
SYS_P1054580
SYS_P1057106
SYS_P1052161
SYS_P1067947
SYS_P1070926
SYS_P1050924
SYS_P1058345
SYS_P1072413
SYS_P1065002
SYS_P1066455
SYS_P1063494
SYS_P1075381
SYS_P1049673
SYS_P1060796
SYS_P1059563
SYS_P1055857
SYS_P1053382
SYS_P1062055
SYS_P1069407
YES 23.08.19
SYS_P672290 NO 23.08.19
SYS_P655103 NO 23.08.19
SYS_P593291 NO 23.08.19
SYS_P510070 NO 23.08.19
SYS_P985934 NO 23.08.19
SYS_P976058 NO 23.08.19
SYS_P971458 NO 23.08.19
SYS_P969987 NO 23.08.19
SYS_P965548 NO 23.08.19
SYS_P961835 NO 23.08.19
SYS_P958593 NO 23.08.19
SYS_P952693 NO 23.08.19
SYS_P952102 NO 23.08.19
SYS_P945572 NO 23.08.19
SYS_P942393 NO 23.08.19
SYS_P935966 NO 23.08.19
SYS_P934503 NO 23.08.19
SYS_P933666 NO 23.08.19
SYS_P932771 NO 23.08.19
SYS_P931257 NO 23.08.19
SYS_P923899 NO 23.08.19
SYS_P920583 NO 23.08.19
SYS_P915937 NO 23.08.19
...

В последний раз партиции соответственно пересчитывались, когда я вручную запускал полный пересчёт статистики - 23.08, с таблицей еженочно производятся работы, выполняются транкейты партиций глубиной в месяц и из заполнение актуальной информацией, плюс добавление новых партиций за каждый новый день, соответствено выше видно, что по 60 партициям статус статистики NULL, и ещё по 20 "YES", то есть необходим пересчёт. И пересчёт не выполняется. Даже при выставлении процента устаревания равным 1. Но при этом на соседней базе, куда собственно эта таблица передаётся с теми же изменениями ежедневно, всё стабильно пересчитывается хотя бы раз в неделю по мере накопления изменений. Настройки уже сравнивал неоднократно, уже не знаю что ещё посмотреть можно.

...

Рейтинг:

0 / 0

10.09.2019, 14:22

| Ответить | Цитировать | Написать

DBMS_STATS AUTOMATIC Maintenance windows

#39860356

KoTTT

Участник

Откуда: Екб

Сообщения: 1 513

Рейтинг: 0 / 0

Сабпартиции есть? Если есть, то инкрементальная мимо.
Сбросьте параметры сбора статистики по таблице в дефолтные. Или
https://docs.oracle.com/database/121/ARPLS/d_stats.htm Oracle will update the global table statistics by scanning only the partitions that have been changed instead of the entire table if the following conditions hold:

* the INCREMENTAL value for the partitioned table is set to TRUE;
* the PUBLISH value for the partitioned table is set to TRUE;
* the user specifies AUTO_SAMPLE_SIZE for ESTIMATE_PERCENT and AUTO for GRANULARITY when gathering statistics on the table.
ну и
https://docs.oracle.com/database/121/ARPLS/d_stats.htm INCREMENTAL_LEVEL
INCREMENTAL_STALENESS

...

Рейтинг:

0 / 0

11.09.2019, 14:55

| Ответить | Цитировать | Написать

DBMS_STATS AUTOMATIC Maintenance windows

#39860698

Nemonor

Гость

Субпартиций нет.

Вот текущие настройки сбора статистики по таблице:
GRANULARITY ESTIMATE_PERCENT METHOD_OPT NO_INVALIDATE DEGREE PUBLISH
AUTO DBMS_STATS.AUTO_SAMPLE_SIZE FOR ALL COLUMNS SIZE AUTO DBMS_STATS.AUTO_INVALIDATE NULL TRUE

...

Рейтинг:

0 / 0

12.09.2019, 09:08

| Ответить | Цитировать | Написать

DBMS_STATS AUTOMATIC Maintenance windows

#39860701

Nemonor

Гость

И соответственно INCREMENTAL тоже TRUE.

...

Рейтинг:

0 / 0

12.09.2019, 09:14

| Ответить | Цитировать | Написать

DBMS_STATS AUTOMATIC Maintenance windows

#39861195

KoTTT

Участник

Откуда: Екб

Сообщения: 1 513

Рейтинг: 0 / 0

Nemonorselect operation,START_TIME,END_TIME from dba_optstat_operations where target = '<schema>.<tab_name>' order by START_TIME desc;
Так посмотрите без фильтра по конкретной таблице. Там все понятнее станет. И поле STATUS там вполне говорящее.

...

Рейтинг:

0 / 0

12.09.2019, 22:23

| Ответить | Цитировать | Написать

DBMS_STATS AUTOMATIC Maintenance windows

#39861298

Nemonor

Гость

Так я выше и приложил выборку по операциям по одной таблице.

...

Рейтинг:

0 / 0

13.09.2019, 09:27

| Ответить | Цитировать | Написать

DBMS_STATS AUTOMATIC Maintenance windows

#39861365

KoTTT

Участник

Откуда: Екб

Сообщения: 1 513

Рейтинг: 0 / 0

Я ведь писал "посмотрите БЕЗ фильтра по конкретной таблице". Чтобы увидеть, чем вообще джоб занимается.
Вообще, вся информация есть в этих вьюхах.
Но и так похоже, что до ваших нужных таблиц джоб просто не успевает дойти, и это вполне должно быть видно в dba_optstat_operations (status = 'TIMED OUT') и с подробностями в dba_optstat_operation_tasks where opid = ... order by start_time.

...

Рейтинг:

0 / 0

13.09.2019, 10:44

| Ответить | Цитировать | Написать

DBMS_STATS AUTOMATIC Maintenance windows

#39861416

Nemonor

Гость

Вы имеете в виду, что он ежедневно перемалывает одни и те же таблицы, по которым есть регулярные изменения и просто не успевает по очереди добраться до интересующей меня?

Вот кусок операций без фильтра:

gather_table_stats 13.09.19 08.00.10,032614000 AM +03:00 13.09.19 08.01.54,474703000 AM +03:00
restore_table_stats 12.09.19 09.00.01,613142000 PM +03:00 12.09.19 09.18.13,588197000 PM +03:00
gather_database_stats(auto) 12.09.19 01.00.04,783171000 PM +03:00 12.09.19 09.18.26,338657000 PM +03:00
gather_table_stats 12.09.19 08.00.08,808076000 AM +03:00 12.09.19 08.02.05,549774000 AM +03:00
restore_table_stats 11.09.19 09.00.00,973539000 PM +03:00 11.09.19 09.29.02,821733000 PM +03:00
gather_database_stats(auto) 11.09.19 01.00.48,835005000 PM +03:00 11.09.19 09.29.09,144325000 PM +03:00
gather_table_stats 11.09.19 08.00.07,147142000 AM +03:00 11.09.19 08.05.04,055607000 AM +03:00
restore_table_stats 10.09.19 09.00.01,918194000 PM +03:00 10.09.19 09.47.09,141577000 PM +03:00
gather_database_stats(auto) 10.09.19 01.00.04,611208000 PM +03:00 10.09.19 09.47.24,170358000 PM +03:00
gather_table_stats 10.09.19 08.00.06,236169000 AM +03:00 10.09.19 08.03.29,045902000 AM +03:00
restore_table_stats 09.09.19 09.00.01,963836000 PM +03:00 09.09.19 09.12.41,468147000 PM +03:00
gather_database_stats(auto) 09.09.19 01.00.04,209725000 PM +03:00 09.09.19 09.12.48,776326000 PM +03:00
gather_table_stats 09.09.19 08.00.05,318139000 AM +03:00 09.09.19 08.02.16,155394000 AM +03:00
restore_table_stats 08.09.19 11.00.01,099762000 PM +03:00 08.09.19 11.10.19,920928000 PM +03:00
gather_database_stats(auto) 08.09.19 05.00.10,567982000 PM +03:00 08.09.19 11.10.31,973036000 PM +03:00
gather_table_stats 08.09.19 08.00.08,611429000 AM +03:00 08.09.19 08.03.40,855183000 AM +03:00

Много записей рестора статистики по разным таблицам (моя не фигурирует), "gather_database_stats(auto)" также фигурирует ежедневно, но в таргете у него null, то есть детализацию здесь по этой операции мы не увидим. Плюс по одной таблице ежедневно из процедуры ручной сбор отрабатывает.

Вообще рассматриваю возможность использования CONCURRENT в TRUE для оптимизации заданий сбора и распараллеливания? Но смущает то что, при его тестировании на тестовом стенде и заметил, что в случае, когда он переведён в TRUE, задание сбора генерит очень большое количество сессий и начинает весьма серьёзно загружать сервер...

...

Рейтинг:

0 / 0

13.09.2019, 11:57

| Ответить | Цитировать | Написать

DBMS_STATS AUTOMATIC Maintenance windows

#39861485

KoTTT

Участник

Откуда: Екб

Сообщения: 1 513

Рейтинг: 0 / 0

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

select  o.start_time,
	o.end_time,
	o.end_time - o.start_time duration,
	o.status,
	ot.opid,
	ot.target,
	ot.target_type,
	ot.target_size,
	ot.start_time task_start_time,
	ot.end_time task_end_time,
	ot.end_time - ot.start_time task_duration,
	ot.status task_status,
	ot.notes
from dba_optstat_operations o, dba_optstat_operation_tasks ot
where o.operation = 'gather_database_stats (auto)' and o.id = ot.opid
order by o.id desc, ot.start_time desc;

Про concurrent лучше забыть, если сервер у вас хоть чем-то еще полезным должен заниматься кроме сбора статистики в это время.

...

Рейтинг:

0 / 0

13.09.2019, 13:29

| Ответить | Цитировать | Написать

DBMS_STATS AUTOMATIC Maintenance windows

#39861528

Nemonor

Гость

В Oracle 11g отсутствует представление dba_optstat_operation_tasks.

...

Рейтинг:

0 / 0

13.09.2019, 14:02

| Ответить | Цитировать | Написать

12 сообщений из 12, страница 1 из 1

Форумы / Oracle [игнор отключен] [закрыт для гостей] / DBMS_STATS AUTOMATIC Maintenance windows

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

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

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=52&msg=39861365&tid=1882087]:	0ms
get settings:	10ms
get forum list:	15ms
check forum access:	4ms
check topic access:	4ms
track hit:	42ms
get topic data:	11ms
get forum data:	3ms
get page messages:	53ms
get tp. blocked users:	2ms
others:	16ms

total:	160ms