Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Периодические подвисания в БД, как быть?  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
andrey_anonymous,

тут еще вопрос что раньше заметят: внезапные ошибки из-за закончившегося места или пики на графике
как бы то ни было , процесс и пул надо настраивать - при вставках в 2-5 потоков оверхеда было бы намного меньше.



Sheriffua,

гляньте еще:
1.
2.
13 май 16, 15:22    [19169364]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
dba123
Member

Откуда:
Сообщений: 1054
О каком +append (direct-path insert) идет речь для insert .. values .. (10g) ?
или я что-то пропустил
13 май 16, 15:37    [19169471]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18351
xtender
andrey_anonymous,

тут еще вопрос что раньше заметят: внезапные ошибки из-за закончившегося места или пики на графике

Какие пики? +append сериализует вставки (TM6).
Если параллельных сессий много, то заметят сра-жу-зе.

dba123
О каком +append (direct-path insert) идет речь для insert .. values .. (10g) ?
или я что-то пропустил

Там на минуточку не просто values, но values(:1,:2,:3).
Дальше вспоминаем про bind-array и получаем пакетную вставку :)
13 май 16, 15:49    [19169533]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
andrey_anonymous
Какие пики? +append сериализует вставки (TM6).
Если параллельных сессий много, то заметят сра-жу-зе.
если моя догадка верна про insert-commit, то все зависит от того через сколько времени они заметили, что вставка идет медленно. Разница, конечно, будет но не такая уж и огромная - упрется в макс. размер пула и все, было ~10 активных сессий с полезной работой из 240 в пике, уменьшится до 1 с таким же пиком, всего-то ~ в 10 раз дольше будет будет пик
13 май 16, 16:01    [19169616]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
ora601
Member

Откуда:
Сообщений: 750
xtender
andrey_anonymous
Какие пики? +append сериализует вставки (TM6).
Если параллельных сессий много, то заметят сра-жу-зе.
если моя догадка верна про insert-commit, то все зависит от того через сколько времени они заметили, что вставка идет медленно. Разница, конечно, будет но не такая уж и огромная - упрется в макс. размер пула и все, было ~10 активных сессий с полезной работой из 240 в пике, уменьшится до 1 с таким же пиком, всего-то ~ в 10 раз дольше будет будет пик


Так параллельная сессия сразу свалиться с ORA-12838. Если по теме, то + за хэш партиционирование индекса.
13 май 16, 17:51    [19170355]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
ora601,

ORA-12838 возникает только если пытаешься модифицировать после direct insert в той же сессии до коммита
13 май 16, 17:55    [19170361]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
ora601
Member

Откуда:
Сообщений: 750
xtender
ora601,

ORA-12838 возникает только если пытаешься модифицировать после direct insert в той же сессии до коммита


Да, точно. Но в любом случае APPEND перпендикулярен проблеме, тем более что : "During a direct path load, the existing index is copied when it is merged with the new index keys.
If the existing index is very large and the number of new keys is very small, then the index copy time can offset the time saved by a direct path load."
13 май 16, 18:08    [19170389]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
ora601,

Ну append здесь появился как дополнение моему комменту 19169124
Он в принципе может быть к месту, если они грузят логи периодически, тогда проще было пачкой сразу загружать в одной сессии
13 май 16, 18:16    [19170416]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18351
xtender
Он в принципе может быть к месту


19169163
13 май 16, 18:41    [19170512]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
Sheriffua
Member

Откуда: г. Киев
Сообщений: 1223
Sergey_Korolev
Sheriffua,

Выложите ASH_REPORT с 13:30:00 по 13:35:00 12-May-16 плз


Уже в понедельник выложу отчет.

А смотрю тема набрала серьезный оборот. По возникновению данных пиков, они бывают в разное время, нет четкого понятия от чего они возникают, таблица чисто используется на логирование событий фиксации откуда пользователь пожаловал.
13 май 16, 19:11    [19170607]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
Sheriffua
Member

Откуда: г. Киев
Сообщений: 1223
Sergey_Korolev
Sheriffua,

Выложите ASH_REPORT с 13:30:00 по 13:35:00 12-May-16 плз


Выкладываю отчет за указанный период. А также вопрос, как узнать, какие объекты вызывают (индексы):
enq: TX - index contention
enq: TX - allocate ITL entry


К сообщению приложен файл (ASH_report_NEW.html - 26Kb) cкачать
16 май 16, 13:37    [19178601]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
Sergey_Korolev
Member

Откуда:
Сообщений: 153
Sheriffua,

Нужен еще отчет AWR за этот же период времени.
16 май 16, 14:29    [19178926]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
Sheriffua
Sergey_Korolev
Sheriffua,

Выложите ASH_REPORT с 13:30:00 по 13:35:00 12-May-16 плз


Уже в понедельник выложу отчет.

А смотрю тема набрала серьезный оборот. По возникновению данных пиков, они бывают в разное время, нет четкого понятия от чего они возникают, таблица чисто используется на логирование событий фиксации откуда пользователь пожаловал.
по-прежнему либо 19169124 либо 19168070
16 май 16, 14:41    [19179027]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
Sheriffua
Member

Откуда: г. Киев
Сообщений: 1223
Sergey_Korolev
Sheriffua,

Нужен еще отчет AWR за этот же период времени.


Отчет AWR

К сообщению приложен файл (awr_report.zip - 40Kb) cкачать
16 май 16, 15:45    [19179467]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
dba123
Member

Откуда:
Сообщений: 1054
Sheriffua,

а не могли бы ещё ддл показать?
execute  sys.dbms_metadata.set_transform_param(sys.dbms_metadata.session_transform, 'CONSTRAINTS', true);
execute  sys.dbms_metadata.set_transform_param(sys.dbms_metadata.session_transform, 'PRETTY', true);
execute  sys.dbms_metadata.set_transform_param(sys.dbms_metadata.session_transform, 'SQLTERMINATOR', true);
execute  sys.dbms_metadata.set_transform_param(sys.dbms_metadata.session_transform, 'CONSTRAINTS_AS_ALTER', true);
execute  sys.dbms_metadata.set_transform_param(sys.dbms_metadata.session_transform, 'STORAGE', true);
execute  sys.dbms_metadata.set_transform_param(sys.dbms_metadata.session_transform, 'SEGMENT_ATTRIBUTES', true);
execute  sys.dbms_metadata.set_transform_param(sys.dbms_metadata.session_transform, 'TABLESPACE', true);

select dbms_metadata.get_ddl('INDEX','OPW_PK', 'ICC_RRR') from dual;
select dbms_metadata.get_ddl('TABLE','OPERATION_WEB', 'ICC_RRR') from dual;
select dbms_metadata.get_ddl('SEQUENCE','OPW_ID_SEQ', 'ICC_RRR') from dual;
17 май 16, 11:09    [19182463]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
Sheriffua
Member

Откуда: г. Киев
Сообщений: 1223
dba123
Sheriffua,

а не могли бы ещё ддл показать?
execute  sys.dbms_metadata.set_transform_param(sys.dbms_metadata.session_transform, 'CONSTRAINTS', true);
execute  sys.dbms_metadata.set_transform_param(sys.dbms_metadata.session_transform, 'PRETTY', true);
execute  sys.dbms_metadata.set_transform_param(sys.dbms_metadata.session_transform, 'SQLTERMINATOR', true);
execute  sys.dbms_metadata.set_transform_param(sys.dbms_metadata.session_transform, 'CONSTRAINTS_AS_ALTER', true);
execute  sys.dbms_metadata.set_transform_param(sys.dbms_metadata.session_transform, 'STORAGE', true);
execute  sys.dbms_metadata.set_transform_param(sys.dbms_metadata.session_transform, 'SEGMENT_ATTRIBUTES', true);
execute  sys.dbms_metadata.set_transform_param(sys.dbms_metadata.session_transform, 'TABLESPACE', true);

select dbms_metadata.get_ddl('INDEX','OPW_PK', 'ICC_RRR') from dual;
select dbms_metadata.get_ddl('TABLE','OPERATION_WEB', 'ICC_RRR') from dual;
select dbms_metadata.get_ddl('SEQUENCE','OPW_ID_SEQ', 'ICC_RRR') from dual;


Результат:
+

CREATE UNIQUE INDEX "ICC_RRR"."OPW_PK" ON "ICC_RRR"."OPERATION_WEB" ("OPW_ID") 
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS 
STORAGE(INITIAL 65536 NEXT 10485760 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "RSR_INDX" 

  CREATE TABLE "ICC_RRR"."OPERATION_WEB" 
   (	"OPW_ID" NUMBER NOT NULL ENABLE, 
	"OT_OT_ID" NUMBER NOT NULL ENABLE, 
	"DT_SYSTEM" DATE NOT NULL ENABLE, 
	"USR_USR_ID" NUMBER, 
	"RC_OP_STATUS" NUMBER NOT NULL ENABLE, 
	"IS_OPW_SUCCESS" NUMBER(1,0) NOT NULL ENABLE, 
	"LOGIN" VARCHAR2(50), 
	"IP_ADDRESS" VARCHAR2(64), 
	"DOC_DOC_ID" NUMBER, 
	 CONSTRAINT "OPW_PK" PRIMARY KEY ("OPW_ID")
  USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS 
  STORAGE(INITIAL 65536 NEXT 10485760 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "RSR_INDX"  ENABLE, 
	 CONSTRAINT "OPW_OT_FK" FOREIGN KEY ("OT_OT_ID")
	  REFERENCES "ICC_RRR"."DICT_OPERATION_TYPES" ("OT_ID") ENABLE
   ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
  STORAGE(INITIAL 65536 NEXT 10485760 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "RSR_TAB" 
 

 CREATE SEQUENCE  "ICC_RRR"."OPW_ID_SEQ"  MINVALUE 1 MAXVALUE 999999999999999999999999999 INCREMENT BY 1 START WITH 949457608 CACHE 20 NOORDER  NOCYCLE 

17 май 16, 11:30    [19182604]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
слюбитель этого дела
Guest
Ящик свопится небось.

Надо включить huge pages для SGA, выставить filesystemio_options в setall, удалить workload статистику (если включали)
17 май 16, 11:36    [19182653]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
Судя по последнему AWR и конкуренции на "ICC_RRR"."OPW_PK" можно попробовать сделать его REVERSE (если часто не юзается RANGE SCAN)
17 май 16, 12:34    [19183055]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
Sergey_Korolev
Member

Откуда:
Сообщений: 153
Sheriffua,

Как уже предлагалось в
19169110|>
сделайте
alter sequence ICC_RRR.OPW_ID_SEQ cache 100000;


и смотрите помогло ли...
17 май 16, 13:47    [19183660]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
Sheriffua
Member

Откуда: г. Киев
Сообщений: 1223
Sergey_Korolev
Sheriffua,

Как уже предлагалось в
19169110|>
сделайте
alter sequence ICC_RRR.OPW_ID_SEQ cache 100000;


и смотрите помогло ли...


Спасибо, изменил для OPV_ID_SEQ и OPW_ID_SEQ, буду наблюдать (реверс пока не пробовал).
17 май 16, 14:13    [19183832]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
Ну да, 28 сек можешь сэкономить на ожидании SQ
17 май 16, 14:18    [19183864]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
Это таблица логов....
17 май 16, 14:38    [19184025]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
Sheriffua
Member

Откуда: г. Киев
Сообщений: 1223
После внесения изменений, которые рекомендовали здесь 19183660 (для OPV_ID_SEQ 1000, а для OPW_ID_SEQ 10000), наблюдаю следующую картину (см.вложение), неужели таки нужен реверс?

К сообщению приложен файл (awr_report_new.zip - 46Kb) cкачать
18 май 16, 10:05    [19187359]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
djeday84
Member

Откуда: default city
Сообщений: 540
Sheriffua,

проверьте наличие IRS


select min(begin_interval_time) start_time,max(begin_interval_time) end_time, sql_id, plan_hash_value,
sum (nvl(executions_delta,0)) execs,
round (sum ((elapsed_time_delta/decode(nvl(executions_delta,0),0,1,executions_delta))/1000000),1) avg_etime,
round (sum ((buffer_gets_delta/decode(nvl(buffer_gets_delta,0),0,1,executions_delta)) ),1)avg_lio,
round ( sum (DISK_READS_DELTA/decode(nvl(DISK_READS_DELTA,0),0,1,executions_delta)),1) avg_pio
from DBA_HIST_SQLSTAT S, DBA_HIST_SNAPSHOT SS
where sql_id in (select sql_id from dba_hist_sql_plan where object_name='OPW_DOC_FK_I' and operation='INDEX' and options='RANGE SCAN')
and ss.snap_id = S.snap_id
and ss.instance_number = S.instance_number
and executions_delta > 0
group by sql_id, plan_hash_value
order by 5 desc;


возможно что он вам и не подходит
18 май 16, 11:27    [19187784]     Ответить | Цитировать Сообщить модератору
 Re: Периодические подвисания в БД, как быть?  [new]
Sheriffua
Member

Откуда: г. Киев
Сообщений: 1223
djeday84
Sheriffua,

проверьте наличие IRS


select min(begin_interval_time) start_time,max(begin_interval_time) end_time, sql_id, plan_hash_value,
sum (nvl(executions_delta,0)) execs,
round (sum ((elapsed_time_delta/decode(nvl(executions_delta,0),0,1,executions_delta))/1000000),1) avg_etime,
round (sum ((buffer_gets_delta/decode(nvl(buffer_gets_delta,0),0,1,executions_delta)) ),1)avg_lio,
round ( sum (DISK_READS_DELTA/decode(nvl(DISK_READS_DELTA,0),0,1,executions_delta)),1) avg_pio
from DBA_HIST_SQLSTAT S, DBA_HIST_SNAPSHOT SS
where sql_id in (select sql_id from dba_hist_sql_plan where object_name='OPW_DOC_FK_I' and operation='INDEX' and options='RANGE SCAN')
and ss.snap_id = S.snap_id
and ss.instance_number = S.instance_number
and executions_delta > 0
group by sql_id, plan_hash_value
order by 5 desc;


возможно что он вам и не подходит


Хм.. Приведенный запрос ничего не возвращает.
18 май 16, 12:24    [19188055]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Oracle Ответить