как обойти 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, чтобы убедиться, что таблицы правильно связаны. Видимо вы еще какое-нибудь условие связи забыли - не может так долго идти выборка. И не поленитесь прописать хоть пару полей вместо *.

← →
Nikolay M. © (2005-08-11 19:13) [30]

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

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

← →
Anatoly Podgoretsky © (2005-08-11 19:45) [31]

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

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

← →
Anatoly Podgoretsky © (2005-08-11 19:45) [32]

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

← →
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...

← →
sniknik © (2005-08-11 20:37) [34]

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

← →
Fay © (2005-08-11 20:39) [35]

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

← →
sniknik © (2005-08-11 20:41) [36]

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

← →
Anatoly Podgoretsky © (2005-08-11 20:42) [37]

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

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

← →
Anatoly Podgoretsky © (2005-08-11 20:42) [38]

sniknik © (11.08.05 20:41) [36]
Сервер про это не знает

← →
sniknik © (2005-08-11 20:45) [39]

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

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

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

Anatoly Podgoretsky © (11.08.05 20:42) [38]
ну так можно ему это обьяснить ;о)

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

SET NOCOUNT ON

DECLARE @au_id varchar(11), @au_fname varchar(20), @au_lname varchar(40),
@message varchar(80), @title varchar(80)

PRINT "-------- Utah Authors report --------"

DECLARE authors_cursor CURSOR FOR
SELECT au_id, au_fname, au_lname
FROM authors
WHERE state = "UT"
ORDER BY au_id

OPEN authors_cursor

FETCH NEXT FROM authors_cursor
INTO @au_id, @au_fname, @au_lname

WHILE @@FETCH_STATUS = 0
BEGIN
PRINT " "
SELECT @message = "----- Books by Author: " +
@au_fname + " " + @au_lname

PRINT @message

-- Declare an inner cursor based
-- on au_id from the outer cursor.

DECLARE titles_cursor CURSOR FOR
SELECT t.title
FROM titleauthor ta, titles t
WHERE ta.title_id = t.title_id AND
ta.au_id = @au_id -- Variable value from the outer cursor

OPEN titles_cursor
FETCH NEXT FROM titles_cursor INTO @title

IF @@FETCH_STATUS <> 0
PRINT " <<No Books>>"

WHILE @@FETCH_STATUS = 0
BEGIN

SELECT @message = " " + @title
PRINT @message
FETCH NEXT FROM titles_cursor INTO @title

END

CLOSE titles_cursor
DEALLOCATE titles_cursor

-- Get the next author.
FETCH NEXT FROM authors_cursor
INTO @au_id, @au_fname, @au_lname
END

CLOSE authors_cursor
DEALLOCATE authors_cursor

2 tormoz (11.08.05 20:46) [40]
Попробуй [9]

2 tormoz (11.08.05 20:46) [40]
Запусти QA, напиши там свой запрос, нажми Ctrl+L

EXEC sp_configure "remote query timeout", 86400 RECONFIGURE WITH OVERRIDE

> sniknik © (11.08.05 20:53) [41]

Ты забыл автору посоветовать, чтобы прежде, чем он у себя такое запустит, заявление на отпуск написать :)

2 tormoz
Индекс на поля простой или составной? Сервер БД действительно сервер или просто бывший комп начальника?

← →
Ольга (2005-08-12 08:13) [49]

> а план запроса - это про что?

Работайте в Query Analyzer - жизнь станет легче, жизнь станет веселее.
Показать план запроса: Query -> Show Execution Plan (в окне результата выполнения запроса появится новая закладка)

← →
tormoz (2005-08-12 10:06) [50]

структура pf1(1550000 записей):
ID float 8 1 WFROM smallint 2 1 F_XA varchar 25 1 N_SR varchar 15 1 O_POL varchar 20 1 S_X varchar 1 1 SVNUM varchar 12 1 B_T varchar 10 1 B_PL varchar 60 1 AD_P varchar 80 1 SPOL varchar 7 1 NPOL varchar 8 1 T_L varchar 10 1 DOC_T varchar 40 1 A_T varchar 10 1 NDOG varchar 8 1

Структура pfp (950000 записей):
S_POL nvarchar 10 1 N_POL float 8 1 S_PAS nvarchar 25 1 DP nvarchar 10 1 F_PS nvarchar 25 1 I_RT nvarchar 20 1 O_T nvarchar 20 1 DR nvarchar 10 1 REGP nvarchar 10 1 REGS nvarchar 10 1 U_D nvarchar 30 1 DPL nvarchar 7 1 KW nvarchar 5 1 KV nvarchar 5 1 NDOG nvarchar 8 1 T_L nvarchar 12 1 S_TE nvarchar 10 1

План запроса он показал, как его можно скопировать? или просто написать, что там выведено?

tormoz (12.08.05 10:06) [50]
а индексы?

сдалай так (и проще и нагляднее получится) зайди в QA в дереве обьектов (если не включен его показ -> Tools->Object Browser->Show /Hide включи) выбираеш свою базу-таблицу, на таблице по правой кнопке мыши выбибираеш Script objects to New Window as->Create ... то что получилось копируй сюда вместо того что в [50].

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

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

Уже не в первый раз наблюдаю у тебя извращенческие наклонности :)
SET SHOWPLAN_TEXT ON
не катит? :)

> tormoz (12.08.05 10:06) [50]
- индексы запости. От у меня предчуствие, что составных нету.

> не катит? :)
чесно? не знал, не пользовался, и не знал. я счас попробовал и не впечатлило... инфы по сравнениюс тем чтонормально QA дает мало (не видно/не наглядно) т.что наверняка и не буду пользоваться.

> sniknik © (12.08.05 11:34) [54]

Вот на sql.ru есть возможность вставлять картинки в сообщение, чем народ и пользуется, когда показывает план запроса. Но ведь это sql.ru... :)

ANB © (12.08.05 11:26) [53]
О это вообще можная вещь позволяет выполнять запросы не обращаясь с самой таблице, что обеспечивает беспрецедентную скорость.

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