Столкнулся с весьма странной проблемой при отмене долгого запроса. Двухдневный поиск ничего не дал.
Итак, есть хранимая процедура, вызывающая хранимую процедуру на связанном сервере:
EXEC [LINKED_SERVER]...sp_test
Если при её работе в Query Analyzer'e нажать "Cancel", то запрос остаётся бесконечно "висеть" в состоянии runnable на связанном сервере.
При некотором кол-ве таких повисших запросов сервер впадет в кому...
После этого, все процедуры, которые используют связанный сервер в запросах вида
select * from main_server.test_table
inner join openquery([LINKED_SERVER],"....")"
перестают работать и в том же Query Analyzer'e выдают следующие ошибки:
1. Could not start a transaction for OLE DB provider 'SQLOLEDB'.
[OLE/DB provider returned message: Cannot create new transaction because capacity was exceeded.]
2. [OLE/DB provider returned message: Connection is busy with results for another command]
3. И ещё что-то про manual or distributed transaction.
Здравствуйте, Smirnov.Anton, Вы писали:
SA>а если попробовать закрыть окошечко?
Не помогает даже реконнект. Всё проходит само по истечении какого-то таймаута на сервере.
Примерно 10 минут.
SA>здесь
Ответ там не впечатляет.
Как же всё-таки грамотно грохнуть запрос так, чтобы умерло всё с ним связанное?
Здравствуйте, eagle_sw, Вы писали:
_>Как же всё-таки грамотно грохнуть запрос так, чтобы умерло всё с ним связанное?
Kill { <spid — коннекта> | <UOW — распределенной транзакции> }
Вообще почитай про эту комманду, там много любопытного.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, eagle_sw, Вы писали:
_>>Как же всё-таки грамотно грохнуть запрос так, чтобы умерло всё с ним связанное? M>Kill { <spid — коннекта> | <UOW — распределенной транзакции> } M>Вообще почитай про эту комманду, там много любопытного.
Сабж. Пример с Query Analyzer'ом — надуманный,
воспроизводящий проблему прерывания запроса из моей программы.
Хотелось бы узнать общий подход к отмене распределённой транзакции.
Здравствуйте, eagle_sw, Вы писали:
_>Сабж. Пример с Query Analyzer'ом — надуманный, _>воспроизводящий проблему прерывания запроса из моей программы.
В чем проблема запустить kill из программы?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, eagle_sw, Вы писали:
_>>Сабж. Пример с Query Analyzer'ом — надуманный, _>>воспроизводящий проблему прерывания запроса из моей программы. M>В чем проблема запустить kill из программы?
Здравствуйте, eagle_sw, Вы писали:
_>Это общепринятая практика?
Общепринятая практика заключается в том, чтобы не выполнять запросов требующих отмены. То есть, скорее всего это проблема дизайна приложения, а не недостаток средств сиквела...
В крайнем случае можно настроить query governor на отмену запросов выполняющихся больше какого-то времени..
M>Общепринятая практика заключается в том, чтобы не выполнять запросов требующих отмены. То есть, скорее всего это проблема дизайна приложения, а не недостаток средств сиквела...
Да что ж это все за правила такие?! Откуда это все? Общепринятая практика — не выполнять ad-hoc запросов для анализа годичных данных?
Здравствуйте, Igor Trofimov, Вы писали:
iT>Да что ж это все за правила такие?!
А вот такие.
iT> Общепринятая практика — не выполнять ad-hoc запросов для анализа годичных данных?
Общепринятая практика — применять ad-hoc запросы исключительно в административных целях, а возможность анализа годичных данных закладывать в начальный дизайн систеы. Да и вообще это OLAP задача по большему счету.
iT>> Общепринятая практика — не выполнять ad-hoc запросов для анализа годичных данных? M>Общепринятая практика — применять ad-hoc запросы исключительно в административных целях, а возможность анализа годичных данных закладывать в начальный дизайн систеы. Да и вообще это OLAP задача по большему счету.
Ну, в общем, да, конечно. Запрос на анализ годичных данных к OLTP отнести сложно. Тут не поспоришь.
И что из того?
Если это OLAP-задача — то ее не надо решать?
Никаким начальным дизайном не получится сделать так, чтобы ad-hoc запросы выполнялись быстро на произвольных объемах данных.
Здравствуйте, Igor Trofimov, Вы писали:
iT>Если это OLAP-задача — то ее не надо решать?
Где я такое сказал? Это значит, что решать ее надо средствами OLAP и для этого есть Analisys Servises и куча паттернов по оптимизации, и по живой базе, в любом случае, такой запрос пол-дня не выполняется, да еще так, чтобы была насущная необходиость его отменять.
iT>Никаким начальным дизайном не получится сделать так, чтобы ad-hoc запросы выполнялись быстро на произвольных объемах данных.
Стоп, давай опять разберемся с терминологией... ad-hoc запросы, в моем понимании, это запросы не предусмотренные в системе. Естественно, твое утверждение верно, но какое отношение имеют ad-hoc запросы к поднятой теме?
Автору топика требуется отменять не ad-hoc, а вполне прогнозируемые запросы, и рекомендация, соответственно, писать эти самые запросы таким образом, чтобы отменять не приходилось, что вообщем-то не rocket science, хотя, конечно, от задачи зависит...
Или опять моя категоричность не устраивает?
M>Где я такое сказал? Это значит, что решать ее надо средствами OLAP и для этого есть Analisys Servises и куча паттернов по оптимизации, и по живой базе, в любом случае, такой запрос пол-дня не выполняется, да еще так, чтобы была насущная необходиость его отменять.
Необходимость отменять естественным образом появляется из-за
а) длительности запроса
б) любой степени интерактивности
Юзер ошибся, спросил не то, что хотел и конечно, лучше запрос прервать, чем попусту грузить сервак.
Что же касается специальных OLAP-средств, то иногда требования к системе таковы, что ad-hoc запросы должны выполняться именно на живой базе — т.е. на самых последних данных. Ведь существует такая ниша как гибридные OLAP/OLTP системы.
А может быть и так, что анализа в системе очень мало, чтобы ради него разрабатывать OLAP-часть, но этот анализ есть и оптимальнее выходит производить его именно в той же базе (например, раз в месяц какие-то отчеты считаются).
Я это все к тому, что чистая OLTP-система — это очень хорошо, но на практике встречается редко.
iT>>Никаким начальным дизайном не получится сделать так, чтобы ad-hoc запросы выполнялись быстро на произвольных объемах данных. M>Стоп, давай опять разберемся с терминологией... ad-hoc запросы, в моем понимании, это запросы не предусмотренные в системе. Естественно, твое утверждение верно, но какое отношение имеют ad-hoc запросы к поднятой теме?
Да, каюсь, это я не в ту степь ушел.
У него длинная процедура, тоже небось отчет какой-то, но, ты прав, это можно попытаться оптимизировать различными средствами.
Правда, все равно не факт, что это можно соптимизировать до такой степени, что не захочется отменять.
И вполне может оказаться, что обеспечить возможность прерывания таких длинных запросов обойдется дешевле, чем разрабатывать средства кардинального улучшения производительности этой (и, возможно, других подобных) процедуры.
Здравствуйте, Igor Trofimov, Вы писали:
iT>Необходимость отменять естественным образом появляется из-за iT>а) длительности запроса
Не должно быть таких запросов, и не надо говорить, что это невозможно... Все зависит от лени разработчика и оправданности оптимизации. Если лень, всегда есть kill и QG, но "правильная" система обходится без таких запросов.
iT>б) любой степени интерактивности
Интерактивности во время запроса? Отказать...
iT>Что же касается специальных OLAP-средств, то иногда требования к системе таковы, что ad-hoc запросы должны выполняться именно на живой базе — т.е. на самых последних данных.
Ни вапрос, промежуточную агрегацию и другую оптимизацию еще никто не отменял, "самые последние" данные чудным образом высчитываются с любой необходимой скоростью, а остальное выгребается из OLAP если есть такая необходимость.
Это всего лишь вопрос оптимизации.
iT>Ведь существует такая ниша как гибридные OLAP/OLTP системы.
Естественно, и в этих системах по OLTP базе запросы пролетают с OLTP коростью, юзер до кнопки дотянуться не успеет, чтобы его отменить.
iT>А может быть и так, что анализа в системе очень мало, чтобы ради него разрабатывать OLAP-часть, но этот анализ есть и оптимальнее выходит производить его именно в той же базе (например, раз в месяц какие-то отчеты считаются).
Бога ради и их можно с оптимизировать так, чтобы юзер не заскучал.
iT>Я это все к тому, что чистая OLTP-система — это очень хорошо, но на практике встречается редко.
Никто не спорит, степень OLTP'шности определяется конкретной задачей.
iT>Правда, все равно не факт, что это можно соптимизировать до такой степени, что не захочется отменять.
Факт. Вопрос необходимости и затраченых усилий...
iT>И вполне может оказаться, что обеспечить возможность прерывания таких длинных запросов обойдется дешевле, чем разрабатывать средства кардинального улучшения производительности этой (и, возможно, других подобных) процедуры.
Вполне. Только вопрос-то был "как правильно" и по моему, возможно не очень скромному мнению, "правильно" с оптимизировать систему на столько, чтобы юзер до кнопки отмены дотянуться не успевал, а не придумывать способы отмены запросов. А уж на сколько такая оптимизация будет оправдана в каждом конкретном случае — совсем другой вопрос.
M>Не должно быть таких запросов, и не надо говорить, что это невозможно... Все зависит от лени разработчика и оправданности оптимизации. Если лень, всегда есть kill и QG, но "правильная" система обходится без таких запросов. M>Ни вапрос, промежуточную агрегацию и другую оптимизацию еще никто не отменял, "самые последние" данные чудным образом высчитываются с любой необходимой скоростью, а остальное выгребается из OLAP если есть такая необходимость.
Лень тут не при чем вообще. Промежуточная аггрегация может быть малоэффективна, если возможных аналитических признаков много и заранее неизвестны группировки, которые потребуются. Объем данных за счет предварительной аггрегации по всем измерениям в этом случае может снизиться очень незначительно, а выделить только "нужные" — может не получиться.
iT>>б) любой степени интерактивности M>Интерактивности во время запроса? Отказать...
Нет конечно, имеется в виду, что пользователь тем или иным образом задает параметры запроса, а значит, может ошибиться и понять это через секунду после нажатия на кнопку "Посчитать". Если запрос будет выполняться хотя бы пару минут, это уже повод, чтобы сделать возможность прерывания и вовсе НЕ повод, чтобы пытаться этот запрос оптимизировать в несколько раз (что может быть очень нетривиальной задачей, влекущей за собой существенную переделку базы).
iT>>А может быть и так, что анализа в системе очень мало, чтобы ради него разрабатывать OLAP-часть, но этот анализ есть и оптимальнее выходит производить его именно в той же базе (например, раз в месяц какие-то отчеты считаются). M>Бога ради и их можно с оптимизировать так, чтобы юзер не заскучал.
Да, но сколько это будет стоить? Зачем делать мощнейшую (в разы или на порядки) оптимизацию, если можно все существующие проблемы решить проще? Замечу — сама длительность выполнения в рассматриваемом случае не является проблемой.
iT>>И вполне может оказаться, что обеспечить возможность прерывания таких длинных запросов обойдется дешевле, чем разрабатывать средства кардинального улучшения производительности этой (и, возможно, других подобных) процедуры. M>Вполне. Только вопрос-то был "как правильно" и по моему, возможно не очень скромному мнению, "правильно" с оптимизировать систему на столько, чтобы юзер до кнопки отмены дотянуться не успевал, а не придумывать способы отмены запросов. А уж на сколько такая оптимизация будет оправдана в каждом конкретном случае — совсем другой вопрос.
Ну вот а мне кажется, что это "правильное" решение может очень дорого встать. И проблемы надо решать существующие и предполагаемые, а не надуманные.
Вот аналогия тебе: надо тебе фильм переписать с компакта на винт. И вдруг — ОБА — оштбся и перетащил файл на сетевой диск. Блиииин! Он же туда час копироваться будет. А кнопки "Отмена" — нету. Звонишь ты в M$ и происходит такой разговор:
-- Почему нельзя прервать копирование? Что за фигня?
-- Ну мы постараемся ускорить копирование на сетевой диск.
-- Нет, просто сделайте кнопку "Отмена"
-- Это неправильно, любой процесс не должен давать пользователю заскучать. Мы проведем мега-оптимизацию, файл будет предварительно в фоновом режиме сжиматься и частично копироваться во все возможные свободные места, но будет невидимым, а потом когда юзер и правда захочет скопировать — мы в десять раз быстрее отрапортуем, что все сделано.
-- Да нахрена??? Не проще будет "Отмену" сделать?
-- А мы ленивых разработчиков не держим!
-- Но тогда мне надо не в десять раз быстрее копировать, а в тысячи — он же час копируется! А я хочу за секунду отменить!
-- Ох.. Ну, оптимизацией тысечекратный рост скорости копирования все-же сделать не получится, тут специальное железо нужно, называется OLFP, Online file processing, как раз для ваших случаев — сверх-быстрой обработки файлов гигабайтного размера.
-- Да я лучше кабель выдерну сетевой!!!
-- Ну что вы.. Это грязный хакинг, всякие kill'ы... Для неквалифицированного пользователя это не подходит.
-- Ну так встройте их в систему, чтобы подходило
-- Это неправильно. И вообще, правильная система обходится без таких длинных операций, которые надо прерывать! так что будем оптимизировать!
Здравствуйте, Igor Trofimov, Вы писали:
iT>Лень тут не при чем вообще.
Причем-причем...
iT>Да, но сколько это будет стоить?
Да какая разница? Вопрос-то ни в стоимости, а в том, что такая система все равно будет "правильнее".
iT>Зачем делать мощнейшую (в разы или на порядки) оптимизацию,
Да ни каких порядков..
iT>Ну вот а мне кажется, что это "правильное" решение может очень дорого встать.
Еще раз, вопрос стоимости мы не рассматриваем, это отдельная тема.
iT>И проблемы надо решать существующие и предполагаемые, а не надуманные.
Надуманного в этих проблемах нет ничего. Работать с ситемой которая не требует отмены, на порядок удобнее, чем с ситемой которая эту отмену поддерживает и вынуждена использовать.
iT>Вот аналогия тебе:
Давай вот только без ложных аналогий..
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eagle_sw, Вы писали:
_>>Это общепринятая практика? S>Нет. Общепринятая практика — не прерывать запросов
Я бы сказал не так — не писать таких запросов, которые было-бы необходимо прерывать
iT>>Зачем делать мощнейшую (в разы или на порядки) оптимизацию, M>Да ни каких порядков..
Конечно, на порядки. Если процедура час выполняется?
iT>>Ну вот а мне кажется, что это "правильное" решение может очень дорого встать. M>Еще раз, вопрос стоимости мы не рассматриваем, это отдельная тема.
То есть ты предлагаешь делать только "правильно" не взирая на последствия в стоимости? Имхо, ты не прав. Если эта оптимизация потребует переделать половину базы, усложнит все последующие доработки в разы, приведет из-за этого к большому количеству ошибок и, в конечном счете задержит проект на полгода — ты считаешь это приемлемой ценой за "правильность"?
Я уж не говорю, что "правильность" эта вовсе из бронзы не отлита, а просто ты сказал "неправильно отменять запрос".
iT>>И проблемы надо решать существующие и предполагаемые, а не надуманные. M>Надуманного в этих проблемах нет ничего. Работать с ситемой которая не требует отмены, на порядок удобнее, чем с ситемой которая эту отмену поддерживает и вынуждена использовать.
Проблема производительности в данном треде — самая что ни на есть надуманная.
Странные у тебя понятия об удобствах Удобнее после мега-оптимизации ждать минуту завершения никому ненужного расчета, чем за секунду отменить его кнопкой "Отмена"? По-моему это уже просто несерьзный разговор пошел.
M>Давай вот только без ложных аналогий..
Ну а все-таки? По-моему очень даже в тему. Что там самое ложное?
Здравствуйте, Igor Trofimov, Вы писали:
iT>Конечно, на порядки. Если процедура час выполняется?
Значит не правильная процедура. Да и вообще, должно быть что-то сильно не так в системе, если по ней процедуры по часу гоняются, тут по любому оптимизировать придется, а скорее всего перепроектировать.
iT>То есть ты предлагаешь делать только "правильно" не взирая на последствия в стоимости?
Да ну вот зануда.. Ну посмотри на вначало топика, я не предлагаю "делать правильно", я отвечаю на вопрос "как в принципе правильно", а уж как надо в конкретном случае — думаю автор разберется.
iT> Имхо, ты не прав.
Прав, имхо, разумеется.
iT>Я уж не говорю, что "правильность" эта вовсе из бронзы не отлита, а просто ты сказал "неправильно отменять запрос".
И правильно, надо заметить, сказал.
iT>Проблема производительности в данном треде — самая что ни на есть надуманная.
Какая проблема?
iT> Удобнее после мега-оптимизации ждать минуту завершения никому ненужного расчета, чем за секунду отменить его кнопкой "Отмена"?
В который раз уже говорю, после "мега-оптимизации" юзер до кнопки даже дотянуться не успеет...
iT> По-моему это уже просто несерьзный разговор пошел.
Да давно уже...
M>>Давай вот только без ложных аналогий.. iT>Ну а все-таки? По-моему очень даже в тему. Что там самое ложное?
Всё.
Во-первых это не БД задача, а во вторых, у правильного приложения либо не будет возможности перепутать диск и сеть, либо даже копирование по сети уже будет достаточно быстро, чтобы не анноить юзера, когда попадет к тому в руки.
Мы уже победили, просто это еще не так заметно...
Это значит, что решать ее надо средствами OLAP и для этого есть Analisys Servises и куча паттернов по оптимизации, и по живой базе, в любом случае, такой запрос пол-дня не выполняется, да еще так, чтобы была насущная необходиость его отменять.
По-моему это уже просто несерьзный разговор пошел.