Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Очень странная проблема с временными таблицами  [new]
Maksim Masliy
Member

Откуда:
Сообщений: 18
Ситуация:

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

Иногда время выполнения INSERT INTO #... по неизвестным причинам 5 минут, причем процедура вызывается 3 раза, и только один инсерт делает проблемы, все остальные работают быстро (данных всего ничего). "Проблемный" инсерт - меняется от запуска к запуску, то есть один и тот же может отработать один раз нормально, но затормозить в следующий.

Временные таблицы создаются явно в начале процедуры:

CREATE TABLE #Purchases1 (...)
CREATE TABLE #Purchases2 (...)
CREATE TABLE #Purchases3 (...)

INSERT INTO #Purchases1
SELECT ...

INSERT INTO #Purchases2
SELECT ...

INSERT INTO #Purchases3
SELECT ...
/* работает 6 минут */

Если я переношу обьявление таблицы внутри процедуры и ставлю его предыдущим перед вставкой данных в эту таблицу, процедура отрабатывает 3 раза за 10-14 секунд.


CREATE TABLE #Purchases1 (...)
INSERT INTO #Purchases1
SELECT ...

CREATE TABLE #Purchases2 (...)
INSERT INTO #Purchases2
SELECT ...

CREATE TABLE #Purchases3 (...)
INSERT INTO #Purchases3
SELECT ...
/*работает 10 секунд*/

Кто-то сталкивался с таким, или может подсказать в чем проблема?

Буду преблагодарен!
31 май 05, 19:05    [1585866]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
jimmers
Member

Откуда: Санкт-Петербург - New York City
Сообщений: 5069
Скажите, а что говорит информация о блокировках?

С уважением,
Мартин Рахманов
http://jimmers.russia.webmatrixhosting.net/
31 май 05, 20:13    [1586035]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Профилером посмотреть не судьба?
1 июн 05, 07:45    [1586470]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
Maksim Masliy
Member

Откуда:
Сообщений: 18
jimmers
Скажите, а что говорит информация о блокировках?

С уважением,
Мартин Рахманов
http://jimmers.russia.webmatrixhosting.net/


Не говорит ничего, временные таблицы не залочены, проверял...
1 июн 05, 10:41    [1586901]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Maksim Masliy
jimmers
Скажите, а что говорит информация о блокировках?

С уважением,
Мартин Рахманов
http://jimmers.russia.webmatrixhosting.net/


Не говорит ничего, временные таблицы не залочены, проверял...
Ну, процедура может длительно перекомпилироваться, локи могут быть наложены на те таблицы из которых сливаются данные во временные таблицы и т.п.
1 июн 05, 10:48    [1586938]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
Maksim Masliy
Member

Откуда:
Сообщений: 18
tpg
Maksim Masliy
jimmers
Скажите, а что говорит информация о блокировках?

С уважением,
Мартин Рахманов
http://jimmers.russia.webmatrixhosting.net/


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


Согласен, был такой вариант, но локи не обнаружились, а изменение кода (как указано выше) в 100% случаев решает проблему, не похоже на блокировку.
1 июн 05, 10:54    [1586972]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Профилер позволяет отслеживать много событий, в частности - перекомпиляцию ХП.
1 июн 05, 10:57    [1586982]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
Roman S. Golubin
Member

Откуда: 140002
Сообщений: 11541
Maksim Masliy
локи не обнаружились, а изменение кода (как указано выше) в 100% случаев решает проблему, не похоже на блокировку.


А после изменения кода процедуры к первоначальному виду опять начинает работать так же медленно?

Selectы в обоих случаях идентичны или может есть какие различия?
1 июн 05, 11:05    [1587032]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Я голосую за рекомпиляцию. А вообще интересно, как без профилера определялось, какой из стейтментов тормозит? :)
1 июн 05, 11:44    [1587252]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Crimean
Я голосую за рекомпиляцию. А вообще интересно, как без профилера определялось, какой из стейтментов тормозит? :)
Дык оп том и речь - с самого утра про профилер талдычу... ан - нет...
1 июн 05, 11:48    [1587271]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31596
Да это обычная перекомпиляция (3 шт.)

Посмотреть можно провыйлером на событие Recompile
1 июн 05, 14:01    [1587993]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
bantik
Member

Откуда:
Сообщений: 370
Maksim Masliy
Ситуация:


Временные таблицы создаются явно в начале процедуры:

CREATE TABLE #Purchases1 (...)
CREATE TABLE #Purchases2 (...)
CREATE TABLE #Purchases3 (...)


Кто-то сталкивался с таким, или может подсказать в чем проблема?

Буду преблагодарен!


Сделай в каждой временной таблице уникальный индекс (либо уж любой индекс)
1 июн 05, 16:44    [1588890]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
Maksim Masliy
Member

Откуда:
Сообщений: 18
bantik
Maksim Masliy
Ситуация:


Временные таблицы создаются явно в начале процедуры:

CREATE TABLE #Purchases1 (...)
CREATE TABLE #Purchases2 (...)
CREATE TABLE #Purchases3 (...)


Кто-то сталкивался с таким, или может подсказать в чем проблема?

Буду преблагодарен!


Сделай в каждой временной таблице уникальный индекс (либо уж любой индекс)


Чем поможет? Пока тестирую данных мало.
1 июн 05, 18:29    [1589410]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
Maksim Masliy
Member

Откуда:
Сообщений: 18
tpg
Crimean
Я голосую за рекомпиляцию. А вообще интересно, как без профилера определялось, какой из стейтментов тормозит? :)
Дык оп том и речь - с самого утра про профилер талдычу... ан - нет...


