powered by simpleCommunicator - 2.0.52     © 2025 Programmizd 02
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Оценка стоимости плана при смене уровня совместимости
7 сообщений из 7, страница 1 из 1
Оценка стоимости плана при смене уровня совместимости
    #40009308
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Коллеги, добрый день. Давно перешли на версию mssql 2016 c 2008. Но до сих пор на части баз не поднят уровень совместимости из-за большого кол-ва кода, который при тестовом поднятии сразу начал тормозить.
Цель поднятия уровня совместимости - использование новых возможностей свежих версий mssql.

Вот исследую на примере одной хранимки, состоящей из одного запроса.
При уровне совместимости 100(2008) в запросе данные выбираются по существующему индексу: 2 поля в индексе и все остальные в include.
При переключении на уровень 130(2016) в плане уже скан таблицы. Пробовал включать LEGACY_CARDINALITY_ESTIMATION ON - это не влияет на запрос, все равно скан. Почему? Разве это не включение старой оценки?

После уже заметил, что в таблице появилось еще одно поле, которое не входит в include. Поэтому при явном указании индекса или уровне совместимости 100, помимо поиска по индексу еще идет поиск ключа, т.е. еще одна операция. Суммарная предполагаемая стоимость 2 операторов выше, чем одного скана. Но при этом скорость выполнения отличается в десятки раз: скан 5-7мин против поиска по индексу 4-5с.
Статистику по таблице обновлял.

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

Буду благодарен за наводку, куда копать.
---
Проходя мимо разложенных граблей, ты теряешь драгоценный опыт. (с)
...
Рейтинг: 0 / 0
Оценка стоимости плана при смене уровня совместимости
    #40009312
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Megabyte
Суммарная предполагаемая стоимость 2 операторов выше, чем одного скана. Но при этом скорость выполнения отличается в десятки раз: скан 5-7мин против поиска по индексу 4-5с.

ну так значит таблица здоровая (скан 5-7мин),
а запрос отбирает лишь небольшую часть строк(поиск по индексу 4-5с).
и вот "старая" оценка и предполагала небольшое число строк,
а по новой оценке выбирается слишком много.

не индекс хинтом надо прописывать, а свои условия нормально переписать.
наверняка туча OR.
актуальный план чего жмотите, стыдно?
...
Рейтинг: 0 / 0
Оценка стоимости плана при смене уровня совместимости
    #40009323
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yasha123
Megabyte
Суммарная предполагаемая стоимость 2 операторов выше, чем одного скана. Но при этом скорость выполнения отличается в десятки раз: скан 5-7мин против поиска по индексу 4-5с.

ну так значит таблица здоровая (скан 5-7мин),
а запрос отбирает лишь небольшую часть строк(поиск по индексу 4-5с).
и вот "старая" оценка и предполагала небольшое число строк,
а по новой оценке выбирается слишком много.

не индекс хинтом надо прописывать, а свои условия нормально переписать.
наверняка туча OR.
актуальный план чего жмотите, стыдно?

Не стыдно вообще, ибо не я автор, это раз. :) Но в любом случае запрос линейный, без единого OR. Так что догадка не верна.
Переписывать там особо нечего. Таблица здоровая, да. Но выборка по индексу быстрая.

Да вот собсно запрос:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
declare 
  @sd datetime = '20201001',
  @ed datetime = '20201001 23:59:59.997',
  @Task_ID int = '2101'
   

select [Интервал 15 мин] = left(sp.Caption1,5),
       [День] = cal.DT, 
	   [ДН] = cal.DAY_CAP,
       lcs.Session_id, 
       lcs.Questionniare_ID,
       [Номер в цепочке звонка] = lcs.Call_No,
       [Номер звонка в анкете]  = case when lcs.Questionniare_ID = 0 then 1 
                                       else ROW_NUMBER() OVER(PARTITION BY lcs.Questionniare_ID ORDER BY CREATED)
                                   end,
       Call_ID,
       Subscriber_ID,
       CallDate = lcs.CREATED, 
       IVRTime = lcs.IVRTime, 
       [QueueTime+Ringing] = lcs.QueueTime,
       [Источник] = cs.Name,
       [Статус Очереди] = qsl.QueueStatus,       
       [Статус выхода на оператора] = osl.OperStatus,
       [Oper_ID] = lcs.User_ID,
       [Площадка] = f.field_Name,
       [Login] = isnull(nullif(u.user_number, ''), u.old_user_number),
	   [Роль] = isnull(en.Name , ''),
       [OperName] = u.user_surname + CHAR(32) + u.user_firstname + CHAR(32) + u.user_secondname,
       RingingTime = lcs.RingTime ,	
       TalkTime	 = lcs.ConnTime - lcs.HoldTime,
       HoldTime	= lcs.HoldTime,       
       ACW = lcs.ACW, 
       HT = case when lcs.Input = 0 or DialStat = 2 then lcs.RingTime+lcs.ConnTime+lcs.ACW else 0 end,
       AON_TO,
       AON = 
				CASE
					WHEN AON LIKE 'UID%' THEN SUBSTRING(AON, CHARINDEX('#', AON)+1, LEN(AON))
					ELSE AON
				END,
       lcs.Queue_ID,
	   [Результат звонка] = cr.Caption,
       tr.TransferStatus,
       lcs.TransferTime,
       lcs.TransferNumber,
       [Инициатор разъединения] = ds.DInitiator,
	   [Комментарий] = isnull(lcs.Comment, '')+isnull(br.hangup, '')   

from report..LS lcs 
 
left join Report.dbo.Report_Templates_CallSources cs 
       on lcs.Source_ID = cs.ID
left join Report.dbo.Report_Templates_QueueStatusList qsl
       on qsl.QS_ID = lcs.QS_ID
left join Report.dbo.Report_Templates_OperStatusList osl 
       on osl.OS_ID = lcs.OS_ID
left join Report.dbo.Report_Templates_TransferStatus tr
       on tr.TransferStatus_ID = lcs.TransferStatus_ID
left join Report.dbo.Report_Templates_Disconnect_Initiator ds
       on ds.Disconnect_ID = lcs.Disconnect_ID
left join Control.dbo.AC_Project_Groups_Users_DT pgudt
  on pgudt.CL_ID = lcs.CL_ID
 and pgudt.user_id = lcs.User_ID
left join Control.dbo.UsersRoles_Entity en
  on en.UREn_ID = pgudt.UREn_ID

left join Control.dbo.AC_Calendar cal
  on cal.CL_ID = lcs.CL_ID
left join Control.dbo.Users u 
       on u.user_id = lcs.user_id
left join Control.dbo.AdminClient_field f 
       on f.field_ID = u.field_ID
left join Control.dbo.Aggregate15M_Spans sp
  on sp.SpanID = lcs.SpanID
outer apply
  (
   select top 1 Caption
   from CallCenter_new.dbo.Spr_CallResult 
   where Task_ID = lcs.Task_ID
     and Result_ID = lcs.Result_ID
	 and ED is null
  ) cr
 outer apply
  (
   select top 1 '| Нажималась кнопка Отбой' as hangup, nw.insert_date
   from Report.dbo.BreakDialByUserNew nw (nolock)
   where nw.Nausessionid = isnull(nullif(lcs.Session_id_linkto,''),lcs.Session_id)
     and nw.User_ID = lcs.User_ID
  ) br


where 1=1
 and lcs.Task_id = @Task_id
 and  lcs.CREATED between @sd and @ed 

order by lcs.CL_ID, lcs.session_id, lcs.LEG_ID



report..LS - большая таблица данных, к нему джойнятся различные мелкие справочники.
Spr_CallResult - тоже небольшой справочник.
Report.dbo.BreakDialByUserNew - таблица данных, но сильно меньше объемом, чем report..LS.

Ну разве что пару outer apply можно переписать. Но я не стал копаться, т.к. запрос работает приемлемое время.

p.s. Попытался сохранить xml-план в файл и прикрепить, получился файл большего размера(234кб), чем можно прикрепить(150кб).
...
Рейтинг: 0 / 0
Оценка стоимости плана при смене уровня совместимости
    #40009329
Фотография komrad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Megabyte

p.s. Попытался сохранить xml-план в файл и прикрепить, получился файл большего размера(234кб), чем можно прикрепить(150кб).

можно воспользоваться сервисом Paste The Plan
или просто заархивировать в zip
...
Рейтинг: 0 / 0
Оценка стоимости плана при смене уровня совместимости
    #40009331
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а чего молчали про параметры?
Код: sql
1.
and  lcs.CREATED between @sd and @ed 


это же процедура, а не запрос с переменными, как вы сейчас показываете.
а процедура как прослушала разок параметры, так и план вы получили соответствующий.
если в первый запуск интервал времени [@sd, @ed] был небольшой,
то в плане индекс и лукапы,
а если пардон весь период, какой только есть в таблице, то и будет скан.
и если теперь во второй раз пустить эту же сп с другими параметрами, то тормоза и будут.
припишите запросу в sp option(recompile) в самый конец, проверьте
...
Рейтинг: 0 / 0
Оценка стоимости плана при смене уровня совместимости
    #40009335
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Megabyte

При уровне совместимости 100(2008) в запросе данные выбираются по существующему индексу: 2 поля в индексе и все остальные в include.
При переключении на уровень 130(2016) в плане уже скан таблицы. Пробовал включать LEGACY_CARDINALITY_ESTIMATION ON - это не влияет на запрос, все равно скан. Почему?

после выполнения alter database .. set compatibility_level
все планы этой базы в кэше инвалидируются.
видимо после этого кто-то запустил сп с параметрами, где скан был выгоднее.
потом запустили вы, уже с параметрами, где выгоднее индекс и лукапы.

что делает с планами LEGACY_CARDINALITY_ESTIMATION ON надо проверять,
мне не приходилось использовать,
но даже если и это выносит все планы, видимо снова кто-то успел запустить сп с параметрами,
провоцирующими скан.

не можете прикрепить план, посмотрите для каких параметров он был скомпилирован
...
Рейтинг: 0 / 0
Оценка стоимости плана при смене уровня совместимости
    #40009416
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yasha123
а чего молчали про параметры?
Код: sql
1.
and  lcs.CREATED between @sd and @ed 


это же процедура, а не запрос с переменными, как вы сейчас показываете.
а процедура как прослушала разок параметры, так и план вы получили соответствующий.
если в первый запуск интервал времени [@sd, @ed] был небольшой,
то в плане индекс и лукапы,
а если пардон весь период, какой только есть в таблице, то и будет скан.
и если теперь во второй раз пустить эту же сп с другими параметрами, то тормоза и будут.
припишите запросу в sp option(recompile) в самый конец, проверьте

Да, изначально это хп. Выдал запрос, не подумал, что надо сказать про хранимку.
В таблице данные за несколько месяцев, а выборка за 1 день. Если бы выбирался почти весь период, то вопросов бы про скан не было. :)
Про "option(recompile)" - спасибо, попробую.
...
Рейтинг: 0 / 0
7 сообщений из 7, страница 1 из 1
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Оценка стоимости плана при смене уровня совместимости
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]