Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2008.09.14;
Скачать: [xml.tar.bz2];

Вниз

Отмена выполнения запроса   Найти похожие ветки 

 
DmitriyG. ©   (2008-03-11 16:13) [0]

Можно ли для MSSQL 2005 сделать отмену выполнения запроса?
Вопрос мне кажется наболевший, но ответа нигде нет...


 
clickmaker ©   (2008-03-11 16:27) [1]

через что?


 
DmitriyG. ©   (2008-03-11 16:46) [2]

Наверное через ADO...
Вроде бы нашел
 ADOCommand.Execute;
 repeat
   Application.ProcessMessages;
   if IsAbort then
     ADOCommand.Cancel;
 until (stExecuting in ADOCommand.States = False);

Более элегантного я так понимаю не получится найти....


 
Johnmen ©   (2008-03-11 16:49) [3]

Что означает "отменить выполнение запроса"?


 
DmitriyG. ©   (2008-03-11 16:54) [4]

Прервать долго выполняющийся запрос


 
Johnmen ©   (2008-03-11 17:10) [5]

Это вряд ли получится.
Но попробуй асинхронно из другого потока. Не сможешь попробовать - забей. Лучше запросы пиши быстрые :))


 
DmitriyG. ©   (2008-03-11 17:16) [6]

Ага... А если база на терабайт? И ищем внтури xml например?
Я думаю ускроить вряд ли получиться, а вот отменить часто хочется... :-)


 
sniknik ©   (2008-03-11 17:24) [7]

> Вроде бы нашел
при синхронном выполнении ADOCommand.Execute; "отдаст" управление только после завершения выполнения запроса и получении рекордсета (при клиентском курсоре)
смысл дальнейшего кода нулевой...

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

> Более элегантного я так понимаю не получится найти....
а ты не ищи, ты изучай, и пиши по надобности то, что именно тебе необходимо.


 
sniknik ©   (2008-03-11 17:28) [8]

> Я думаю ускроить вряд ли получиться
зачем данные в которых делается поиск хранятся в виде не предназначеном для него?

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


 
ANB   (2008-03-11 18:04) [9]


> DmitriyG. ©   (11.03.08 16:46) [2]

1) Добавить в цикл Sleep
2) На время ожидания поднять формочку, в которой крутить мультики, с кнопкой отмена
3) Способа лучше нету. Тока убедись, что запрос выполняется асинхронно.

ЗЫ. Скептикам : у нас в фин.отчетности большая часть запросов выполняется часы. Ускорено уже по максимум (ранее выполнялось несколько суток).


 
sniknik ©   (2008-03-11 19:46) [10]

> 1) Добавить в цикл Sleep
зачем? там же есть Application.ProcessMessages;

> 2) На время ожидания поднять формочку, в которой крутить мультики, с кнопкой отмена
тогда и смысл Application.ProcessMessages; пропадает, не говоря о Sleep ... он (цикл выборки) же уже там есть, если ShowModal...
бред какойто в общем советуешь...

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

> Ускорено уже по максимум
уверен? а то судя по тому, что советуешь ...

> (ранее выполнялось несколько суток).
ну, это уж вообще не доказательство...


 
Ega23 ©   (2008-03-12 00:11) [11]


> включи полнотекстовый поиск (текст индексируется по словам
> из которых состоит) и ищи... быстро.


Кстати, о пцыцах.
А вот кок долго он будет строиться? (FTI)
Это нормально, что он у меня на 5.000.000 записей по прикидкам 2 суток будет строиться???


 
Johnmen ©   (2008-03-12 00:18) [12]


> Ega23 ©   (12.03.08 00:11) [11]
> А вот кок долго он будет строиться? (FTI)

Из практики - на P3 самом быстром на ~100 т.з. ~1 час.


 
Германн ©   (2008-03-12 02:31) [13]


> Ega23 ©   (12.03.08 00:11) [11]

Оффтоп по поводу русского языка. Но это нынче в моде.
Я бы написал "о пцицах". Или "о псИсах" :)


 
Ega23 ©   (2008-03-12 07:50) [14]


> Я бы написал "о пцицах". Или "о псИсах" :)


Откровенно говоря, не помню откуда это взялось.
Есть подозрение, что из грузинской рок-оперы "Муха Цокотуха". Очень интересное произведение было...  :)


 
ANB   (2008-03-12 09:40) [15]


> зачем? там же есть Application.ProcessMessages;

Мало. Процессор все равно лопается. Sleep(200) или 100 - в самую тему там.


> ShowModal...

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


> > Ускорено уже по максимум
> уверен? а то судя по тому, что советуешь ...


