Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Новый топик    Ответить
 SQLSTATE=57014  [new]
SGrey
Member

Откуда:
Сообщений: 7
Столкнулся с проблемой:
При выполнении “тяжелых” SQL запросов на удаленном сервере иногда получаю

[DB2/NT] SQL0952N Обработка была отменена из-за прерывания SQLSTATE=57014

Если разворачиваю базу у себя локально, то такого никогда не происходит.
Ошибка “плавающая”, отчего зависит - не понял.

Подскажите, пожалуйста, что это такое и можно ли вылечить.
22 июн 10, 14:30    [8980102]     Ответить | Цитировать Сообщить модератору
 Re: SQLSTATE=57014  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4946
SGrey,

Что за приложение у вас?
22 июн 10, 17:11    [8981951]     Ответить | Цитировать Сообщить модератору
 Re: SQLSTATE=57014  [new]
SGrey
Member

Откуда:
Сообщений: 7
>>Что за приложение у вас?
Delphi -> ADO -> прямые SQL запросы.
Дело не в приложении.
У коллег на др. проектах та же самая ситуация.
Вывалится c SQLSTATE=57014 может и в SQL менеджере. Непредсказуемо.
Причем от времени выполнения запроса не зависит.
На одних и тех же запросах (разных, но “тяжелых”) могут быть данные, может быть пустой курсор, может быть SQLSTATE=57014.
Вроде бы зависит от нагрузки на сервер. Меньше сессий - меньше вероятность появления проблемы. Разворачиваем локально (т. е. нагрузка минимальна) - проблем нет.
Аномальное поведение DB2 проявляется на разном “железе”. От серверных “железяк” до убогих персоналок, работающих серверами DB2, если они удаленные и под “нагрузкой”.
Оптимизация запросов помогает . Например отказ от UNION и, почему то, JOIN.
Или отказ от сложного запроса и разбивка на серию менее сложных.
IMHO, но это не панацея. Оно же вывалится может в любой момент.
Я не DBA, я просто программер.
То ли ресурсов (чего ??) не хватает (каких??), то ли я не знай “тонкие” настройки DB2.
P.S
DB2 под WinXP устанавливались по умолчанию + регистрация в ODBC.[i][/i]
23 июн 10, 12:31    [8986313]     Ответить | Цитировать Сообщить модератору
 Re: SQLSTATE=57014  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4946
SGrey,

Попробуйте на клиенте из db2cw выполнить:
db2 update cli cfg for section dbalias using QUERYTIMEOUTINTERVAL 0
где dbalias - алиас этой БД на клиенте.
Перезапустите приложение.
23 июн 10, 12:58    [8986648]     Ответить | Цитировать Сообщить модератору
 Re: SQLSTATE=57014  [new]
BuryCommoner
Member

Откуда:
Сообщений: 177
Не знаю тот случай или нет. Была похожая фигня. В TADOQuery 30 секунд по умолчанию таймаут был, из-за этого запрос отваливался с ошибкой "Операция прервана пользователем".
24 июн 10, 07:36    [8991349]     Ответить | Цитировать Сообщить модератору
 Re: SQLSTATE=57014  [new]
SGrey
Member

Откуда:
Сообщений: 7
Спасибо

Mark Barinstein
а db2cw - это что? CLP ?

BuryCommoner
Нет, не тот. От таймаута в TADOQuery зависимость не обнаружили.
24 июн 10, 11:17    [8992645]     Ответить | Цитировать Сообщить модератору
 Re: SQLSTATE=57014  [new]
Favn
Member

Откуда:
Сообщений: 576
SGrey
а db2cw - это что? CLP ?
Ежели под виндой, то
IBM DB2 -> Command Line Tools -> Command Window
Окно shell, настроенное для работы с DB2.
24 июн 10, 12:16    [8993392]     Ответить | Цитировать Сообщить модератору
 Re: SQLSTATE=57014  [new]
Favn
Member

Откуда:
Сообщений: 576
SGrey,
На самом деле, сам когда-то натыкался на отваливание по таймауту.
В том же db2cw наберите
db2 ? SQL0952N
оно само все расскажет.
Скорее всего, причина именно в таймауте клиента DB2, а не в сервере или в ADO.
Выставив таймаут в 0, как советовал Марк, вы его отключите на данном клиенте.
24 июн 10, 12:23    [8993521]     Ответить | Цитировать Сообщить модератору
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Ответить