request synchronization error

[AntonYa]

Описание условий: запрос выполняется через isql с другого сервера, до этого момента все выполнялось без ошибок, никаких изменений на БД не производилось.

При запросе вылетает ошибка :
Statement failed, SQLCODE = -901
request synchronization error

Другим приложением не пробовал выполнить ?

сейчас делаю выгрузку с помощью IBEScript.
но это если чесно не вариант - после выгрузки файл обрабатывается - awk и делать это под Windows при таких обьемах данных...
В оригинале скрипт стартует с линукса...

[AntonYa]

вопрос, может он и не в тему - но хочется ограничить кол-во возможных причин ошибки (плюс сузить варианты поиска причин проблемы) - данная ошибка может возникать при неправильных данных в таблице или это проблема в самом запросе?

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

а как ее исправить?

[AntonYa]

Описание условий: запрос выполняется через isql с другого сервера, до этого момента все выполнялось без ошибок, никаких изменений на БД не производилось.

При запросе вылетает ошибка :
Statement failed, SQLCODE = -901
request synchronization error

Другим приложением не пробовал выполнить ?

сейчас делаю выгрузку с помощью IBEScript.
но это если чесно не вариант - после выгрузки файл обрабатывается - awk и делать это под Windows при таких обьемах данных...
В оригинале скрипт стартует с линукса...

в IBEScript выдало ошибку
Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
request synchronization error.

[Attid]

да, используется в основном запросе процедуры...

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

1:30

это в минутах или часах ?

[AntonYa]

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

в процедуре для select указан план по которому она работает - таблицу по которой идет IN он смотрит по другому индексу, а IN - уже добирает натуралом...

это в минутах или часах ?

часах...

[Attid]

остается ждать ответ Влада , что нибуть другое советовать без исходного кода процедуры нельзя, но ставлю пиво что без изменения структуры можно ускорить её минимум раза в три, а с изменением меньше минуты.

как минимум

для select указан план по которому она работает

использовать не советуют , чтобы не столкнутся когда нибуть с невостановимым бекапам, лучше +0 гвоздиком прибить где нибуть.

[AntonYa]

можно ускорить её минимум раза в три, а с изменением меньше минуты.

пробовали, еще когда тестировали...

использовать не советуют , чтобы не столкнутся когда нибуть с невостановимым бекапам, лучше +0 гвоздиком прибить где нибуть.

в принципе - что направлять план принудительно с помощью +0 что указать тот же план... а про невосстановимый backup если честно не слышал. [/quote]

[Dmitry Dyachenko]

Всем привет.

Вот основной запрос в процедуре.

SELECT
Agreements.BranchID,
/* список полей */
PrivateClients.ClientPrivID
FROM Accounts, Agreements, PrivateClients
WHERE Accounts.ContractID = Agreements.ContractID
AND PrivateClients.ClientPrivID = Agreements.ClientPrivID
AND agreements.enrolled <= :o_BalanceDate
AND Accounts.BalNumClassID IN (2,4,6,8,10,12,16,34,36,41,42,45,46,49,50)
PLAN JOIN (AGREEMENTS NATURAL, ACCOUNTS INDEX (IND_ACCOUNTS_CONTRACTID), PRIVATECLIENTS INDEX (IND_PRIVATECLIENTS_CLIENTPRIVID))

Он возвращает единицы миллионов записей. Дальше в цикле идут запросы, выбирающие одну запись из одной таблицы в каждом случае. Таких запросов много, но работает это достаточно быстро, объединение этого в один запрос не дало выиграша по производительности, хотя наверное просто мало пытались. Для каждой строки вызывается четыре раза datetostr из RFunc и strreplace ещё откуда-то (может наша, может из RFunc). Тут раньше была утечка памяти, может никкуда не далась и дело в этом. [Антон, на память посмотрите.] Также вызывается два раза другая процедура, как EXECUTE, делает запросы к архивной таблице. Больше ничего особенного вроде нет.

[hvlad]

Протокол менять не пробовал ?

В 1.5.х портируются только исправления из основных веток, касающиеся безопасности.
Советую проверить это на 2.0.3 (и клиент, и сервер), если и там такая же беда, то жду воспроизводимого примера.

[Attid]

AND Accounts.BalNumClassID IN (2,4,6,8,10,12,16,34,36,41,42,45,46,49,50)

Он возвращает единицы миллионов записей.