5 таблиц. в 1-й 20 000 000 записей. В остальных - примерно в 100 раз больше (истории всякие). Все сджойнить и сгруппировать.
Быстрее чем за полтора часа у меня не получилось. Если Вы сможете оптимизнуть круче - приходите к нам работать. Зарплатой мой начальник не обидит.


 
sniknik ©   (2008-03-12 10:43) [16]

>> ShowModal...
> - единственный способ показать форму ?
не единственный, а разумный (!)... делать показ по другому (по вашему) только затем чтобы после делать "костыль" из цикла с ProcessMessages вместо стандартной выборки сообщений, делающий тоже самое только хуже, глупо.

> не нравятся мне модальные формы по делу и без.
ты советовал показать форму на время выполнения запроса, какая разница нравиться тебе ее показывать модально или нет если показать так проще (писать меньше) и лучше ("костылей" нет)?
(мне например вон with не нравиться... но если я считаю что код с ним будет лучше (уберет например лишнюю переменную), я его все одно использую. невзирая на личные предпочтения)

> 5 таблиц. в 1-й 20 000 000 записей.
ну, таких у меня рабочих нет, хотя пробовать пробовал.
даже расказывал тут както (можеш найти в дайджестах) про столкновение с ораклом, когда клиент на вопрос, а че так долго (2 часа) на хваленом "самом быстром"? сказал "так 40 миллионов записей в таблице"... типа это чтото доказывает. дома сделал тест с той же структурой, нагенерил теже 40 миллионов случайных значений и написал запрос на тот же результат (не оптимизировал, а написал с 0, т.к. сами ихние запросы мне никто не да (сам ради интереса проверял), результат у меня получился за секунды... чего они там оптимизировали и как ради 2х часов х.з. правда я поставил это в заслугу MSSQL-ю т.к. тестил на нем, а "оригинал" был на оракле.

> Все сджойнить и сгруппировать.
цель разве в этом? а если возможен тот же результат вообще без джойнов, или групп... засчитается? ;)

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


 
DmitriyG. ©   (2008-03-12 11:11) [17]

Кстати приведенный в начале пример не рабочий - States сразу после выполения запроса = stClose... Так что пока ищу варианты...
А по поводу оптимизации данных и выборки всего нескольких записей скажу: - есть ситуации когда необходимо бывает стянуть на клиента тысяч 50 записей или например произвезсти поиск содержимому BLOB поля (в этом случае случае я думаю вряд ли можно как нибудь оптимизировать запрос)


 
Ega23 ©   (2008-03-12 11:17) [18]


> произвезсти поиск содержимому BLOB поля


Full-text Search?


 
sniknik ©   (2008-03-12 11:26) [19]

> есть ситуации когда необходимо бывает стянуть на клиента тысяч 50 записей
просто "стянуть" это даже секунду не займет, не то что время чтобы требовалась какаято особая обработка, типа формы на время выполнения... часиков в курсоре хватит.
(при приемлемом количестве полей в запросе разумеется, а то если "ширина" записи больше чем "высота" таблицы, тады ой...)

> в этом случае случае я думаю вряд ли можно как нибудь оптимизировать запрос
в этом случае нужно "оптимизировать" логику построения базы и работы с ней. ибо нефиг "поисковые" данные вкладывать внутрь BLOB полей.

> Full-text Search?
а если картинка, и поиск идет всех черных "пикселей"/группы... ? (в MSSQL блоб имеет название (тип) image, а текст так и есть text ...)


 
sniknik ©   (2008-03-12 11:28) [20]

> Кстати приведенный в начале пример не рабочий - States сразу после выполения запроса = stClose...
тебе что зря про асинхронные запросы говорили?... естественно он у тебя stClose при ...  -> [7] первый абзац.


 
Johnmen ©   (2008-03-12 11:33) [21]


> DmitriyG. ©   (12.03.08 11:11) [17]
> есть ситуации когда необходимо бывает стянуть
> на клиента тысяч 50 записей

Можно поподробней, что за ситуации, когда надо сразу столько записей?


 
Ega23 ©   (2008-03-12 11:36) [22]


> Можно поподробней, что за ситуации, когда надо сразу столько
> записей?


Есть, у меня аккурат сейчас такая.
Правда там, фактически, ID с небольшим заголовком тянется. А вот вся дополнительная инфа - уже через Master-detail и по одной записи...  :)


 
ANB   (2008-03-12 11:49) [23]


> цель разве в этом? а если возможен тот же результат вообще
> без джойнов, или групп... засчитается? ;)

