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

Откуда:
Сообщений: 63
Всем привет!
Один и тот же бекап поднят на двух разных серверах. Один и тот же запрос выполняется по разному. Т.е. разные планы и сильно отличается время выполнения. Статистику на все таблицы, учавствующие в запросе, мы обновляли, индексы перестраивали - результат тот же.

Вот тексты планов:
  |--Nested Loops(Inner Join, OUTER REFERENCES:([D].[SubUnit]))

       |--Filter(WHERE:((((([D].[Valuta]=[Cur].[Valuta] AND Convert(Convert([D].[CreateDate]))-datepart(weekday, Convert([D].[CreateDate]))+1=Convert(Convert([Cur].[Week]))-datepart(weekday, Convert([Cur].[Week]))+1) AND [D].[TypeDoc]=1) AND [D].[CreateDat

       |    |--Bookmark Lookup(BOOKMARK:([Bmk1002]), OBJECT:([FPTest].[dbo].[DOCUMENTS] AS [D]))

       |         |--Nested Loops(Inner Join, OUTER REFERENCES:([SART].[ID]))

       |              |--Nested Loops(Inner Join)

       |              |    |--Nested Loops(Inner Join, OUTER REFERENCES:([GV_SCL].[FuncID]))

       |              |    |    |--Clustered Index Scan(OBJECT:(GETVAL AS [GV_SCL]))

       |              |    |    |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1012], [Expr1013], [Expr1014]))

       |              |    |         |--Compute Scalar(DEFINE:([Expr1012]=Convert([GV_SCL].[FuncID])-1, [Expr1013]=Convert([GV_SCL].[FuncID])+1, [Expr1014]=If (Convert([GV_SCL].[FuncID])-1=NULL) then 0 else 6|If (Convert([GV_SCL].[FuncID])+1=NULL) then 0 e

       |              |    |         |    |--Constant Scan

       |              |    |         |--Clustered Index Seek(OBJECT:([FPTest].[dbo].[SUBARTICLES].[PK_SUBARTICLES] AS [SART]), SEEK:([SART].[ID] > [Expr1012] AND [SART].[ID] < [Expr1013]),  WHERE:((((Convert([SART].[ID])=[GV_SCL].[FuncID] AND [SART].[TypeB

       |              |    |--Clustered Index Seek(OBJECT:([FPTest].[dbo].[Currency].[PK_Currency] AS [Cur]), SEEK:([Cur].[Week] >= 'янв  3 2005 12:00AM' AND [Cur].[Week] <= 'фев  6 2005 12:00AM') ORDERED FORWARD)

       |              |--Index Seek(OBJECT:([FPTest].[dbo].[DOCUMENTS].[Sart] AS [D]), SEEK:([D].[SubArticle]=[SART].[ID]) ORDERED FORWARD)

       |--Clustered Index Seek(OBJECT:([FPTest].[dbo].[SUBUNITS].[PK_SubUnits] AS [SU]), SEEK:([SU].[ID]=[D].[SubUnit]) ORDERED FORWARD)


 |--Merge Join(Inner Join, MERGE:([SU].[ID])=([D].[SubUnit]), RESIDUAL:([SU].[ID]=[D].[SubUnit]))

       |--Clustered Index Scan(OBJECT:([FPTest].[dbo].[SUBUNITS].[PK_SubUnits] AS [SU]), ORDERED FORWARD)

       |--Nested Loops(Inner Join, WHERE:([D].[Valuta]=[Cur].[Valuta] AND Convert(Convert([D].[CreateDate]))-datepart(weekday, Convert([D].[CreateDate]))+1=Convert(Convert([Cur].[Week]))-datepart(weekday, Convert([Cur].[Week]))+1))

            |--Sort(ORDER BY:([D].[SubUnit] ASC))

            |    |--Hash Match(Inner Join, HASH:([SART].[ID])=([D].[SubArticle]))

            |         |--Nested Loops(Inner Join, OUTER REFERENCES:([GV_SCL].[FuncID]))

            |         |    |--Clustered Index Scan(OBJECT:(GETVAL AS [GV_SCL]))

            |         |    |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1012], [Expr1013], [Expr1014]))

            |         |         |--Compute Scalar(DEFINE:([Expr1012]=Convert([GV_SCL].[FuncID])-1, [Expr1013]=Convert([GV_SCL].[FuncID])+1, [Expr1014]=If (Convert([GV_SCL].[FuncID])-1=NULL) then 0 else 6|If (Convert([GV_SCL].[FuncID])+1=NULL) then 0 else 1

            |         |         |    |--Constant Scan

            |         |         |--Clustered Index Seek(OBJECT:([FPTest].[dbo].[SUBARTICLES].[PK_SUBARTICLES] AS [SART]), SEEK:([SART].[ID] > [Expr1012] AND [SART].[ID] < [Expr1013]),  WHERE:((((Convert([SART].[ID])=[GV_SCL].[FuncID] AND [SART].[TypeBuch]<

            |         |--Clustered Index Scan(OBJECT:([FPTest].[dbo].[DOCUMENTS].[PK_DOCUMENTS] AS [D]), WHERE:((([D].[TypeDoc]=1 AND [D].[CreateDate]>='янв  3 2005 12:00AM') AND [D].[CreateDate]<='фев  6 2005 12:00AM') AND Convert([D].[Debit])=1))

            |--Clustered Index Seek(OBJECT:([FPTest].[dbo].[Currency].[PK_Currency] AS [Cur]), SEEK:([Cur].[Week] >= 'янв  3 2005 12:00AM' AND [Cur].[Week] <= 'фев  6 2005 12:00AM') ORDERED FORWARD)
Вот текст запроса. Но не спрашивайте почему он так написан - не я его писал. Проблема в том что на разных серверах разные планы.
SELECT	*
FROM	SUBARTICLES SART		WITH (NOLOCK) 
	INNER JOIN  GETVAL(4,4199,14) GV_SCL		ON sart.ID	= GV_SCL.FUNCID 
	INNER JOIN DOCUMENTS D		WITH (NOLOCK)	ON SART.ID	=D.SUBARTICLE
	INNER JOIN SUBUNITS SU		WITH (NOLOCK)	ON SU.ID	=D.SUBUNIT  
	LEFT OUTER JOIN Currency  Cur	WITH (NOLOCK)	ON (d.Valuta	= Cur.Valuta
							AND (CAST(CAST(d.CreateDate AS float) AS int)-DATEPART(dw, d.CreateDate) + 1)
							=(CAST(CAST(Cur.week AS float) AS int)-DATEPART(dw, Cur.week) + 1)) 
WHERE	(d.CreateDate >= '20050103 00:00:00:000')
	AND (d.CreateDate <= '20050206 00:00:00:000')
	AND (Cur.week  >= '20050103 00:00:00:000' )
	AND (Cur.week <= '20050206 00:00:00:000' )
	AND (d.TypeDoc = 1)
	AND (d.Debit=1)
	AND (sart.TYPEBUCH <> 'AKT')
	AND (sart.TYPE not in ('SPRAV', 'NOBDG'))
	AND (sart.Commerc=0)
	AND (su.Project in (select id from dbo.fn_StrToTable( '0', ','))
		OR su.id in (select id from dbo.fn_StrToTable( '0', ','))
		OR 0=0)
31 авг 05, 10:31    [1831405]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
А, типа, железо одинаковое?
31 авг 05, 10:46    [1831484]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
Cancer3
Member

Откуда:
Сообщений: 63
tpg
А, типа, железо одинаковое?

Железо сильно отличается. На сервере разработчиков железо намного слабее, но и пользователей почти нет - там работает быстрее. На продакшн-сервере железо в несколько раз мощнее, но есть много пользователей - там медленнее выполняется запрос.
Если явно указать индекс в запросе на продакшн-сервере, то есть существенное увеличение производительности. Сам сервер не считает нужным его использовать, хотя на сервере разработки сервер использует этот индекс.
31 авг 05, 12:17    [1832027]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Наверное все же данные разные и/или статистика не продакшене не обновлена...
31 авг 05, 12:23    [1832056]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
MCMXCVIII
Member

Откуда:
Сообщений: 130
А какой запрос быстрее ? С первым планом или со вторым ?
31 авг 05, 12:24    [1832070]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
MCMXCVIII
Member

Откуда:
Сообщений: 130
AND (su.Project in (select id from dbo.fn_StrToTable( '0', ','))
OR su.id in (select id from dbo.fn_StrToTable( '0', ','))
OR 0=0)

Скажи, у кого сила, брат.
31 авг 05, 12:40    [1832179]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
Berg
Member

Откуда: Кр-ск
Сообщений: 3480
MCMXCVIII
AND (su.Project in (select id from dbo.fn_StrToTable( '0', ','))
OR su.id in (select id from dbo.fn_StrToTable( '0', ','))
OR 0=0)

Скажи, у кого сила, брат.


Просто запрос наверняка сформирован каким-либо генератором, а не "ручной"
31 авг 05, 13:13    [1832378]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
vzolotoy
Member

Откуда: Moscow
Сообщений: 27
Можно попробовать посмотреть состав статистик на таблицах на двух серверах и почитать статью Использование статистики оптимизатором запросов Microsoft SQL Server 2005.
Она к Server 2005 написана, но многое из нее есть и в 2000.
Скорее всего у Вас состав статистик на поля разный, версии SQL Server совпадают?
31 авг 05, 13:28    [1832473]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
Cancer3
Member

Откуда:
Сообщений: 63
Berg
MCMXCVIII
AND (su.Project in (select id from dbo.fn_StrToTable( '0', ','))
OR su.id in (select id from dbo.fn_StrToTable( '0', ','))
OR 0=0)

Скажи, у кого сила, брат.


Просто запрос наверняка сформирован каким-либо генератором, а не "ручной"

Да конечно в ЕМ сгенерирован. Я видел этот 0=0, но текст запроса одинаков на обоих серверах. Версии серверов разные: Developer и Enterprise соответственно. Статистику обновляли и индексы перестраивали, данные одинаковые.
31 авг 05, 14:17    [1832722]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
MCMXCVIII
Member

Откуда:
Сообщений: 130
Какой запрос быстрее ? С первым планом или со вторым ?
31 авг 05, 14:20    [1832736]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
Cancer3
Member

Откуда:
Сообщений: 63
MCMXCVIII
А какой запрос быстрее ? С первым планом или со вторым ?

Первый быстрее.
Видимо из-за фильтра, который фильтрует данные вначале.
31 авг 05, 14:26    [1832772]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
Breakneck
Member

Откуда: Kiev
Сообщений: 2454
Cancer3
Первый быстрее.
Видимо из-за фильтра, который фильтрует данные вначале.

Скорее из-за отсутствия Sort(ORDER BY:([D].[SubUnit] ASC)) в первом.
Попробуйте очистить кэш + реиндексацию и обновление статистики провести.
31 авг 05, 14:32    [1832809]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
MCMXCVIII
Member

Откуда:
Сообщений: 130
Если первый быстрее, то все очень просто. Надо "придушить" оптимизатор.
Ставишь после запроса
option (loop join)
31 авг 05, 14:43    [1832881]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
Cancer3
Member

Откуда:
Сообщений: 63
MCMXCVIII
Если первый быстрее, то все очень просто. Надо "придушить" оптимизатор.
Ставишь после запроса
option (loop join)

Спасибо, может воспользуемся советом. Но это не сильно отличается от явного указания индекса. Ведь со временем может измениться статистика, индексы и другие факторы влияющие на оптимизацию. И тогда, возможно, сервер сделает правильную оптимизацию. А так мы напишем чтоб он не делал оптимизацию и забудем. Это не очень хорошо, согласитесь.
31 авг 05, 15:14    [1833044]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
MCMXCVIII
Member

Откуда:
Сообщений: 130
Cancer3
MCMXCVIII
Если первый быстрее, то все очень просто. Надо "придушить" оптимизатор.
Ставишь после запроса
option (loop join)

Спасибо, может воспользуемся советом. Но это не сильно отличается от явного указания индекса. Ведь со временем может измениться статистика, индексы и другие факторы влияющие на оптимизацию. И тогда, возможно, сервер сделает правильную оптимизацию. А так мы напишем чтоб он не делал оптимизацию и забудем. Это не очень хорошо, согласитесь.


Не соглашусь. :)
Мы не запрещаем оптимизатору менять индексы и порядок соединения таблиц. В предложенном запросе оптимизатор исходя из статистики Currency джойнит раньше DOCUMENTS и SUBUNITS, и loop join никак в это не вмешивается.
Мы просто отрубаем Merge и Hash которые для данного запроса неэффективны.
31 авг 05, 15:31    [1833117]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
Cancer3
Member

Откуда:
Сообщений: 63
MCMXCVIII
Cancer3
MCMXCVIII
Если первый быстрее, то все очень просто. Надо "придушить" оптимизатор.
Ставишь после запроса
option (loop join)

Спасибо, может воспользуемся советом. Но это не сильно отличается от явного указания индекса. Ведь со временем может измениться статистика, индексы и другие факторы влияющие на оптимизацию. И тогда, возможно, сервер сделает правильную оптимизацию. А так мы напишем чтоб он не делал оптимизацию и забудем. Это не очень хорошо, согласитесь.


Не соглашусь. :)
Мы не запрещаем оптимизатору менять индексы и порядок соединения таблиц. В предложенном запросе оптимизатор исходя из статистики Currency джойнит раньше DOCUMENTS и SUBUNITS, и loop join никак в это не вмешивается.
Мы просто отрубаем Merge и Hash которые для данного запроса неэффективны.

Можно подробней. Я не совсем понял.
31 авг 05, 15:50    [1833208]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
MCMXCVIII
Member

Откуда:
Сообщений: 130
option (loop join) запрещает оптимизатору использовать hash и merge join. Причина торможения именно в них. Оптимизатор при анализе запросов в котором используется более 4-х таблиц, оценивает эффективность использования индексов пессимистично, а соответсвенно пытается использовать hash join.
Данная опция (loop join) никак не влияет на оптимизатор при выборе порядка джоина таблиц, и выбор индексов.
31 авг 05, 16:36    [1833502]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
marg
Member

Откуда:
Сообщений: 6
Спасибо за совет, но не помогло, стало работать еще медленнее (куда еще!) Давайте зайдем с другой стороны - почему этот так называемый оптимизатор ставит явно указанный индекс в середине плана, почему не в начале? Причем оптимизатор на серере разработчиков, где запрос работает быстро, ставит этот индекс в самом начале. Явно указан только индекс. Казалось бы...:(
1 сен 05, 12:51    [1836280]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
MCMXCVIII
Member

Откуда:
Сообщений: 130
marg
Спасибо за совет, но не помогло,

А план какой получился ?
marg
стало работать еще медленнее (куда еще!) Давайте зайдем с другой стороны - почему этот так называемый оптимизатор ставит явно указанный индекс в середине плана, почему не в начале? Причем оптимизатор на серере разработчиков, где запрос работает быстро, ставит этот индекс в самом начале. Явно указан только индекс. Казалось бы...:(


Индекс здесь не при чем, он в своей строке стоит, в той же что и таблица. А вот порядок джоина таблиц определяет оптимизатор. Так как таблиц больше четырех имеет смысл ему "подсказать", поставить Currency перед DOCUMENTS, SUBUNITS. Если ему исходя из статистики такой вариант не понравится, он его отвергнет. Проблема в том, что у оптимизатора 5! = 120 вариантов различных порядков джоина для 5-ти таблиц, но он лимитирован в своих раздумьях по времени. Он просто не успевает найти хороший план.
1 сен 05, 16:05    [1837469]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
marg
Member

Откуда:
Сообщений: 6
План получился другой, но т.к. не помогло, я его не выкладываю. Но могу выложить, если тебе интересно.
Насчет джойна таблиц - так да! вроде подсказываю ему - ставлю первой таблицей как раз документы (от них основная выборка идет), а он берет третью в списке джойнов. Мне думалось что он будет брать таблицы в порядке их указания в джойнах. А он не хотит.
Вопрос: может быть статистика глючная из-за того, что индексы несколько раз удалялись создавались модифицировались? Может дело в этом - странички памяти, где индексы хранятся, надо привести в порялок? (Update statistic ничего не дало).
2 сен 05, 18:38    [1842609]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
marg
Member

Откуда:
Сообщений: 6
И еще вопрос. Сделали явно указанные индексы в запросе. На одну таблицу - 2, на вторую - один. При одновременном запуске этого запроса (4 аналайзера) сервер мощно подвис и возникли блокировки. Не замочки, но жесткие - отпустило минуты через 3. Когда оставили один только хинт-индекс, блокировок больше не возникало. Это как, нормально вообще? А если оно на один хинт такие блокировки создаст когда вся толпа начнет с этой выборкой работать? Стремно как-то...Что думаешь по этому поводу?
2 сен 05, 18:49    [1842640]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
Glory
Member

Откуда:
Сообщений: 104760
При одновременном запуске этого запроса (4 аналайзера) сервер мощно подвис и возникли блокировки.
Ну так значит ваши хинты задают не лучший план выполнения.

Не замочки, но жесткие - отпустило минуты через 3. Когда оставили один только хинт-индекс, блокировок больше не возникало. Это как, нормально вообще? А если оно на один хинт такие блокировки создаст когда вся толпа начнет с этой выборкой работать? Стремно как-то...Что думаешь по этому поводу?
Блокировки сервер накладывает всегда. А от плана выполнения зависит какие именно. Используя хинты, т.е принуждая сервер использовать ваш план, вы должны думать и о возможных блокировках
Есди вы не представляете себе четко что есть что в плане выполнения и почему оно там берется, то не надо сразу использовать хинты.
2 сен 05, 18:56    [1842656]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
MCMXCVIII
Member

Откуда:
Сообщений: 130
marg
Мне думалось что он будет брать таблицы в порядке их указания в джойнах. А он не хотит.


Не может - научим.
Не хочет - заставим !
option ( FORCE ORDER )
5 сен 05, 09:58    [1845177]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
marg
Member

Откуда:
Сообщений: 6
Glory: "Есди вы не представляете себе четко что есть что в плане выполнения " - с этого все и началось - на разных серверах разные планы выполнения. И индексы берутся по разному. А что есть что в плане выполнения, я себе представляю :)
MCMXCVIII: спасибо, будем долбить дальше
5 сен 05, 13:57    [1846641]     Ответить | Цитировать Сообщить модератору
 Re: Разные планы на разных серверах?  [new]
marg
Member

Откуда:
Сообщений: 6
MCMXCVIII: О, так ведь этот Force похоже то что надо! А его нужно писать один раз в конце всего запроса, так?
5 сен 05, 15:11    [1847075]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить