Я читав кілька чудових статей щодо кешування планів SQL Server від Kimberly Tripp, таких як ця: http://www.sqlskills.com/blogs/kimberly/plan-cache-and-optimizing-for-adhoc-workloads/
Чому існує навіть можливість "оптимізувати для спеціальних навантажень"? Чи не повинно це бути завжди? Незалежно від того, розробники використовують спеціальний SQL чи ні, чому б вам не було ввімкнено цю опцію для кожного екземпляра, який підтримує її (SQL 2008+), тим самим зменшуючи розширення кешу?
Відповіді:
Команда розробок SQL Server працює за принципом найменшого здивування - тому SQL Server, як правило, має нові функції, відключені в інтересах збереження поведінки як попередніх версій.
Так, оптимізація для навантажень adhoc чудово знижує кількість кешу плану, але завжди слід протестувати це спочатку!
[Редагувати: Кален Делані розповідає цікавий анекдот, що вона запитала одного зі своїх друзів-інженерів Майкрософт, чи не виникнуть обставини, коли це було б недоцільно увімкнути. Він повертається через кілька днів, щоб сказати - уявіть програму, яка має багато різних запитів, і кожен запит працює рівно два рази. Тоді це може бути недоречно. Досить сказати, що не так багато додатків!]
[Редагувати: якщо більшість ваших запитів виконуються більше одного разу (не точно два рази); це, ймовірно, буде недоречно. Загальним правилом було б перетворити його, якщо в базі даних є багато одноразових запитів adhoc; однак таких програм все ще не так багато.]
Нижче наведено невеликий код, який допоможе вам вирішити, корисним буде чи ні " оптимізація перемикання для тимчасових робочих навантажень ON / OFF". Ми зазвичай перевіряємо це як частину нашої перевірки стану здоров’я на внутрішніх та клієнтських серверах.
Це найбезпечніший варіант для включення і добре описується Бредом тут і Гленн Беррі тут .
--- for 2008 and up .. Optimize ad-hoc for workload
IF EXISTS (
-- this is for 2008 and up
SELECT 1
FROM sys.configurations
WHERE NAME = 'optimize for ad hoc workloads'
)
BEGIN
DECLARE @AdHocSizeInMB DECIMAL(14, 2)
,@TotalSizeInMB DECIMAL(14, 2)
,@ObjType NVARCHAR(34)
SELECT @AdHocSizeInMB = SUM(CAST((
CASE
WHEN usecounts = 1
AND LOWER(objtype) = 'adhoc'
THEN size_in_bytes
ELSE 0
END
) AS DECIMAL(14, 2))) / 1048576
,@TotalSizeInMB = SUM(CAST(size_in_bytes AS DECIMAL(14, 2))) / 1048576
FROM sys.dm_exec_cached_plans
SELECT 'SQL Server Configuration' AS GROUP_TYPE
,' Total cache plan size (MB): ' + cast(@TotalSizeInMB AS VARCHAR(max)) + '. Current memory occupied by adhoc plans only used once (MB):' + cast(@AdHocSizeInMB AS VARCHAR(max)) + '. Percentage of total cache plan occupied by adhoc plans only used once :' + cast(CAST((@AdHocSizeInMB / @TotalSizeInMB) * 100 AS DECIMAL(14, 2)) AS VARCHAR(max)) + '%' + ' ' AS COMMENTS
,' ' + CASE
WHEN @AdHocSizeInMB > 200
OR ((@AdHocSizeInMB / @TotalSizeInMB) * 100) > 25 -- 200MB or > 25%
THEN 'Switch on Optimize for ad hoc workloads as it will make a significant difference. Ref: http://sqlserverperformance.idera.com/memory/optimize-ad-hoc-workloads-option-sql-server-2008/. http://www.sqlskills.com/blogs/kimberly/post/procedure-cache-and-optimizing-for-adhoc-workloads.aspx'
ELSE 'Setting Optimize for ad hoc workloads will make little difference !!'
END + ' ' AS RECOMMENDATIONS
ENDПодумайте про виробничий сервер, який обслуговує лише 5 різних запитів, але кілька тисяч таких в секунду. Ви команда розробників Microsoft SQL Server. Ви збираєтесь поспішати з кешуванням плану. Чи включаєте ви цю поведінку за замовчуванням, коли знаєте, що деякі з ваших найбільших і найважливіших клієнтів (наприклад, внутрішня реалізація Microsoft SAP) працюють у тому ж кампусі та використовують ту саму кафетерію, яку ви робите?
Якщо ввімкнути опцію " Оптимізація спеціальних робочих навантажень ", ви спричините, що спеціальні запити, які виконуються вдруге, будуть такими ж повільними, як і 1-й, оскільки ви будете складати план виконання та витягувати ті самі дані ( без кешування) ті перші 2 рази.
Це може не бути великою справою, але ви помітите це під час тестування запитів.
То що ж відбувається зараз, не ввімкнувши цю опцію та кеш, наповнений одноразовими спеціальними запитами?
Після введення цієї функції оптимізації алгоритм кешування кешування також був оновлений.
У статті Кімберлі Тріпп також згадується публікація Калена Делані про зміну цього алгоритму.
Вона це найкраще пояснює:
Зміна фактично обчислює розмір кешу плану, при якому SQL Server визнає, що є тиск у пам'яті, і він почне видаляти плани з кешу. Плани, які слід зняти, - це дешеві плани, які не використовувались повторно, і це ДОБРО.
Це означає, що ті примхливі одноразові плани будуть першими, коли потрібно звільнити ресурси.
" Чому ми потребуємо" оптимізації робочих навантажень ", коли SQL Server піклується про видалення невикористаних планів, коли це необхідно? "
Моєю відповіддю є те, що якщо ви регулярно маєте s-тонну динамічного квадратного генерування ювелів не параметризованих оголошень -hoc запити, то має сенс увімкнути цю функцію.
Ви хочете уникнути навантаження на системні ресурси, щоб змусити видалити кешований план / дані після того, як ви використали максимальний простір кеш-пам'яті.
Ось запит, який я написав, щоб показати вам, скільки спеціальних планів ви зараз кешували та скільки місця на диску вони з'їдають (результати змінюватимуться протягом дня - тому протестуйте це під час великого навантаження):
--Great query for making the argument to use "Optimize for Ad Hoc Workloads":
SELECT S.CacheType, S.Avg_Use, S.Avg_Multi_Use,
S.Total_Plan_3orMore_Use, S.Total_Plan_2_Use, S.Total_Plan_1_Use, S.Total_Plan,
CAST( (S.Total_Plan_1_Use * 1.0 / S.Total_Plan) as Decimal(18,2) )[Pct_Plan_1_Use],
S.Total_MB_1_Use, S.Total_MB,
CAST( (S.Total_MB_1_Use * 1.0 / S.Total_MB ) as Decimal(18,2) )[Pct_MB_1_Use]
FROM
(
SELECT CP.objtype[CacheType],
COUNT(*)[Total_Plan],
SUM(CASE WHEN CP.usecounts > 2 THEN 1 ELSE 0 END)[Total_Plan_3orMore_Use],
SUM(CASE WHEN CP.usecounts = 2 THEN 1 ELSE 0 END)[Total_Plan_2_Use],
SUM(CASE WHEN CP.usecounts = 1 THEN 1 ELSE 0 END)[Total_Plan_1_Use],
CAST((SUM(CP.size_in_bytes * 1.0) / 1024 / 1024) as Decimal(12,2) )[Total_MB],
CAST((SUM(CASE WHEN CP.usecounts = 1 THEN (CP.size_in_bytes * 1.0) ELSE 0 END)
/ 1024 / 1024) as Decimal(18,2) )[Total_MB_1_Use],
CAST(AVG(CP.usecounts * 1.0) as Decimal(12,2))[Avg_Use],
CAST(AVG(CASE WHEN CP.usecounts > 1 THEN (CP.usecounts * 1.0)
ELSE NULL END) as Decimal(12,2))[Avg_Multi_Use]
FROM sys.dm_exec_cached_plans as CP
GROUP BY CP.objtype
) AS S
ORDER BY S.CacheTypeРезультати:
Я не збираюся говорити: " Коли у вас є X MB " або " Якщо X% вашої рекламної програми є одноразовою ", щоб увімкнути це.
Це не впливає на Sprocs, тригери, перегляди або параметризований / підготовлений SQL - лише спеціальні запити.
Моя особиста рекомендація - просто увімкнути вашу програму Prod Environment, але подумайте про те, щоб залишити її у вашому середовищі Dev.
Я говорю це лише для Dev, тому що якщо ви оптимізуєте запит, який потребує хвилини або більше, то ви не хочете запускати його 3 рази, перш ніж ви зможете побачити, наскільки швидко він піде з кешованим керуванням - кожен одноразово редагуючи його, щоб знайти найкращий дизайн оптимізації.
Якщо ваша робота не передбачає цього робити цілий день, то згорбіть і попросіть DBA включити її скрізь.
"Чому я НЕ повинен використовувати ...." У ході деяких розслідувань ефективності витягнення планів із кешу плану майже в реальному часі, а спостереження за використанням ресурсів може бути дуже корисним. "Оптимізація для навантажень adhoc" це може порушити, оскільки плани заглушки adhoc не повертають план при запиті кешу. У такому випадку, якщо запит і план не можна ідентифікувати, налаштування можна буде вимкнути і знову ввімкнути для дослідження. Зауважте, що зміна запитів щодо встановлення ефектів, складених з цього моменту вперед. Крім того, щоразу, змінюючи властивість "сервера", перевірте невластивий екземпляр у тій самій версії, щоб перевірити, чи зміна буде змивати кеш плану. Я особисто не люблю дивуватися цим. (Наприклад, зміна maxdop на рівні сервера, як правило, стирає кеш плану,
"У скомпільованому заглушці плану немає пов'язаного з ним плану виконання, і запит на ручку плану не поверне XML Showplan." http://technet.microsoft.com/en-us/library/cc645587.aspx