Поддържането на високопроизводителни екземпляри на SQL Server е огромна част от длъжностните отговорности на DBA. Неуспехът да се открие и коригира необичайна дейност може да повлияе на вътрешните операции, както и да навреди на крайния резултат на бизнеса.
Ако забележите пикови промени в активността или аномалии в екземпляр на SQL Server, ето три места, от които да започнете търсенето на отговори.
Продължителност на живота на страницата
Очакваната продължителност на живота на страницата на екземпляр (PLE) трябва да поддържа доста последователен диапазон от стойности. Ако тази стойност спадне и остане ниска, това е знак, че буферният пул изпитва повишено търсене.
Преди да свършите и да увеличите паметта, погледнете активността на натоварването. Ако работното натоварване се е увеличило, това би отчитало допълнителния натиск върху буферния пул. Но ако работното натоварване не се е променило, ще трябва да погледнете по-внимателно, за да определите какво използва допълнителната памет.
Възможните причини за спад в PLE включват активно изпълняване на задачи за поддръжка, възстановяване на индекси или актуализации на статистиката, DBCC операции и промени в плана за заявки.
Ако забележите спад в PLE, който не е свързан с увеличаване на работното натоварване, има няколко неща, които можете да опитате да подобрите PLE на екземпляр:
- Изхвърлете неизползваните индекси
- Обединяване на дублиращи се индекси
- Внимавайте за големи заявки
- Дефрагментиране
- Изчистване на данните
WRITELOG Време за изчакване
Когато времето за изчакване на WRITELOG е твърде голяма част от общото време за изчакване, вероятно имате затруднение във вашия екземпляр на SQL Server. Тесното място вероятно е причинено или от проблем на диска, където се съхранява регистрационният файл на транзакциите, или от неефективното предаване на данни.
За да определите с какъв вид пречки имате работа, започнете с анализ на броя на SQL изразите, които чакат събитието WRITELOG. Ако има много изявления, които чакат, имате затруднено място на диска. Ако чакат само няколко изявления, вероятно данните се записват твърде често.
Има няколко начина да разрешите голямото време на изчакване WRITELOG, след като разберете дали вашето затруднение е свързано с диск или свързано с записване:
- Добавете I/O честотна лента към диска, където се съхранява регистърът на транзакциите
- Преместване на I/O дневник без транзакции от диска
- Преместете регистъра на транзакциите на по-малко натоварен диск
- Намалете размера на регистъра на транзакциите
- Уверете се, че операторът COMMIT е поставен в кода, така че данните да не се записват твърде често
TempDB
TempDB е временно работно пространство в SQL Server, което съдържа временни обекти. Тъй като обектите, държани в TempDB, са преходни, екземпляр на SQL Server пресъздава TempDB всеки път, когато се рестартира. Това прави оптимизирането на TempDB критично за поддържане на производителността и избягване на оперативни тесни места.
Спорът за TempDB е един от основните виновници за влошаването на производителността. Конфликт възниква, когато множество ресурси се нуждаят от достъп до TempDB, но има само един TempDB файл с данни. Това причинява затруднение, тъй като процесите не могат да имат достъп до TempDB достатъчно бързо, което води до изтичане на времето за свързване и освобождаване на процесите.
За щастие, затрудненията на TempDB могат да бъдат разрешени сравнително лесно чрез коригиране на броя и размера на TempDB файловете. При инсталиране SQL Server по подразбиране е един файл с данни TempDB. Ако забележите, че възниква спор, се препоръчва да добавите осем нови файла с данни и да определите дали това отстранява проблема. Ако проблемът не бъде разрешен, опитайте да добавите допълнителни файлове с данни, кратни на четири, докато производителността се възстанови.
Въпреки че е страхотно да знаете откъде да започнете да търсите, когато имате проблеми с производителността, всеки от проблемите по-горе и произтичащите от това тесни места могат да бъдат смекчени или избегнати като цяло чрез прилагане на едно твърдо и бързо правило:Наблюдението на показателите за производителност не е по избор. Ето няколко примера за ключови показатели за проследяване:
Продължителност на живота на страницата:Проследявайте PLE с непрекъснато наблюдение и бъдете проактивни, когато падне и остане под типичната стойност за конкретен екземпляр на SQL Server.
WRITELOG времена на изчакване:Наблюдавайте показатели като нарастване на дневника, свиване на дневника, използван процент на дневник и изчакване на изтриване на регистрационни файлове/сек.
Неефективност на TempDB:Следете какво се разпределя на потребителски обекти, хранилище на версии или вътрешни обекти. Проследете как се развиват във времето, след което определете кои сесии консумират TempDB и колко.
На пазара има някои отлични богати на функции и достъпни инструменти за наблюдение на производителността на SQL Server, които могат да ви помогнат да останете пред проблеми, влошаващи производителността. Станете MVP на DBA на компанията, като проактивно проучвате решения, които поддържат както насочените навътре операции, така и насочените навън бизнес услуги да работят с максимална производителност.