Значится надо пройти по 20 миллионам договоров, по истории (около 100 миллионов записей) определить группу риска на дату, по остаткам в разрезе договоров (около 2-х миллиардов записей) вытащить на дату остатки разных 4-х типов, по таблице коммиссий в разрезе договоров (чуть больше миллиарда записей) вытащить остатки по 6 типам коммиссий на дату, выкинуть проданные и закрытые на дату договора (отсеется около 10%) тоже по таблицам с историей(2 таблицы, около 5 миллионов записей в каждой), по таблице продаж договоров (около 40 миллионов записей) уточнить тип договора. На основании выгребленных данных раскидать остатки и комиссии по отдельным полям, все сложить, сгруппировав по вычисленным типам договоров.
Т.е. на выходе примерно 5 записей.
Менять  структуру и заводить индексы низзя. Можно пользоваться времянками.


 
ANB   (2008-03-12 11:54) [24]


> не единственный, а разумный (!)... делать показ по другому
> (по вашему) только затем чтобы после делать "костыль" из
> цикла с ProcessMessages вместо стандартной выборки сообщений,
>  делающий тоже самое только хуже, глупо.

В принципе - вариант.
Только модальная форма же внутри себя сообщения обрабатывает - как тогда проверять, что запрос уже выполнился и уже мона форму закрыть ? Или придется писать свой цикл обработки сообщений.
Можно, конечно, в отдельном потоке запрос выполнять, но неудобно и граблей много.

Может поподробнее разжуешь - как с модальной формой это аккуратно сделать ?


 
sniknik ©   (2008-03-12 12:00) [25]

> Менять  структуру и заводить индексы низзя.
?, а дышать во время программирования можно?

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


 
ANB   (2008-03-12 12:08) [26]


> как это без индексов? а что ты тогда называешь оптимизацией,
>  фулскан сменяный на ... фулскан?

1. Индексы почти все нужные есть. Для выборки менее миллиона договоров (если запрошен конкретный тип, договоров с которым немного) я по ним запрос и сделал - за 20 секунд все считает (хотя все равно надо формочку показывать)
Нельзя тока новые индексы добавлять.
2. Фулл-скан фулл-скану - рознь. Правда, виртуозной оптимизацией мой начальник занимается. В частности, была аналогичная задача. План был на индексах. Считался больше суток да еще и RBS кончался через раз. После перевода на фулл-скан стал считаться 2 часа. Я не очень опытен в такой оптимизации, посему из того кода постоянно приемы и деру нагло.


 
sniknik ©   (2008-03-12 12:09) [27]

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

> Можно, конечно, в отдельном потоке запрос выполнять
"асинхронность" сама свой поток сделает, не стоит парится.

> но неудобно и граблей много.
Form.ShowModal; в одном месте и Form.Close; в другом это слишком много граблей?... нда, а ваша структура базы без индексов это что?


 
sniknik ©   (2008-03-12 12:12) [28]

> 1. Индексы почти все нужные есть.
по дате нету, если вам для "определить группу риска на дату" приходится "20 миллионам договоров" сканировать. или они все на один день? ("на дату") ???


 
ANB   (2008-03-12 12:20) [29]


> событие при завершении есть, я говорил.

Все. Понял. В бефоре - поднять форму, в афтер - закрыть.
Чет в одаке у меня эти события не всегда корректно ловились, посему я и ставил циклы ожидания.
Впрочем, обычно мне приходилась выполнять не запросы, а просто долго работующую хранимку/блок.
Действительно, вариант самый удобный, а мультик мона готовый на форму ожидания кинуть.
Единственно - нарывался на странный эффект, когда модальная форма уходила на задний план и приложение клинило. Причем даже в тодае такой эффект иногда вылезает.


> по дате нету, если вам для "определить группу риска на дату"
> приходится "20 миллионам договоров" сканировать. или они
> все на один день? ("на дату") ???

20 миллионов - это действующие договора. Для каждого из которых надо рассчитать несколько параметров. А потом уже эти параметры сложить.
Индекс по дате в историях есть - я же написал, есть запрос по индексам, но на количестве договоров более 2 миллионов его клинит.


 
sniknik ©   (2008-03-12 12:25) [30]

> когда модальная форма уходила на задний план и приложение клинило.
родитель у формы nil был.

> 20 миллионов - это действующие договора. ...
не. "лечение по фотографии" надо прекращать, вот с чего "его клинит" на 2х миллионах? у меня в тесте на 40ка не клинило а вас на 2х... не понимаю.


 
ANB   (2008-03-12 12:46) [31]


> родитель у формы nil был.

Не, нормально все прописывал - все равно, если переключаться между окнами, иногда пропадает. Особливо ShowMessage этим грешит.


> у меня в тесте на 40ка не клинило а вас на 2х... не понимаю.

А сколько таблиц и какого размера к этим 40-ка прикручивал ?

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

Ща приходится учится работать с большими объемами, для которых такие вещи не всегда прокатывают.

Короче - если сможешь на оракле еще ускорить такой запрос и аналогичные - начальник возьмет на работу с окладом не меньше моего (а то и больше). Сейчас у нас 2 человека сидят на оптимизации, один из которых - начальник и есть.


 
ANB   (2008-03-12 12:49) [32]


> вот с чего "его клинит" на 2х миллионах?

Не то чтобы совсем клинит, но фулл-скан стабильно где то за час все перелопачивает, причем количество договоров уже сильно не влияет на время. А по индексу - больше 2-х часов я ждать уже замучался. Да и юзеры жалуются, что падает с ошибкой (под RBS места не сильно много и увеличивать его значительно уже особо некуда).


 
DmitriyG. ©   (2008-03-13 11:07) [33]

Я конечно извиняюся за назойлисвость, но получается рабочего варианта отмены запросы пока никто не предложил. Дискусии на фига это нужно и что нужно оптимизировать и тому подобное конечно хорошо... Но бывают ситуации, что нужно прервать запрос, который будет выполняться даже заведомо 5 минут...


 
Sergey13 ©   (2008-03-13 12:00) [34]

> [33] DmitriyG. ©   (13.03.08 11:07)

В оракловом инструменте PL/SQL Delveloper это, насколько я понял, реализовано примерно так. Каждый запрос выполняется в отдельной сессии. При зависании запроса срубается сессия.


 
sniknik ©   (2008-03-13 12:17) [35]

> Каждый запрос выполняется в отдельной сессии.
им наверное приходится "выкручиваться" потому, что используемые ими компоненты/методы не поддерживают потоков/сессий/асинхронности самостоятельно. для ADO у которого есть асинхронный режим это лишнее.

> но получается рабочего варианта отмены запросы пока никто не предложил.
ты просто не понял предложенного, как не понял и найденного кода ([2]) который вполне рабочий, при определенных обстоятельствах.
...
можно и проще. вот код который отменяет запрос (прямой и точный ответ на заданный вопрос)
ADODataSet1.Close;
помогло? без понимания то.
(на самом деле просто прерывается работа клиентского потока, сервер его все одно "докрутит", но это практически у всех так)


 
ANB   (2008-03-13 13:04) [36]


> При зависании запроса срубается сессия.

Нет. Более того, сессию замучаешься срубать, если она чего то делает.
Девелопер открывает отдельную сессию для каждого окошка (если включена соответствующая настройка). За счет этого мона одновременно выполнять несколько запросов параллельно в разных окнах.
Есть специальная команда в OCI - "срубить запрос".


 
ANB   (2008-03-13 13:07) [37]


> сервер его все одно "докрутит", но это практически у всех
> так

в оракле не так. хотя можно умудрится проигнорить срубание. особенно, если выполняется хранимка.
Кстати, в мс скл, если лезть через DBLib, тоже аккуратно все срубается. Пример - QA.


 
Правильный_Вася   (2008-03-13 13:10) [38]

не знаю, будет жить или нет, но в качестве идеи

написать функцию, которая будет опрашивать некую сессионную переменную в БД (если такие есть в скуле)
при необходимости отмены запроса она выставляется из программы в нужное значение
функция встраивается в where запроса, ей передается параметром некое поле из таблицы (чтоб оптимизатор не подумал, что значение функции можно посчитать один раз и успокоиться), а сама функция возвращает нечто, что явно не дает выполниться остальной части запроса (напримар, false для условия and во where)


 
Sergey13 ©   (2008-03-13 13:29) [39]

> [36] ANB   (13.03.08 13:04)

Тогда почему кнопочка убийства запроса доступна только при многосессионной настройке?


 
ANB   (2008-03-13 13:31) [40]


> Правильный_Вася   (13.03.08 13:10) [38]

Скорее всего не будет работать.
Во время выполнения запроса сессия/коннект заняты и вызвать что то (чтобы установить сессионную переменную, про которые я в мс скл не слышал) именно для этой сессии не получится.
Плюс не факт, что исполнитель запросов отработает в таком режиме, даже если флаг останова подсунуть глобально через закомиченное изменение обычной таблицы. Плюс использование такой функции сильно тормознет выполнение запроса.



Страницы: 1 2 вся ветка

Форум: "Базы";
Текущий архив: 2008.09.14;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.58 MB
Время: 0.07 c
15-1216888228
Denis__
2008-07-24 12:30
2008.09.14
логика?


2-1217424279
@!!ex
2008-07-30 17:24
2008.09.14
Рабочая папка процесса.


2-1217484390
a.a.j.
2008-07-31 10:06
2008.09.14
inifiles vs xml


2-1217707354
demon
2008-08-03 00:02
2008.09.14
API и меню


15-1216271482
Dennis I. Komarov
2008-07-17 09:11
2008.09.14
MS WinXP SP3





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский