MS SQL + Oracle = проблемы, или грязный межрассовый секс вместо нежной любви ?

Shlippenbaranus
Дата: 07.06.2011 13:15:41
Добрый день, не особо надеюсь на помощь, но все-таки.

Работаю с MS SQL 2005 со связанным сервером на Oracle (пусть он будет LEON). Открываю management studio, выполняю запрос
  select
    *
  from
    openquery(
      LEON, 'много букв'
  )
'
- запрос отрабатывает за несколько секунд. Работаю дальше, возвращаюсь к указанному запросу - а он вдруг берет, и "повисает". Как теперь оказалось, в действительности запрос продолжает выполняться, но очень долго - от получаса до многих часов.

При этом:

1) попытка прервать выполнение запрос из интерфейса management studio оказывается безуспешной - сообщение executing query в строке статуса сменяется на canceling query, и все;

2) попытка выполнить тот же запрос через другой связанный сервер, отличающийся от первого выбором провайдера (LEON - MSDAORA, альтернативный - OraOLEDB.Oracle) приводит к аналогичному "зависанию";

3) попытка выполнить тот же запрос через openrowset без обращения к связанному серверу, т.е. вот так:
  select
    *
  from
    openrowset(
      'OraOLEDB.Oracle',
      'алиас из tnsnames.ora';'юзер';'пароль',
      'тот же запрос'
    )
приводит к аналогичному зависанию;

5) попытка несущественно изменить текст запроса (в предельном случае - ПЕРЕНЕСТИ СКОБКУ В ДРУГУЮ СТРОКУ), и выполнить "новый" запрос любым способом приводит к тиому, что "новый" запрос завершается за несколько секунд. А "старый", при этом, продоложает "висеть".

Отмечу, что объем изменений, которые нужно произвести для того, чтобы запрос снова выполнился за неск-ко секунд, может быть разным: в предельном случае, как я уже указал, достаточно перенести скобку в другую строку, в обычном - написать что-нибудь вроде
  select
    *
  from
    openrowset(
      'OraOLEDB.Oracle',
      'алиас из tnsnames.ora';'юзер';'пароль',
      'select * from (изначальный запрос)'
    )
, иногда нужно избавиться от аналитических функций в запросе, т.п.

Кроме того, отмечу, что (а) "на самом оракле", т.е. в sqlplus, исходный запрос всегда выполняется быстро, (б) проблемы не наблюдались при выполнении запросов, не использующих аналитические функции, (в) тестировавшийся запрос стал вести себя странно после того, как в процессе работы я попытался прервать выполнение альтернативного запроса на связаном сервере, (г) ни SQL сервер, ни Oracle с тех пор не перегружались.

Вопрос к почтенному обществу: что это может быть, и где искать?

И главное: способен ли MS SQL 2005 СТАБИЛЬНО работать в связке с Oracle 11g, или я должен ждать необычных проблем в необычных местах постоянно?
Гавриленко Сергей Алексеевич
Дата: 07.06.2011 13:22:06
Shlippenbaranus
И главное: способен ли MS SQL 2005 СТАБИЛЬНО работать в связке с Oracle 11g, или я должен ждать необычных проблем в необычных местах постоянно?
Судя по довольно большому количеству вопросов, скорее всего второе.
BestZvit
Дата: 07.06.2011 15:15:00
Shlippenbaranus
а он вдруг берет, и "повисает". Как теперь оказалось, в действительности запрос продолжает выполняться, но очень долго - от получаса до многих часов.


1. Смотрел - в Oracle запрос-то в это время (пока ты висишь) реально выполняется ? Или там он уже не ничего не делает, а просто ты принять к себе данные не можешь (причин тут м.б. море) ?

2. Планы на стороне Оракла не поплыли ?
3. Утечек памяти в пуле MSSQL нет ?
4. Утечек памяти в dll-ках в провайдере нет ? (логи смотрели ? Нет ли в логах ошибок, пусть по первому взгляду даже будет казаться, что эти ошибки к функционалу и не относятся)
5. MSSQL 2005 - небось совсем без сервис паков ? (Очень напоминает)

... и т.д. и т.п.

PS
Если лень истреблять саму причину, а достаточно любой затычки - переносите "СКОБКУ В ДРУГУЮ СТРОКУ" и радуйтесь молниеносности отработки (вот только надолго ли.. )
Shlippenbaranus
Дата: 07.06.2011 19:09:42
BestZvit
1. Смотрел - в Oracle запрос-то в это время (пока ты висишь) реально выполняется ? Или там он уже не ничего не делает, а просто ты принять к себе данные не можешь (причин тут м.б. море) ?
2. Планы на стороне Оракла не поплыли ?
3. Утечек памяти в пуле MSSQL нет ?
4. Утечек памяти в dll-ках в провайдере нет ? (логи смотрели ? Нет ли в логах ошибок, пусть по первому взгляду даже будет казаться, что эти ошибки к функционалу и не относятся)
5. MSSQL 2005 - небось совсем без сервис паков ? (Очень напоминает)

... и т.д. и т.п.

PS
Если лень истреблять саму причину, а достаточно любой затычки - переносите "СКОБКУ В ДРУГУЮ СТРОКУ" и радуйтесь молниеносности отработки (вот только надолго ли.. )


Спасибо за советы. Посмотреть что-то на стороне Oracle я не могу по административным причинам, что касается логов - симметричная ситуация наблюдается на двух MS SQL серверах, но одинаковых ошибок в логах я не вижу. Cервис-пак SP3.

Что касается лени - есть такое слово "текучка". И она по мне уже матом ругается :).
Mnior
Дата: 07.06.2011 19:19:34
Стабильно работающей вещи не получится как ни крути. Но на проблемы с подвисанием не нарывался ни разу - стабильно. Да, рубить бесполезно, если лоханулся с запросом (условиями). Да, чувствителен к тексту (аля коменты) и типам данных. Про версии оракловского клиента ваще молчу.

Были утечки памяти (на 32х), периодические падения из-за ошибок в оракловском клиенте работающем в окружении MS SQL процесса.

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

Сочувствую.
Outproc ora
Дата: 07.06.2011 20:22:01
Mnior
Стабильно работающей вещи не получится как ни крути. Но на проблемы с подвисанием не нарывался ни разу - стабильно. Да, рубить бесполезно, если лоханулся с запросом (условиями). Да, чувствителен к тексту (аля коменты) и типам данных. Про версии оракловского клиента ваще молчу.

Были утечки памяти (на 32х), периодические падения из-за ошибок в оракловском клиенте работающем в окружении MS SQL процесса.

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

Сочувствую.


В свойствах провайдера, кстати, "outproc" ставить не пробовали ?
Glamorama
Дата: 08.06.2011 00:29:13
У меня работает только через OraOLEDB.Oracle, с MSDAORA любви не получилось.
Глюки бывали при работе с 9i (вплоть до падения SQL Server и необходимости перезагрузки Windows), с 11g всё работает стабильно (правда статистики маловато - всего лишь пара запросов каждый день).
Поэкспериментируйте с дровами на стороне SQL Server, заплатками к Oracle. А проблем с сеткой между серверами нет случаем?
Mnior
Дата: 14.06.2011 16:27:33
Outproc ora
"outproc" ставить не пробовали ?
Решили опять/снова/повторить данный вариант. Да, большинство запросов отвалилось. НО, мы на этом не остановились и решили копать. И нашли условие работоспособности!!!:
EXEC('begin ... end;', ... ,<LastParam>) AT OraLinkName
Если последний параметр
  • или не OUT
  • или не NULL (до вызова)
  • или остаётся NULL в результате (после вызова)

    Ура!!!!!!!

    Версия провайдера: 11.2.0.1.0

    Когда у нас было 32 битная система приходилось увеличивать -g <memory_to_reserve>. И если в OUT параметрах вдруг затесался не NULL (до вызова), то утечка памяти была большой и эта память быстро забивалась.

    Сейчас 64 битная, да и провайдер другой. Посмотрим.

    По ходу придётся отказываться от своих высказываний: 10204549
  • Memory Leak
    Дата: 14.06.2011 16:33:09
    Mnior
    Когда у нас было 32 битная система приходилось увеличивать -g <memory_to_reserve>. И если в OUT параметрах вдруг затесался не NULL (до вызова), то утечка памяти была большой и эта память быстро забивалась.


    А теперь утечка памяти маленькая и память забивается не так быстро ?
    egaraev
    Дата: 14.06.2011 17:04:12
    Советую поставить все патчи на Оракл клиента, все патчи на МС СКЛ Сервер. Мне это помогло, правда это было примерно год назад, т.ч. деталей не помню...