Коллеги, здравствуйте!
Нужна помощь в прояснении ситуации.
В нашей организации есть read-only базы cache дружественной нам организации. Для выполнения определенного анализа данных настроен импорт данных из баз в нашу, развернутую на mssql2k8r2. Импорт выполняется с помощью t-sql скриптов, выполняемых через слинкованные сервера к cache.
Замечено, что после запуска наших скриптов в рандомном порядке валится служба mssql.

Конфигурация:
- mssql 2008r2 x64 10.50.2500.0;
- odbc-драйвер cache.2014.1.3.ODBCDriver_x64;
- Cache for Windows (x86-64) 2014.1.3 (Build 775);

Строка соединения линкованного сервера: @provstr=N'DRIVER={InterSystems ODBC};SERVER=<servername>;DATABASE=<dbname>;'

Почему такое происходит и что сделать, чтобы такое больше не происходило?

DAiMor,

запрос не рандомный, но написан как dynamic sql (сконструирован, короче). В нем ничего такого, просто выборка из класса/таблицы, помещение во временную таблицу (и перекладывание в основную - служба валится даже без этой части запроса).
Запрос может несколько раз отработать, а потом без видимых причин валится служба скуля. До сегодня списывалось на фазу луны, потому что делалось в dev-окружении, но готовится переезд на prod и не хочется там завалить службу.

DAiMor,

Служба скуля падает рандомно. Т.е. скрипт можно несколько раз запустить, а на какой-то рандомный раз завалится служба. Так же замечено, что если этот скрипт запускать в нескольких окнах, но для разных cache-баз, то через некоторое время это тоже приведет к аварийному завершению службы, но случится это раньше.

У нас развернуто 30+ виртуальных машин, на каждой по инстансу cache с базой. Из каждой такой виртуалки нужно забрать к себе в одну mssql базу - классическая задача.

Например, была ситуация, когда я этот скрипт запускал последовательно для каждого из cache-серверов из списка (dynamic sql как раз нужен для того, чтобы подставить имя линкованного cache-сервера) и где-то на 15-20 раз падала служба скуля. А в другой раз я открыл пять окон и параллельно запустил один и тот же скрипт (но для разных cache-баз) и тоже заваливалась служба, но в этот раз долго не пришлось ждать.

servit,
скорректировал параметры линкования в соответствии с Вашей рекомендацией. Обновил sql 2008r2 до sp3.

Запустил свой скрипт 4 удачных раза (проходил руками по списку баз), на пятый получил ошибку: Сообщение 7347, уровень 16, состояние 1, строка 1
Поставщик OLE DB "MSDASQL" для связанного сервера <ЗдесьИмяЛинка> вернул для столбца "[MSDASQL].House" данные, по размеру не соответствующие ожидаемым данным. Максимально ожидаемая длина данных 100, тогда как длина возвращенных данных 102.


После чего служба sql-сервера упала.

Запрос был такой (упростил):

При повторных перезапусках скрипта пока не повторяется...

Теперь у меня две проблемы: падение службы и исключение, выбрасываемое, судя по всему, oledb-провайдером о_О

Property House As Address.EHouse;


который в свою очередь:
Property Num As %String;


где %String:
/// The maximum number of characters the string can contain.
Parameter MAXLEN As INTEGER = 50;


Сейчас повторилась ситуация, когда любые запросы к cache через линковку, зависают на неопределенное время. У меня такое уже было некоторое время назад. Помогал только рестарт службы sql-сервера.

Может быть я взял кривую версию odbc-драйвера? Качал с сайта интерсистемс: cache.2014.1.3.ODBCDriver_x64.exe , версия файла 16.0.0.400, версия продукта 1.00.0000 от 13.01.15 16:13

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

servitТогда должно ожидаться 50, а не 100. Нет?
Похоже взведенный ключ Unicode=1 привел к такому удвоению.

servitА если взять поновее?
Так можно? В этом разделе форума видел обсуждение про odbc-драйвер, советовали использовать версию соответствующую версии cache

servitПоиграйтесь с ODBC query timeout
Думаю, закрытие зависших процессов в Портале тоже должно решить проблему.
Проблема зависания повторябельна для всех +30 виртуальных cache. Там по своему порталу ведь. Дело точно в mssql. У него снесло крышу после того исключения, почему-то.

servitНе заметил Unicode=1 в
Сделал в соответствие с рекомендацией:

servitПопробуйте использовать драйвер совместимый с ODBC 3.5 вместо ODBC 2.5 и явно указывайте все параметры, например:

Обновил версию драйвера на эту: cache.2015.1.0.ODBCDriver_x64.exe
Запустил на оставшихся +25 базах - все ок, sql-сервер не падал, исключений не выбрасывал, но я кастанул выбираемые поля к нужной длине, т.е. сделал так: CAST(Addresses.House->Num as varchar(50)) as House