если вместо цыферок запрос который работает хотя бы сотую долю секунду, он будет выполнятся "единицы миллионов" раз или 2 часа на миллион.

[Dmitry Dyachenko]

использовать не советуют , чтобы не столкнутся когда нибуть с невостановимым бекапам

а про невосстановимый backup если честно не слышал.

Тут наверное имеется в виду использование RDB$ имен индексов в планах. И может быть в меньшей степени о изменениях индексов, после чего они перестают быть пригодными для использования в плане. Первого избегаем, за вторым вроде обычно следим.

[Dmitry Dyachenko]

если вместо цыферок запрос который работает хотя бы сотую долю секунду, он будет выполнятся "единицы миллионов" раз или 2 часа на миллион.

Не уверен, что понял, о чем ты. Два момента:
- по IN не используются индексы
- с производительностью проблемы нет, есть проблема с ошибкой при выборке большого количества данных.

Мое предположение пока - datetostr. Стоит их убрать и попробовать ещё раз.

[Dmitry Dyachenko]

Протокол менять не пробовал ?

Говорят, что в строке connect'а стоит IP. То есть протокол TCP/IP. Стоит пробовать локальный протокол? Воспроизводимый пример может быть с помощью while удастся получить, подумаем.

[Attid]

если вместо цыферок запрос который работает хотя бы сотую долю секунду, он будет выполнятся "единицы миллионов" раз или 2 часа на миллион.

Не уверен, что понял, о чем ты. Два момента:
- по IN не используются индексы
- с производительностью проблемы нет, есть проблема с ошибкой при выборке большого количества данных.

Мое предположение пока - datetostr. Стоит их убрать и попробовать ещё раз.

производительность 1:30 - это не нормально особенно если вы утверждаете что в процедуре только получение данных, без изменений других данных.

запрос который ты показал не может работать час, даже при десятках милионов, или там что-то важное забыли или одно из двух =)

Стоит пробовать локальный протокол?

локальный должен быть быстрее
но имхо проблема не в нем.

[AntonYa]

производительность 1:30 - это не нормально особенно если вы утверждаете что в процедуре только получение данных, без изменений других данных.
запрос который ты показал не может работать час, даже при десятках милионов, или там что-то важное забыли или одно из двух =)

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

Дима, насколько я знаю проблема с утечкой памяти была решена.

[Dmitry Dyachenko]

запрос который ты показал не может работать час, даже при десятках милионов, или там что-то важное забыли или одно из двух =)

Я рассказал, что там ещё. Самые тяжелые - вызовы процедур, читающих из архивной таблицы по счетам. Я не знаю, как ускорить без архивации состояния всех счетов за каждый день, что вызывает быстрый рост базы. Тут было бы здорово, если бы кто подсказал, как лучше. Но это уже не по теме, вынесу в отдельную наверное. То есть причина 1:30 в тех вызовах, но проблема не в этом, а в ошибке.

[Merlin]

Склероз мне шепчет, что сходные (возможно, не дословно) сообщения случались
а) на превышении предусмотренной глубины рекурсии
б) на каких-то старых (а 1.5.2 - далеко не девочка) версиях при использовании Break в For Select (причём не всегда)
в) что-то смутное насчёт дистинкта и подзапросов (но совсем смутно)

[Dmitry Dyachenko]

а) на превышении предусмотренной глубины рекурсии

Явной рекурсии нет, причин для срабатывания триггеров тоже.

б) на каких-то старых (а 1.5.2 - далеко не девочка) версиях при использовании Break в For Select (причём не всегда)

Break нет. Но клиент и сервер разные, есть шанс на то, что это оно. Говорят, что клиент 1.5.5, сервер 1.5.2. [Попробуйте таки вернуть 1.5.2 клиента]

в) что-то смутное насчёт дистинкта и подзапросов (но совсем смутно)

Ни того ни другого. Есть один MAX. А вот UDF ещё одна нашлось незнакомая, сейчас собираю пример с ними всеми.

[AntonYa]

Break нет. Но клиент и сервер разные, есть шанс на то, что это оно. Говорят, что клиент 1.5.5, сервер 1.5.2. [Попробуйте таки вернуть 1.5.2 клиента]

Выборка ругалась и на версии 1.5.2...

[AntonYa]

Разделили выгрузку на две части - сформировалась...
Вопрос - нет ли ограничений на кол-во строк в файле или что-то подобного?
В операционке таких ограничений нет...