как обойти Timeot Expired

← →
tormoz (2005-08-11 15:26) [0]

Здравствуйте. Есть две таблицы: в первой 1550000 записей, во второй 950000. Необходимо выполнить запрос
SELECT pf1.* FROM pf1 INNER JOIN pfp ON pf1.SPOL = pfp.S_POL AND pf1.NPOL = pfp.N_POL
Точнее надо в первой таблице изменить значение одного поля, которое будет браться из второй таблицы по соответствию двух полей. Но не то что update, даже просто select не выполняется: пишет Timeout expired. Посоветуйте что-нибудь. Запросы пытаюсь выполнить через SQL Server Enterprise Manager.

← →
Fay © (2005-08-11 15:37) [1]

2 tormoz (11.08.05 15:26)
1) CommandTimeout = много.
2) Нафиг тебе SELECT?! Типа такого не прокатит?
update T1 set T1.Field2 = T2.Field2 from Table1 T1, Table2 T2 where T1.Field1 = T2.Field1

← →
Nikolay M. © (2005-08-11 15:52) [2]

> Fay © (11.08.05 15:37) [1]

Он имеет ввиду, что если селект отваливается по таймауту, то апдейт - тем более.

> пишет Timeout expired

Увеличить? И чем QA не угодил для выполнения запросов?

← →
Fay © (2005-08-11 16:00) [3]

2 Nikolay M. © (11.08.05 15:52) [2]

>> Он имеет ввиду, что если селект отваливается по таймауту, то апдейт - тем более.

Представь на секунду, что автор юзает клиентский курсор и ждёт когда к нему вползёт 950000 записей.

← →
Nikolay M. © (2005-08-11 16:09) [4]

Думаю, дело не в фетче. Ради эксперимента можно, конечно, поставить SELECT TOP 1 ...., но никто, имхо, в здравом уме не будет обрывать процесс передачи данных. Ко мне не раз приползал миллион записей, когда условие связки для какой-нибудь таблицы упускал - и ничего :)
А вот наличие индексов по связываемым полям и конфигурация сервера - это более актуальные вопросы.

← →
tormoz (2005-08-11 16:10) [5]

так ничего и не работает. сейчас пробую QA, запрос
update pf1 set pf1.ndog=pfp.ndog from pf1,pfp where (pf1.spol=pfp.s_pol) and (pf1.npol=pfp.n_pol)
выполняется уже 13 минут... :-(

← →
Fay © (2005-08-11 16:17) [6]

2 tormoz (11.08.05 16:10) [5]
А индексы есть? А триггеры?

← →
tormoz (2005-08-11 16:18) [7]

индексы - естественно, а тригеры пока еще не разрабатывал... потом надо будет делать, но не на update.

← →
Fay © (2005-08-11 16:19) [8]

2 tormoz (11.08.05 16:18) [7]
План запроса не покажешь?

← →
Fay © (2005-08-11 16:23) [9]

2 tormoz (11.08.05 16:18) [7]
set showplan_text on go set noexec on update pf1 set pf1.ndog=pfp.ndog from pf1,pfp where (pf1.spol=pfp.s_pol) and (pf1.npol=pfp.n_pol)

← →
Fay © (2005-08-11 16:24) [10]

2 tormoz (11.08.05 16:18) [7]
И вАщЕ, давай струкатуру этих таблиц с индексами!

← →
tormoz (2005-08-11 16:32) [11]

> Fay © (11.08.05 16:23) [9]

это к чему? так же не работает - висит, делает вид, что выполняется, и - НИЧЕГО...

← →
sniknik © (2005-08-11 16:33) [12]

для изменения одного поля, полное обьеднение... сделай левое. не в пример быстрее отработает
SELECT pf1.*
FROM pf1 LEFT JOIN pfp ON pf1.SPOL=pfp.S_POL AND pf1.NPOL=pfp.N_POL

плюс предварительно сделай индексы на полях pf1.SPOL и pf1.NPOL (в принципе на присоеденяемой таблице тоже не помешают... но эти вожнее)
глядиш и вложишся в таймаут. ;о))

а нет, то выполняй в QA там этот параметр можно изменить(может и в EM можно но не знаю как). в QA правой кнопкой мыши на сервере -> scripting options -> connections -> query time aut.
да и просто так, все одно выполняй в QA.

← →
Fay © (2005-08-11 16:35) [13]

2 sniknik © (11.08.05 16:33) [12]
>> сделай левое. не в пример быстрее отработает
Слишком категорично. Бывает быстрее, не более того. А бывает не в пример медленнее.

← →
sniknik © (2005-08-11 16:36) [14]

да, недосмтрел... добавка к запросу
WHERE pfp.S_POL IS NOT NULL

(иначе при переносе в апдейт потреш записи при пустых, ненайденых полях)

← →
sniknik © (2005-08-11 16:38) [15]

Fay © (11.08.05 16:35) [13]
ну... данный случай рассматриваем? тогда, представь себе полное декартово обьеденение по этим таблицам (обьемам). представил? а ведь делается полное при иннер а после отсекаются неподходящие.

← →
Fay © (2005-08-11 16:43) [16]

2 sniknik © (11.08.05 16:38) [15]
1) Вам бы сцнарии для ужастиков писать.
2) left join, конечно, совсем иначе работает, т.к. в общем случае возвращает больше записей. Так? Просто смешно.
3) Предлагаю подождать план запроса.

← →
Nikolay M. © (2005-08-11 16:53) [17]

> sniknik © (11.08.05 16:33) [12]
> для изменения одного поля, полное обьеднение... сделай левое.
> не в пример быстрее отработает

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

← →
sniknik © (2005-08-11 16:53) [18]

> 1) Вам бы сцнарии для ужастиков писать.
;о)) тяжела правда жизни....

> т.к. в общем случае возвращает больше записей.
см. "добавку" из [14]. тоже самое будет, а то и меньше.
(если в правой несколько подходящий под обьеденение записей то при иннер их будет больше)

> 3) Предлагаю подождать план запроса.
можно

← →
sniknik © (2005-08-11 16:56) [19]

> Nikolay M. © (11.08.05 16:53) [17]
не однозначность, догадка, но с хорошей долей вероятности (процентов 95 даю за себя ;о))).
просто сдесь обьем настолько большой что не удивлюсь если результат обьеденения в память не помещается и в кеш на винт скидывается...

← →
Fay © (2005-08-11 16:57) [20]

2 sniknik © (11.08.05 16:53) [18]
>> см. "добавку" из [14]
Конечно, я её видел. Специально проверял - план даёт как при inner join.
>> а то и меньше
Не вижу оснований для "меньше".

← →
Fay © (2005-08-11 16:59) [21]

2 sniknik © (11.08.05 16:56) [19]
>> если результат обьеденения в память не помещается
А что он (рузультат) там забыл (в памяти)?!

← →
sniknik © (2005-08-11 17:03) [22]

> Не вижу оснований для "меньше".
да, это я погорячился. столько же будет.

← →
Nikolay M. © (2005-08-11 17:24) [23]

> sniknik © (11.08.05 16:56) [19]
> просто сдесь обьем настолько большой что не удивлюсь если
> результат обьеденения в память не помещается и в кеш на
> винт скидывается...

Скорее всего, это так. И что с того?

← →
sniknik © (2005-08-11 17:53) [24]

> Скорее всего, это так. И что с того?
да нет. ничего. ;)
просто построить полное обьеденение и после вырезать ненужное, гораздо затратнее решение (на момент постройки, а не готового результата из которого уже все несовпадаюшее вырезано)
чем выбрать таблицу слева (не больше) и присоеденить к ней по одной запись таблицы права.
(в одном случае через умножение таблиц во втором через прибавление...)
это конечно все утрировано, при некоторых условиях (к примеру совпадениях только по одной записи), и сервер наверняка поступает не "чисто" таким образом. но догадка имеет место быть ;о)).
так слова
"в первой таблице изменить значение одного поля, которое будет браться из второй таблицы по соответствию двух полей"
воспринимаю как практически прямое указание, что совпадающих будет по одной...
а "чистое" произведение будет занимать (при 100 байтной суммовой записи) 137137 гигабайт. неудивительно что таймаут. ;о)

ну не знаю как обьяснить. ну вот - как ты думаеш? не о чемто не по поводу и т.д. а "как"?
знаеш? не знаеш? но ведь думаеш. ;о)) ну вот и тут тоже. вроде все очевидно, а обьяснить как к этому пришол тяжело. проще проверить практикой, и все.

← →
Fay © (2005-08-11 17:58) [25]

2 sniknik © (11.08.05 17:53) [24]
Далось Вам это произведение... Ни один вервер не станет его строить.

← →
sniknik © (2005-08-11 18:07) [26]

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

← →
sniknik © (2005-08-11 18:10) [27]

во. я понял. просто допишите туда к посту [12]+дополнение [15] одно большое ИМХО, и прочтите еще раз. и закончим на этом. ;о))

← →
Fay © (2005-08-11 18:11) [28]

2 sniknik © (11.08.05 18:10) [27]
OK 8)

← →
Ольга (2005-08-11 18:43) [29]

> tormoz (11.08.05 15:26)

Все же перед update выполните select, чтобы убедиться, что таблицы правильно связаны. Видимо вы еще какое-нибудь условие связи забыли - не может так долго идти выборка. И не поленитесь прописать хоть пару полей вместо *.

> sniknik © (11.08.05 17:53) [24]

Несколько сумбурно, но в целом понятно и, увы, неубедительно :(
Лично я на практике с таким не сталкивался, сколько статей по оптимизации и просто советов в форумах ни читал, ни разу не встречал такой "догадки". Но буду иметь ввиду, если вдруг однажды left join у меня побъет все рекорды скорости :)

sniknik © (11.08.05 17:53) [24]
чем выбрать таблицу слева (не больше) и присоеденить к ней по одной запись таблицы права.

Почему по одной?, столько раз сколько раз будет выполнено условие соединения и если при этом не будет индексоы, то правая таблица будет полностью сканировать, вот тут и получится декартово произведение, для каждой левой записи сканирование справа. И не важно внутреннее или внешнее соединение.
Для таких записей очень важны правильные индексы, что уйти от полного сканирования таблицы. Для указаных размеров может произойти 1 472 500 000 000 сравнений, так как никаких ограничений слева нет.

Хорошо если сервер догадается построить временный индекс, но расчитывать на это не стоит.

← →
tormoz (2005-08-11 20:32) [33]

Индексы построены по всем полям, в обоих таблицах, которые участвуют в запросе. Повторяю то, что должно получится. Есть две таблицы, в которых два поля (spol, npol в одной и s_pol,n_pol в другой) задают однозначное соответствие (для каждой записи в одной таблице во второй существует только одна запись), причем в первой таблице есть записи, которым во второй нет соответствия...
надо на основании этого полю ndog первой таблицы присвоить значения ndog из второй таблицы, учитывая все условия...есть еще условие(сразу про него забыл): в первой таблице записи, в которых должно произойти изменение поля, имеют обязательный параметр wfrom=9... В общем, надо построить запрос, который заменит значение одного поля в первой таблице в соответствии со значениями полей второй...

> Ольга (11.08.05 18:43) [29]

Разницы нет, я пробовал и одно поле выбрать... Это был просто тест... мне в итоге запрос нужен не select, а update...

Anatoly Podgoretsky © (11.08.05 19:45) [31]
Почему по одной?
субьективное мнение для данного случая, основанное на словах в вопросе
"в первой таблице изменить значение одного поля, которое будет браться из второй таблицы по соответствию двух полей"
ну вот не представляю по такому описанию изменение одной записи значениями и нескольких соответствий в другой таблице.

2 tormoz (11.08.05 20:32) [33]
Струкатуру, индексы и план запроса мы так и не увидим?

tormoz (11.08.05 20:32) [33]
сделай открытием курсора, сканом левой таблици с запросом на обновление для каждой записи. на сервере естественно. возможно и будет быстрее но сомневаюсь.

sniknik © (11.08.05 20:37) [34]
Я в целом говорил, а не частное.

Fay © (11.08.05 20:39) [35]
Хотелось бы (С) Председатель

Fay © (11.08.05 20:39) [35]
в общем да, было бы интересно. я уже готов сам тест делать, но боюсь места под такую базу у меня не хватит. (на всех винтах по 400-500мег максимум осталось ;(, уже винт себе дополнительный купил на 200гиг но вот вместо того чтобы установить его, сижу тут с вами треплюсь ;о))

← →
tormoz (2005-08-11 20:46) [40]

структуру щас подготовлю и выложу... а план запроса - это про что?

как обойти Timeot Expired Найти похожие ветки