Перекомпиляция не берет много времени, я же говорил что на инсерте тормозить. Толдычить можно сколько угодно, тольео желательно в тему.
1 июн 05, 18:30    [1589414]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
Maksim Masliy
Member

Откуда:
Сообщений: 18
Crimean
Я голосую за рекомпиляцию. А вообще интересно, как без профилера определялось, какой из стейтментов тормозит? :)


Элементарно - PRINT GETDATE()
1 июн 05, 18:30    [1589416]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
Maksim Masliy
Member

Откуда:
Сообщений: 18
Roman S. Golubin
Maksim Masliy
локи не обнаружились, а изменение кода (как указано выше) в 100% случаев решает проблему, не похоже на блокировку.


А после изменения кода процедуры к первоначальному виду опять начинает работать так же медленно?

Selectы в обоих случаях идентичны или может есть какие различия?


Да, когда код возращаю к первоначальному виду - тормозит опять.

Запросы одинаковые, меняеться один параметр в условии отбора - целочисленная переменная. Обраружил еще интересную деталь: если вместо этой переменной ставлю hardcoded value проблема исчезает. Исчезает также если этот запрос динамическим делаю (исполняю потом с sp_executesql). Суть таже, подставить явно значение переменной в условие отбора.

Я бы понял если бы к переменной применял функцию какую-то (CAST, DATEDIFF и т.д.), в таком случае еще можно как-то обьяснить, но в данном случае все предельно просто:

SELECT ...
FROM ...
WHERE Field = @Variable

Работать работает, но в чем проблема так и не понимаю.
1 июн 05, 18:39    [1589463]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
bantik
Member

Откуда:
Сообщений: 370
bantik
Maksim Masliy
Ситуация:


Временные таблицы создаются явно в начале процедуры:

CREATE TABLE #Purchases1 (...)
CREATE TABLE #Purchases2 (...)
CREATE TABLE #Purchases3 (...)


Кто-то сталкивался с таким, или может подсказать в чем проблема?

Буду преблагодарен!


Сделай в каждой временной таблице уникальный индекс (либо уж любой индекс)


RTFM Разработчики MS SQL буквально поняли Кодда - в каждой таблице должны быть определены правила для однозначного выбора записи. А это индексом и делается. Без него много непонятных глюков бывает - врет @@rowcount, курсоры внезапно заканчиваются и пр.
1 июн 05, 18:45    [1589488]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Maksim Masliy
Запросы одинаковые, меняеться один параметр в условии отбора - целочисленная переменная. Обраружил еще интересную деталь: если вместо этой переменной ставлю hardcoded value проблема исчезает. Исчезает также если этот запрос динамическим делаю (исполняю потом с sp_executesql). Суть таже, подставить явно значение переменной в условие отбора.

См. тут - Почему похожие запросы имеют различные планы исполнения?
1 июн 05, 19:49    [1589666]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
bantik
RTFM Разработчики MS SQL буквально поняли Кодда - в каждой таблице должны быть определены правила для однозначного выбора записи. А это индексом и делается. Без него много непонятных глюков бывает - врет @@rowcount, курсоры внезапно заканчиваются и пр.

Ух ты. И примеры привести можете?
1 июн 05, 19:51    [1589668]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Maksim Masliy
tpg
Crimean
Я голосую за рекомпиляцию. А вообще интересно, как без профилера определялось, какой из стейтментов тормозит? :)
Дык оп том и речь - с самого утра про профилер талдычу... ан - нет...


Перекомпиляция не берет много времени, я же говорил что на инсерте тормозить. Толдычить можно сколько угодно, тольео желательно в тему.
И что ж такого я наталдычил не в тему? Пользование услугами профилера - обычная практика по поиску узких мест. Или первый раз про это слышим, принт - единственный способ диагностирования?
2 июн 05, 06:42    [1590066]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
Maksim Masliy
Member

Откуда:
Сообщений: 18
tpg
Maksim Masliy
tpg
Crimean
Я голосую за рекомпиляцию. А вообще интересно, как без профилера определялось, какой из стейтментов тормозит? :)
Дык оп том и речь - с самого утра про профилер талдычу... ан - нет...


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


Профилер в тему, но перекомпиляция не делает проблем, что понятно из вопроса по-моему. Кстати не профилер, ни принт не является единственным способом, в каждом случае нужно выбирать что-то подходящее для конкретного случая. По крайней мере я так считаю.
И считаю хорошей практикой вносить в код отладочную информацию, которую могу видеть или не видеть, не жалко один параметр добавить к процедуре. Заодно можно и результаты промежуточных запросов смотреть, и много чего другого, так что уважаемый профилер в некоторых случаях вынужден отдыхать...
2 июн 05, 10:25    [1590478]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
Maksim Masliy
Member

Откуда:
Сообщений: 18
GreenSunrise
bantik
RTFM Разработчики MS SQL буквально поняли Кодда - в каждой таблице должны быть определены правила для однозначного выбора записи. А это индексом и делается. Без него много непонятных глюков бывает - врет @@rowcount, курсоры внезапно заканчиваются и пр.

Ух ты. И примеры привести можете?


Действительно интересно, можно про это где-то более подробно почитать?
2 июн 05, 10:27    [1590481]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Maksim Masliy
Профилер в тему
Ну, и что тогда за наезды?
2 июн 05, 10:56    [1590645]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
Maksim Masliy
Member

Откуда:
Сообщений: 18
tpg
Maksim Masliy
Профилер в тему
Ну, и что тогда за наезды?


Я наездами не занимаюсь, мне проблему решить надо.
2 июн 05, 12:01    [1590958]     Ответить | Цитировать Сообщить модератору
 Re: Очень странная проблема с временными таблицами  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Планы выполнения обоих вариантов сравнивались?
2 июн 05, 12:15    [1591041]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить