
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
25.06.2018, 15:37
|
|||
|---|---|---|---|
|
|||
ORA-01013 user requested cancel of current operation |
|||
|
#18+
Добрый день. На сервере приложения часто падают ошибки вида: ORA-01013 user requested cancel of current operation. Запрос делается по dblink, обычно выполняется за пару сек. Таймаут стоит в минуту, почему иногда не хватает этого времени? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.06.2018, 16:34
|
|||
|---|---|---|---|
|
|||
ORA-01013 user requested cancel of current operation |
|||
|
#18+
alex722 Таймаут стоит в минуту, почему иногда не хватает этого времени? Потому что гладиолус oracle rdbms не является ни системой реального времени, ни однопользовательской системой, ни системой тривиальной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.06.2018, 22:11
|
|||
|---|---|---|---|
|
|||
ORA-01013 user requested cancel of current operation |
|||
|
#18+
andrey_anonymous, так же считаю, но, возможно, у кого-то была похожая ситуация и нашлась таблетка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.06.2018, 11:33
|
|||
|---|---|---|---|
|
|||
ORA-01013 user requested cancel of current operation |
|||
|
#18+
alex722и нашлась таблетка... в виде увеличения тайм-аута? Или на время разбора проблемы "медленное исполнение запроса" или "просто навсегда"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.06.2018, 15:39
|
|||
|---|---|---|---|
|
|||
ORA-01013 user requested cancel of current operation |
|||
|
#18+
Basil A. Sidorov, увеличение тайм аута- это скорее костыль. Мне скорее интересно решение вопроса, чтобы запросы по dblink с одним и тем же sql_id отрабатывали за схожее время без достижения таймаута. Почему при одном и том же условии запрос может порой выполняться от нескольких секунд до более минуты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.06.2018, 15:52
|
|||
|---|---|---|---|
|
|||
ORA-01013 user requested cancel of current operation |
|||
|
#18+
alex722Мне скорее интересно решение вопроса 1. Сформулировать четкие критерии оптимизации. 2. По необходимости стабилизировать нагрузку на удаленный сервер (чтобы сгладить сайд-эффекты недостатка ресурсов (cpu, io, память, сеть) в моменты пиковых нагрузок). 3. Построить эффективный план выполнения запроса (как на "нашей стороне", так и на стороне "за dblink" - это два взаимосвязанных, но разных плана). Построение эффективного плана может включать в себя, помимо прочего, построение простых/составных/bitmap/функциональных/доменных индексов, реорганизацию схемы данных (в т.ч. денормализацию, partitioning, отказ от некоторых constraints), реорганизацию техпроцессов, в отдельных случаях - вплоть до внесения изменений в инфраструктуру и должностные инструкции. 4. Закрепить эффективный план любым удобным способом (прибить полным набором хинтов, использовать прочие инструменты plan stability (зависит от версии и редакции сервера)) 5. Попробовать со всей этой фигней на борту взлететь. 6. По результатам опытно-промышленной отказаться от DBLink в пользу более других инструментов Data Integration ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/search_topic.php?author=Bozhkov&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
get settings: |
10ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
152ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 450ms |
| total: | 697ms |

| 0 / 0 |
