Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Почему 2000 хуже 7  [new]
cbm
Guest
Поставили SQL Server 2000 вместо семерки.
В результате запрос, выполнявшийся за секунды, стал выполняться за минуты.
Как я понимаю, оптимизатор 2000 не понял того, о чем мы неплохо столковались с семеркой.

К сожалению план запроса из семерки получить уже негде, а в 2000 имею следующее:

set showplan_text on
go
update temprec1 Set city=isNull((SELECT TOP 1 PrefDB.City
frOM PrefDB WHERE temprec1.b_full_num LIKE RTRIM(PrefDB.Pref) + '%' ORDER BY PrefDB.Pref DESC),'')

, AType = ISNULL((SELECT TOP 1 PrefDB.CallType
FROM PrefDB WHERE Temprec1.a_sub_num LIKE RTRIM(PrefDB.Pref) + '%' ORDER BY PrefDB.Pref DESC), '')

, AMType = ISNULL((SELECT TOP 1 PrefDB.CallType
FROM PrefDB WHERE Temprec1.a_sub_mob LIKE RTRIM(PrefDB.Pref) + '%' ORDER BY PrefDB.Pref DESC), '')

, BType = ISNULL((SELECT TOP 1 PrefDB.CallType
FROM PrefDB WHERE Temprec1.b_full_num LIKE RTRIM(PrefDB.Pref) + '%' ORDER BY PrefDB.Pref DESC), '')
, BMType = ISNULL((SELECT TOP 1 PrefDB.CallType
FROM PrefDB WHERE Temprec1.b_sub_mob LIKE RTRIM(PrefDB.Pref) + '%' ORDER BY PrefDB.Pref DESC), '')
where (Temprec1.mustwrk=1)
go
set showplan_text off
go


|--Clustered Index Update(OBJECT:([Billing].[dbo].[temprec1].[PK_temprec1_1]), SET:([temprec1].[City]=RaiseIfNull([Expr1008]), [temprec1].[BMType]=RaiseIfNull([Expr1028]), [temprec1].[BType]=RaiseIfNull([Expr1023]), [temprec1].[AMType]=RaiseIfNull([Expr1
|--Compute Scalar(DEFINE:([Expr1008]=isnull([PrefDB].[City], ' '), [Expr1013]=isnull([PrefDB].[CallType], ' '), [Expr1018]=isnull([PrefDB].[CallType], ' '), [Expr1023]=isnull([PrefDB].[CallType], ' '), [Expr1028]=isnull
|--Nested Loops(Left Outer Join, OUTER REFERENCES:([temprec1].[b_sub_mob]))
|--Nested Loops(Left Outer Join, OUTER REFERENCES:([temprec1].[b_full_num]))
| |--Nested Loops(Left Outer Join, OUTER REFERENCES:([temprec1].[a_sub_mob]))
| | |--Nested Loops(Left Outer Join, OUTER REFERENCES:([temprec1].[a_sub_num]))
| | | |--Nested Loops(Left Outer Join, OUTER REFERENCES:([temprec1].[b_full_num]))
| | | | |--Top(ROWCOUNT est 0)
| | | | | |--Clustered Index Scan(OBJECT:([Billing].[dbo].[temprec1].[PK_temprec1_1]), WHERE:([temprec1].[MustWrk]=1) ORDERED)
| | | | |--Hash Match(Cache, HASH:([temprec1].[b_full_num]), RESIDUAL:([temprec1].[b_full_num]=[temprec1].[b_full_num]))
| | | | |--Compute Scalar(DEFINE:([PrefDB].[City]=[PrefDB].[City]))
| | | | |--Top(1)
| | | | |--Filter(WHERE:(like([temprec1].[b_full_num], rtrim(Convert([PrefDB].[Pref]))+'%', NULL)))
| | | | |--Bookmark Lookup(BOOKMARK:([Bmk1004]), OBJECT:([Billing].[dbo].[PrefDB]))
| | | | |--Index Scan(OBJECT:([Billing].[dbo].[PrefDB].[PK_PrefDB]), ORDERED BACKWARD)
| | | |--Hash Match(Cache, HASH:([temprec1].[a_sub_num]), RESIDUAL:([temprec1].[a_sub_num]=[temprec1].[a_sub_num]))
| | | |--Compute Scalar(DEFINE:([PrefDB].[CallType]=[PrefDB].[CallType]))
| | | |--Top(1)
| | | |--Filter(WHERE:(like([temprec1].[a_sub_num], rtrim(Convert([PrefDB].[Pref]))+'%', NULL)))
| | | |--Bookmark Lookup(BOOKMARK:([Bmk1009]), OBJECT:([Billing].[dbo].[PrefDB]))
| | | |--Index Scan(OBJECT:([Billing].[dbo].[PrefDB].[PK_PrefDB]), ORDERED BACKWARD)
| | |--Hash Match(Cache, HASH:([temprec1].[a_sub_mob]), RESIDUAL:([temprec1].[a_sub_mob]=[temprec1].[a_sub_mob]))
| | |--Compute Scalar(DEFINE:([PrefDB].[CallType]=[PrefDB].[CallType]))
| | |--Top(1)
| | |--Filter(WHERE:(like([temprec1].[a_sub_mob], rtrim(Convert([PrefDB].[Pref]))+'%', NULL)))
| | |--Bookmark Lookup(BOOKMARK:([Bmk1014]), OBJECT:([Billing].[dbo].[PrefDB]))
| | |--Index Scan(OBJECT:([Billing].[dbo].[PrefDB].[PK_PrefDB]), ORDERED BACKWARD)
| |--Hash Match(Cache, HASH:([temprec1].[b_full_num]), RESIDUAL:([temprec1].[b_full_num]=[temprec1].[b_full_num]))
| |--Compute Scalar(DEFINE:([PrefDB].[CallType]=[PrefDB].[CallType]))
| |--Top(1)
| |--Filter(WHERE:(like([temprec1].[b_full_num], rtrim(Convert([PrefDB].[Pref]))+'%', NULL)))
| |--Bookmark Lookup(BOOKMARK:([Bmk1019]), OBJECT:([Billing].[dbo].[PrefDB]))
| |--Index Scan(OBJECT:([Billing].[dbo].[PrefDB].[PK_PrefDB]), ORDERED BACKWARD)
|--Hash Match(Cache, HASH:([temprec1].[b_sub_mob]), RESIDUAL:([temprec1].[b_sub_mob]=[temprec1].[b_sub_mob]))
|--Compute Scalar(DEFINE:([PrefDB].[CallType]=[PrefDB].[CallType]))
|--Top(1)
|--Filter(WHERE:(like([temprec1].[b_sub_mob], rtrim(Convert([PrefDB].[Pref]))+'%', NULL)))
|--Bookmark Lookup(BOOKMARK:([Bmk1024]), OBJECT:([Billing].[dbo].[PrefDB]))
|--Index Scan(OBJECT:([Billing].[dbo].[PrefDB].[PK_PrefDB]), ORDERED BACKWARD)

Может кто подскажет, что здесь плохо?
16 сен 03, 09:37    [339954]     Ответить | Цитировать Сообщить модератору
 Re: Почему 2000 хуже 7  [new]
Flare
Member

Откуда:
Сообщений: 711
Это запрос? %)
Ещё пару страниц кода не хватает для полного осознания общей картины. ;)

А если честно, то по частям не пробовали как оно работает? И где возникает задержка. Видимо лень, понимаю.

А так вряд ли скажешь, без базы, типов и объема данных. Издеваетесь, что ли?
16 сен 03, 09:46    [339975]     Ответить | Цитировать Сообщить модератору
 Re: Почему 2000 хуже 7  [new]
свм
Guest
Извиняюсь за издеватльство, не хотел.
Пораздельно пробовал, приблизительно то же самое.

Упрощенный план привожу.

StmtText
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
update temprec1 Set city=isNull((SELECT TOP 1 PrefDB.City
frOM PrefDB WHERE temprec1.b_full_num LIKE RTRIM(PrefDB.Pref) + '%' ORDER BY PrefDB.Pref DESC),'')

(1 row(s) affected)

StmtText
----------------------------------------------------------------------------------------------------------------------------------
|--Clustered Index Update(OBJECT:([Billing].[dbo].[temprec1].[PK_temprec1_1]), SET:([temprec1].[City]=RaiseIfNull([Expr1008])))
|--Compute Scalar(DEFINE:([Expr1008]=isnull([PrefDB].[City], ' ')))
|--Nested Loops(Left Outer Join, OUTER REFERENCES:([temprec1].[b_full_num]))
|--Top(ROWCOUNT est 0)
| |--Clustered Index Scan(OBJECT:([Billing].[dbo].[temprec1].[PK_temprec1_1]))
|--Hash Match(Cache, HASH:([temprec1].[b_full_num]), RESIDUAL:([temprec1].[b_full_num]=[temprec1].[b_full_num]))
|--Compute Scalar(DEFINE:([PrefDB].[City]=[PrefDB].[City]))
|--Top(1)
|--Filter(WHERE:(like([temprec1].[b_full_num], rtrim(Convert([PrefDB].[Pref]))+'%', NULL)))
|--Bookmark Lookup(BOOKMARK:([Bmk1004]), OBJECT:([Billing].[dbo].[PrefDB]))
|--Index Scan(OBJECT:([Billing].[dbo].[PrefDB].[PK_PrefDB]), ORDERED BACKWARD)

Какая информация о базе может пригодиться?

В запросе используются 2 таблицы с первичными ключами.
PrefDB - ключ по полю участвующему в запросе,
TempRec1 - нет
16 сен 03, 09:59    [339998]     Ответить | Цитировать Сообщить модератору
 Re: Почему 2000 хуже 7  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
А если попробовать перестроить индесы и обновить статистику?
16 сен 03, 10:18    [340043]     Ответить | Цитировать Сообщить модератору
 Re: Почему 2000 хуже 7  [new]
AlTk
Member

Откуда: Волгоград
Сообщений: 124
такая же фигня.
устанавливаем новый сервер (железо), новый сиквел (2000), закачиваем БД, выполняем приложение - 10 минут выполняется запрос. своим ощущениям не верим, удаляем 2000, устанавливаем сиквел 7.0 -максимальный срок выполнения составил 1,5 секунды!!!
лечилось переписыванием запросов и расстановкой хинтов.
странно оптимизатор у 2000 работает.
даже проводили тест - делали БД из 4 таблиц и выполняли запрос.
в 7.0 все нормально, смотрим на план запроса там, к примеру, hash join - объем данных 50000 строк, берем базу один в один заливаем на 2000, выполняем обновление статистики, индексов и т.д. смотрим в план - там merge join - объем данных 15000000 строк. вот такая фигня.
очень мы расстроились по этому поводу.

ПС. если раньше разработчики писали просто на T-SQL, то теперь на T-SQL для 2000.

ППС. первый раз с этим столкнулись, хотя работаем с сиквелом еще с версии 6.0
16 сен 03, 10:24    [340054]     Ответить | Цитировать Сообщить модератору
 Re: Почему 2000 хуже 7  [new]
свм
Guest
To tpg
Спасибо, стало лучше, хотя уровня семерки не достиг.
Придется править запрос.
16 сен 03, 10:31    [340071]     Ответить | Цитировать Сообщить модератору
 Re: Почему 2000 хуже 7  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Версия сервера?
select @@vesrion

Уровень совместимости базы?
Филлфакторы индексов?
Опции базы?
Реиндекс после перехода делали?
Переподнятие объектов или хотя бы перекомпиляцию делали?
Индекс тюн визард что показываеть по этой ситуации?
16 сен 03, 10:44    [340107]     Ответить | Цитировать Сообщить модератору
 Re: Почему 2000 хуже 7  [new]
Glory
Member

Откуда:
Сообщений: 104760
Какой план будет у такого запроса ?

update temprec1 Set city=isNull((SELECT TOP 1 PrefDB.City 

frOM PrefDB WHERE PrefDB.Pref = LEFT(temprec1.b_full_num, LEN(RTRIM(PrefDB.Pref)) ORDER BY PrefDB.Pref DESC),'')


ЗЫ
Чем кстати вызвано наличие функции RTRIM ??? Типом поля ?
16 сен 03, 10:50    [340134]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить