Продължение на Summer Performance Palooza 2013

На 27 юни PASS Performance Virtual Chapter проведе своето лятно изпълнение Palooza за 2013 г. – нещо като намален 24 часа PASS, но фокусиран единствено върху теми, свързани с представянето. Проведох сесия, озаглавена „10 лоши навика, които могат да убият производителността“, третирайки следните 10 концепции:

1. ИЗБЕРЕТЕ *
2. Слепи индекси
3. Без префикс на схема
4. Опции на курсора по подразбиране
5. sp_ префикс
6. Разрешаване на раздуване на кеша
7. Широки типове данни
8. По подразбиране на SQL сървъра
9. Прекомерна употреба на функции
10. „Работи на моята машина“

Може би си спомняте някои от тези теми от такива презентации като моята беседа „Лоши навици и най-добри практики“ или нашите седмични уебинари за настройка на заявки, които бях домакин с Кевин Клайн от началото на юни до тази седмица. (Тези 6 видеоклипа, между другото, ще бъдат достъпни в началото на август в YouTube.)

Моята сесия имаше 351 посетители и получих страхотни отзиви. Исках да се обърна към някои от това.

Първо, проблем с конфигурацията:използвах чисто нов микрофон и нямах представа, че всяко натискане на клавиш ще звучи като гръм. Реших този проблем с по-добро разположение на периферните си устройства, но искам да се извиня на всички засегнати от това.

След това изтеглянията; тестето и пробите се публикуват на сайта на събитието. Те са в долната част на страницата, но можете да ги изтеглите и от тук.

И накрая, това, което следва, е списък с въпроси, които бяха публикувани по време на сесията и исках да се уверя, че съм се обърнал към всички, на които не е било отговорено по време на въпроси и отговори на живо. Извинявам се, че притиснах това за малко по-малко от месец , но имаше много въпроси и не исках да ги публикувам на части.

А: Ще трябва да подхождате към това за всеки отделен случай, тъй като наистина ще зависи от различни фактори (включително сложността на плана). Също така имайте предвид, че можете да направите прекомпилиране на ниво оператор, така че само засегнатите оператори да поемат удара, за разлика от целия модул. Пол Уайт ми напомни, че хората често "поправят" подслушването на параметри с RECOMPILE , но твърде често това означава С ПРЕКОМПИЛИРАНЕ в стил 2000 вместо много по-добрата ОПЦИЯ (ПРЕКОМПИЛИРАНЕ) , което не само се ограничава до израза, но също така позволява вграждане на параметри, което WITH RECOMPILE не. Така че, ако ще използвате RECOMPILE за да предотвратите подслушването на параметри, добавете го към оператора, а не към модула.

А: Както по-горе, това ще зависи от цената и сложността на плановете и няма начин да се каже „Да, винаги ще има голям успех в производителността“. Трябва също така да сравните това с алтернативата.

А: Не съм сигурен какво означава "четливо в реалния свят". Ако имате предвид, че искате изхода в определен формат, обикновено е по-добре да конвертирате в низ от страна на клиента. C# и повечето други езици, които вероятно използвате на ниво презентация, са повече от способни да форматират изхода дата/час от базата данни в какъвто регионален формат искате.

А: Повечето DMV са валидни само от последното стартиране на услугата и дори други могат да се промиват по-често (дори при поискване – както по невнимание, така и нарочно). Кешът на плана, разбира се, е в постоянен поток и AFAIK планове, които изпадат от кеша, не поддържат предишния си брой, ако се върнат обратно. Така че дори когато видите план в кеша, аз не съм 100% уверени, че можете да повярвате на броя на употребата, който откривате.

Въпреки това, това, което вероятно търсите, е sys.dm_exec_cached_plans.usecounts и можете също да намерите sys.dm_exec_procedure_stats.execution_count за да помогне за допълване на информация за процедури, при които отделни изявления в рамките на процедурите не са открити в кеша.

А: Основните опасения около това са възможността да се използва определен синтаксис, като OUTER APPLY или променливи с функция с таблично значение. Не са ми известни случаи, при които използването на по-ниска съвместимост има пряко въздействие върху производителността, но няколко неща, които обикновено се препоръчват, са да изградите отново индекси и да актуализирате статистиката (и да накарате вашия доставчик да поддържа по-новото ниво на съвместимост възможно най-скоро). Виждал съм, че разрешава неочаквано влошаване на производителността в значителен брой случаи, но също така съм чувал някои мнения, че това не е необходимо и може би дори неразумно.

А: Не, поне по отношение на производителността, едно изключение, където SELECT * няма значение, когато се използва вътре в EXISTS клауза. Но защо бихте използвали * тук? Предпочитам да използвам EXISTS (SELECT 1 ... – оптимизаторът ще ги третира по същия начин, но по някакъв начин самодокументира кода и гарантира, че читателите разбират, че подзаявката не връща никакви данни (дори ако пропуснат големия EXISTS навън). Някои хора използват NULL , и нямам представа защо започнах да използвам 1, но намирам NULL също леко неинтуитивен.

*Забележка* ще трябва да бъдете внимателни, ако се опитате да използвате EXISTS (ИЗБЕРЕТЕ * вътре в модул, който е свързан със схема:

CREATE VIEW dbo.ThisWillNotWork
WITH SCHEMABINDING
AS
  SELECT BusinessEntityID
    FROM Person.Person AS p
	WHERE EXISTS (SELECT * FROM Sales.SalesOrderHeader AS h
	  WHERE h.SalesPersonID = p.BusinessEntityID);

Получавате тази грешка:

Въпреки това го промените на SELECT 1 работи добре. Така че може би това е още един аргумент за избягване на SELECT * дори при този сценарий.

А: Вероятно има стотици на различни езици. Подобно на конвенциите за именуване, стандартите за кодиране са нещо много субективно. Всъщност няма значение каква конвенция решите, че работи най-добре за вас; ако харесвате tbl префикси, полудя! Предпочитайте Pascal пред bigEndian, имайте го. Искате да поставите префикс на имената на колоните си с типа данни, като intCustomerID , няма да те спирам. По-важното е да дефинирате конвенция и да я прилагате *последователно.*

Въпреки това, ако искате моите мнения, не ми липсват.

А: Не знам за никакви планове за оттегляне на XACT_ABORT така че трябва да продължи да работи добре. Честно казано, не виждам това да се използва много често сега, когато имаме TRY / CATCH (и ХВЪРЛЯНЕ от SQL Server 2012).

А: Не тествах това, но в много случаи замяната на скаларна функция с вградена функция с таблично значение може да има голямо влияние върху производителността. Проблемът, който намирам, е, че извършването на този превключвател може да бъде значително количество работа върху системата, която е написана преди APPLY съществуваше или все още се управлява от хора, които не са възприели този по-добър подход.

А: Имам предвид две неща:(1) забавянето е свързано с времето за компилация или (2) забавянето е свързано с количеството данни, които се зареждат, за да удовлетворят заявката, и първия път, когато трябва да дойдат от диск а не памет. За (1) можете да изпълните заявката в SQL Sentry Plan Explorer и лентата на състоянието ще ви покаже времето за компилиране за първото и следващите извиквания (въпреки че една минута изглежда доста прекомерна за това и малко вероятно). Ако не откриете разлика, тогава това може да е просто естеството на системата:недостатъчно памет, за да поддържа количеството данни, което се опитвате да заредите с тази заявка в комбинация с други данни, които вече са били в буферния пул. Ако не вярвате, че нито едно от тях е проблемът, тогава вижте дали двете различни изпълнения всъщност дават различни планове – ако има някакви разлики, публикувайте плановете на answers.sqlperformance.com и ние ще се радваме да разгледаме . Всъщност заснемането на действителни планове и за двете изпълнения с помощта на Plan Explorer във всеки случай може също да ви уведоми за всякакви разлики в I/O и може да доведе до това, където SQL Server прекарва времето си при първото, по-бавно изпълнение.

А: Не, не мисля, че настройката Оптимизиране за ad hoc работни натоварвания ще помогне на този сценарий, тъй като подслушването на параметри предполага, че последващите изпълнения на същия план се използват за различни параметри и със значително различно поведение на производителността. Оптимизиране за ad hoc работни натоварвания се използва за минимизиране на драстичното въздействие върху кеша на плана, което може да се случи, когато имате голям брой различни SQL изрази. Така че освен ако не говорите за въздействие върху кеша на плана на много различни изрази, които изпращате до sp_executesql – което не би се характеризирало като подслушване на параметри – мисля, че експериментирам с OPTION (RECOMPILE) може да има по-добър резултат или, ако знаете стойностите на параметрите, които *правят* дават добри резултати при различни комбинации от параметри, използвайте OPTIMIZE FOR . Този отговор от Пол Уайт може да даде много по-добра представа.

А: Разбира се, просто включете OPTION (RECOMPILE) в динамичния SQL текст:

DBCC FREEPROCCACHE;
 
USE AdventureWorks2012;
GO
SET NOCOUNT ON;
GO
 
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderHeader;';
GO
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderDetail OPTION (RECOMPILE);'
GO
 
SELECT t.[text], p.usecounts
FROM sys.dm_exec_cached_plans AS p
CROSS APPLY sys.dm_exec_sql_text(p.[plan_handle]) AS t
WHERE t.[text] LIKE N'%Sales.' + 'SalesOrder%';

Резултати:1 ред, показващ Sales.SalesOrderHeader запитване.

Сега, ако някое изявление в пакета НЕ включва OPTION (RECOMPILE) , планът все още може да е кеширан, просто не може да се използва повторно.

DBCC FREEPROCCACHE(0x06.....);