Споделете сега:
Съдържание крия

1. Въведение в SQL Server Performance Monitor

1.1 Какво е SQL Server Монитор на производителността?

SQL Server Мониторът на производителността е процес на проследяване, анализ и управление на производителността и състоянието на вашия SQL Server бази данни. Това включва събиране и интерпретиране на данни за различни аспекти на вашата система от бази данни, за да се осигури оптимална производителност, да се предотвратят проблеми и да се поддържа здравето на базата данни.

Мониторингът на производителността обхваща проследяване на времето за изпълнение на заявки, използването на ресурси, производителността на индексите, блокирането и безизходицата, както и моделите на растеж на базата данни. Този непрекъснат надзор помага на администраторите да идентифицират потенциални проблеми, преди те да повлияят на потребителите или бизнес операциите.

1.2 Ключови предимства на мониторинга на производителността

Ефективен SQL Server Мониторът за производителност предоставя няколко важни предимства:

  • Проактивно откриване на проблеми: Идентифицирайте и адресирайте потенциални проблеми, преди те да засегнат потребителите или бизнес операциите
  • Оптимизация на производителността: Откриване на пречки и неефективности, за да се подобри цялостната производителност на базата данни
  • Планиране на капацитета: Прогнозирайте нуждите от ресурси и планирайте бъдещ растеж въз основа на исторически данни
  • Съответствие и сигурност: Осигуряване на спазване на регулаторните изисквания и откриване на подозрителни дейности

1.3 Често срещани предизвикателства пред производителността

Без подходящ монитор за производителност на SQL базата данни, организациите са изправени пред няколко риска:

  • Неочакван престой, който нарушава бизнес операциите
  • Лошата производителност на приложението, която влияе върху потребителското изживяване
  • Загуба на данни или повреда
  • Неефективно използване на ресурсите, водещо до ненужни разходи
  • Разочаровани потребители и потенциална загуба на приходи

Според проучване на IDC от 2023 г., 65% от проблемите с производителността на базите данни произтичат от лоши практики за мониторинг или оптимизация.

2. Разбиране на монитора на производителността на Windows (PerfMon)

2.1 Какво е монитор на производителността на Windows?

Мониторът на производителността на Windows (PerfMon) е вграден инструмент на Windows, който следи системните ресурси и производителността на приложенията. SQL Server администраторите, PerfMon предоставя безценна информация както за операционната система, така и за SQL Server показатели, което го прави от съществено значение за цялостен анализ на производителността.

Монитор на производителността на Windows (PerfMon)

PerfMon измерва статистически данни за производителността на редовни интервали и запазва тези данни във файлове за по-късен анализ. Администраторите на бази данни могат да изберат интервала от време, файловия формат и кои статистически данни да наблюдават. Инструментът не е SQL Server-специфичен – системните администратори го използват за наблюдение на самия Windows, Exchange, файловите сървъри и всяко приложение, което може да има проблеми с работата.

2.2 Стартиране на монитора на производителността

Можете да стартирате Performance Monitor, като използвате няколко метода:

  1. Кликнете СТАРТ , Тип Perfmon В полето за търсене щракнете върху „Performand Monitor“ в резултата от търсенето:
    Търсете и стартирайте PerfMon от полето за търсене на Windows.
  2. Натискане Windows + R, Тип Perfmon, и натиснете Въведете
    Стартирайте PerfMon от прозореца за изпълнение на Windows.
  3. Навигирайте до контролен панел. -> Система и защита -> Административни инструменти -> Performance Monitor
    Стартирайте PerfMon от Контролния панел -> Система и сигурност -> Административни инструменти -> Монитор на производителността

3. съществен SQL Server Броячи на производителност

3.1 Броячи на производителността на паметта

Броячите на паметта са критични за мониторинга SQL Server производителност, тъй като те показват дали вашата база данни разполага с достатъчно паметови ресурси.

Налични мегабайти

Този брояч показва количеството физическа памет, което е незабавно достъпно за разпределение. То трябва да остане сравнително постоянно и в идеалния случай да не пада под 4096 MB. Ниските стойности може да показват, че SQL ServerНастройката за максимална памет е оставена по подразбиране или не еSQL Server приложенията консумират памет.

Продължителност на живота на страницата

Очакваната продължителност на живота на страницата измерва колко дълго (в секунди) една страница остава в буферния пула, без да бъде препратена. Нормалната стойност е 300 секунди или повече. По-ниските стойности показват натоварване на паметта и прекомерно оборота на буфера, което намалява ефективността на кеша.

Съотношение на попаденията в кеша на буфера

Този брояч показва процента на заявките за данни, на които е отговорено чрез използване на кеша на SQL буфера (паметта), вместо чрез четене от диск. Обикновено той достига или надвишава 99%. По-ниските стойности показват, че SQL Server се нуждае от повече памет или все още се загрява след рестартиране.

Чакащи предоставяния на памет

Това показва броя на процесите, чакащи паметта в SQL ServerПри нормални условия тази стойност трябва постоянно да бъде 0. По-високите стойности показват недостатъчно разпределение на паметта за SQL Server.

Памет на целевия сървър спрямо обща памет на сървъра

Паметта на целевия сървър показва идеалното количество памет SQL Server иска да използва. Общата памет на сървъра показва какво SQL Server използва в момента. Съотношението между тези стойности трябва да бъде приблизително 1. Значителни разлики може да показват натиск върху паметта или недостатъчна налична памет.

3.2 Броячи на производителността на процесора

Броячите на процесора помагат за идентифициране на затруднения в процесора и разбиране как SQL Server използва изчислителни ресурси.

% време на процесора

Това измерва процента от изминалото време, което процесорът прекарва в изпълнение на неактивни нишки. На активни сървъри стойностите могат да скочат до 100%, но продължителното използване над 70-75% обикновено показва проблеми с производителността за потребителите. Липсващите или неадекватните индекси често причиняват високо натоварване на процесора.

% Привилегировано време

Процесорното време се разделя на потребителски режим и режим на привилегирована обработка (ядро). Целият достъп до диска и входно-изходните операции се извършват в режим на ядрото. Ако този брояч надвиши 25%, системата вероятно извършва твърде много входно-изходни операции. Нормалните стойности варират между 5% и 10%.

Дължина на опашката на процесора

Този брояч показва нишки, чакащи ресурси на процесора. Стойностите са постоянно над 1 (с изключение на SQL Server компресия на резервни копия) показват натоварване на процесора. Това често означава, че на SQL Server машина, което нарушава най-добрите практики.

Превключване на контекста/сек

Това измерва колко често процесорът превключва между нишките. Прекомерното превключване на контекста може да повлияе на производителността и да показва високо натоварване на системата.

3.3 Броячи на производителността на дисковия вход/изход

Дисковите броячи са от съществено значение за наблюдение на производителността на SQL, тъй като дисковите входно-изходни операции често се превръщат в основното пречка в системите за бази данни.

% Време на диска

Това записва процента от времето, през което дискът е бил зает с операции за четене/запис. Стойности, постоянно над 85%, показват затруднено място в I/O операциите. Тъй като дискът е много по-бавен от паметта, намаляването на този показател подобрява производителността.

Средно време на диска (сек.)/четене и средно време на диска (сек.)/запис

Тези броячи измерват средното време (в секунди) за операции по четене и запис. Ако средните стойности надвишават 10-20 ms, на диска му отнема твърде много време за обработка на данните. Устройствата за логове на транзакции изискват особено бърза производителност на запис.

Дължина на опашката на диска

Това показва неизпълнени заявки за четене/запис на диск. Стойности, постоянно по-високи от 2 (или 2 на диск за RAID масиви), показват, че дискът не може да се справи със заявките за входно/изходни операции.

Дискови байтове/сек

Това следи скоростта на прехвърляне на данни към/от диска. Ако тя надвиши номиналния капацитет на диска, данните започват да се натрупват, което се вижда от увеличаването на дължината на опашката на диска.

Прехвърляния на диск/сек

Това проследява броя на операциите за четене/запис, извършени на диска. SQL Server Достъпът до данни обикновено е произволен, което е по-бавно поради движението на главата на устройството. Уверете се, че тази стойност остава под максималната скорост на вашето дисково устройство (обикновено 100/сек за стандартни устройства).

3.4 SQL Server Специфични броячи

3.4.1 Броячи на буферния мениджър

Монитор на броячите на Buffer Manager SQL Serverоперации с буфера на паметта:

  • Прочетени страници/сек: Кумулативен брой четения на физически страници от базата данни
  • Записи на страница/сек: Кумулативен брой записи на физически страници в базата данни
  • Мързеливи записи/сек: Брой буфери, записани от lazy writer за освобождаване на памет
  • Страници/сек за контролни точки: Страници, изчистени от контролна точка или други операции, изискващи изчистване на всички „мръсни“ страници

3.4.2 SQL статистически броячи

Тези броячи предоставят представа за SQL Server обработка на заявки:

  • Групови заявки/сек: Брой SQL пакетни заявки, получени от сървъра. Това служи като бенчмарк за активността на сървъра.
  • SQL компилации/сек: Брой SQL компилации. Трябва да бъде 10% или по-малко от общия брой заявки за пакети/сек.
  • SQL рекомпилации/сек: Брой SQL рекомпилации. Трябва също да бъде 10% или по-малко от общия брой заявки за пакети/сек.

3.4.3 Броячи за обща статистика

  • Потребителски връзки: Брой потребители, свързани към системата. Използва се като еталон за проследяване на растежа на връзките с течение на времето.
  • Блокирани процеси: Текущ брой блокирани процеси. В идеалния случай трябва да е 0

3.4.4 Броячи на мениджъра на паметта

  • Чакащи разрешения за памет: Общ брой процеси, чакащи за предоставяне на памет за работното пространство. В идеалния случай трябва да е 0.

4. Настройване на монитор за производителност за SQL Server(Windows Vista / Server 2008 и по-нови версии)

Първо, трябва да създадем контейнер за по-лесно управление на броячите:

  • За Windows Vista / Server 2008 и по-нови версии можете да създавате набори от колектори на данни в този раздел.
  • За Windows XP / Server 2003 и по-стари версии можете да създавате регистрационни файлове на броячи в следващия раздел.

4.1 Какво представляват комплектите за събиране на данни?

Комплектите за събиране на данни организират броячите на производителността, данните за проследяване на събития и информацията за системната конфигурация в една единица за събиране. Те осигуряват по-голяма гъвкавост от обикновените регистрационни файлове на броячите и позволяват автоматизирано, планирано събиране на данни за цялостно наблюдение на производителността на SQL базата данни.

4.2 Създаване на набор от колектори на данни

Създайте персонализиран набор от колектори на данни за наблюдение SQL Server броячи на производителността:

  1. Отворете монитора на производителността
  2. Разширете Комплекти за събиране на данни
  3. Щракнете с десния бутон Потребителски дефиниран
  4. Изберете НОВ -> Комплект за събиране на данни
    Създаване на нов набор от колектори на данни в PerfMon
  5. Въведете описателно име (напр. „SQL Server „Показатели за ефективност“)
  6. Изберете Създаване ръчно (Разширено)
    Задайте име на описание за набора от колектори на данни
  7. Кликнете Следваща
  8. Проверка Създаване на регистрационни файлове с данни -> Брояч на производителността
    Изберете Създаване на регистрационни файлове с данни -> Брояч на производителността в съветника за създаване на нов набор от колектори на данни.
  9. Кликнете Следваща
  10. Кликнете върху ДОБАВЯНЕ, за избор на броячи
  11. върху ДОБАВЯНЕ, желания SQL Server и системни броячи.
    Добавете броячи на производителността към новия набор за събиране на данни.
  12. комплект Примерен интервал
    • За рутинно наблюдение използвайте 1 минута (60 секунди)
    • За активно отстраняване на неизправности използвайте 15-30 секунди
    • Избягвайте да изпълнявате високочестотни заснемания в дългосрочен план, тъй като те могат да повлияят на производителността и да генерират прекомерно количество данни.

    Задайте интервала на извадката в новия съветник за набор от колектори на данни.

  13. Кликнете Следваща
  14. Изберете местоположението за запазване на лог файловете
    Задайте местоположението за запазване на данните за производителността в новия съветник за набор от колектори на данни.
  15. Кликнете завършеност, ще бъде създаден нов набор от колектори на данни.
  16. По подразбиране новият набор за събиране на данни ще НЯМА да се стартира автоматично. Трябва да го намерите в левия панел, под Изпълнение -> Комплекти за събиране на данни -> Потребителски дефиниран -> Вашият колектор на данни, щракнете с десния бутон върху него и изберете СТАРТ
    Стартирайте нов набор от колектори на данни в PerfMon.

4.3 Ключови броячи за добавяне

  • Памет -> Налични мегабайти
  • Физически диск -> Средно време на четене на диска (всички случаи с изключение на _Total)
  • Физически диск -> Средно време на запис на диска (всички случаи с изключение на _Total)
  • Физически диск -> Четения от диска/сек (всички случаи с изключение на _Total)
  • Физически диск -> Записи на диск/сек (всички случаи с изключение на _Total)
  • Процесор -> % процесорно време (всички случаи с изключение на _Total)
  • SQLServer: Обща статистика -> Потребителски връзки
  • SQLServer: Мениджър на паметта -> Чакащи гранти на паметта
  • SQLServer: SQL статистика -> Пакетни заявки/сек
  • SQLServer: SQL статистика -> SQL компилации/сек
  • SQLServer: SQL статистика -> SQL рекомпилации/сек
  • Система -> Дължина на опашката на процесора

4.4 Задаване на условия за спиране

Конфигурирайте условията за спиране, за да предотвратите неограничен растеж на данните:

  1. След като създадете набора за събиране на данни, щракнете с десния бутон върху него и изберете Имоти
  2. Кликнете върху менюто Условие за спиране етикет
  3. Разреши Обща продължителност
  4. Задайте продължителност на 1 ден (24 часа)
  5. Кликнете OK да запазите

Задайте условието за спиране за набора от колектори на данни

Това гарантира, че логът няма да стане твърде голям и ще се рестартира автоматично, ако е планирано.

4.5 Планиране на събиране на данни

Автоматизирайте събирането на данни, за да осигурите последователен мониторинг:

  1. Щракнете с десния бутон върху вашия набор от данни за събиране на данни и изберете Имоти
  2. Кликнете върху менюто Планирам етикет
  3. Кликнете върху ДОБАВЯНЕ, да създадете нов график
  4. Конфигуриране на начална дата и час
  5. Задайте модел на повторение (напр. ежедневно)
  6. Кликнете OK за запазване на графика

Задайте график за набора от колектори на данни

За автоматично стартиране конфигурирайте комплекта за събиране на данни да се стартира при стартиране на сървъра, като създадете тригер за стартиране в планировчика на задачите на Windows.

5. Настройване на монитор за производителност за SQL Server(Windows XP / Server 2003 и по-стари версии)

За Windows XP / Server 2003 и по-стари версии можете да създавате регистрационни файлове на броячи, които ви позволяват да изберете набор от броячи на производителността и периодично да ги регистрирате във файл.

5.1 Създаване на регистрационни файлове на броячи

Следвайте тези стъпки, за да създадете нов дневник на брояча:

  1. Отворете монитора на производителността
  2. Разширете Дневници и предупреждения за производителност в левия панел
  3. Щракнете с десния бутон Броячни дневници
  4. Изберете Нови настройки на лога
  5. Наименувайте лога с името на вашия сървър на базата данни (напр. „ProductionSQL01“)
  6. Кликнете OK за да започнете конфигурацията

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

5.2 Добавяне на броячи на производителността

След като създадете дневник на брояча, добавете конкретните броячи на производителността, които искате да наблюдавате:

  1. Кликнете върху менюто Добавяне на броячи бутон
  2. Променете името на компютъра, така че да сочи към вашия SQL Server инстанция
  3. Натискане Етикет за зареждане на наличните обекти за производителност
  4. Изберете обект за изпълнение от падащото меню (напр. памет)
  5. Изберете конкретни броячи от Списъкът
  6. Изберете екземпляри, ако е приложимо (напр. отделни процесори или дискове)
  7. Кликнете върху ДОБАВЯНЕ, да се включи броячът
  8. Повторете за всички желани броячи
  9. Кликнете Затвори когато приключи

5.3 Конфигуриране на интервали на вземане на проби

Интервалът на извадката определя колко често Performance Monitor събира данни. Конфигурирайте подходящи интервали въз основа на вашите нужди от мониторинг:

  1. В свойствата на регистрационния файл на брояча намерете Пробни данни на всеки
  2. Задайте интервала (по подразбиране е 15 секунди)
  3. За мониторинг на изходното ниво, използвайте интервали от 1 минута за ежедневно събиране
  4. За отстраняване на неизправности използвайте интервали от 15-30 секунди за кратки импулси.
  5. Кликнете OK да кандидатствате

Не забравяйте, че по-малките интервали генерират повече данни, които могат да бъдат по-трудни за рендиране и анализ. По-големите интервали може да пропуснат важни пикове. Балансирайте гранулираността на данните с изискванията за съхранение и анализ.

5.4 Конфигуриране на лог файлове

Правилната конфигурация на лог файловете гарантира, че данните се съхраняват ефективно и достъпно:

  1. Кликнете върху менюто Лог файлове раздел в свойствата на регистрационния файл на брояча
  2. Променете типа на лог файла на Текстов файл (разделен със запетаи) за лесно импортиране в Excel
  3. Кликнете Определен
  4. Задайте пътя на файла до специално място (напр. споделена папка PerformanceLogs)
  5. Кликнете OK за да потвърдите

Използвайте достъпно през мрежата споделено хранилище за съхранение на лог файлове, за да можете да осъществявате достъп до файлове дистанционно и да ги споделяте с други потребители.

5.5 Настройване на идентификационни данни

Конфигурирайте подходящи идентификационни данни, така че Performance Monitor да може да осъществява достъп до отдалечено SQL Server случаи:

  1. В свойствата на регистрационния файл на брояча намерете Стартирай като
  2. Въведете потребителското име на вашия домейн във формат: ДОМЕЙН\потребителско име
  3. Кликнете Задаване на парола
  4. Въведете и потвърдете паролата си
  5. Кликнете OK да запазите

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

6. Анализиране на данни от монитора на производителността

6.1 Преглед на лог файлове в Performance Monitor

Мониторът на производителността може да показва исторически данни от запазени лог файлове:

  1. Отворете монитора на производителността
  2. В левия прозорец щракнете върху Инструменти за мониторинг -> Performance Monitor.
  3. Щракнете с десния бутон на мишката произволно място в областта на графиката
  4. Изберете Имоти
    Отворете свойствата в PerfMon, като щракнете с десния бутон някъде в областта на графиката.
  5. Кликнете върху менюто  източник етикет
  6. Изберете Лог файлове радио бутон
  7. Кликнете върху ДОБАВЯНЕ,
  8. Отидете до вашия лог файл (.blg или .csv)
  9. Изберете файла и щракнете Отворете
    Задайте лог файла като източник на графиката в PerfMon.
  10. Използвайте Времеви интервал плъзгача, за да изберете периода, който искате да анализирате
  11. Кликнете OK за да затворите диалоговия прозорец „Свойства“
  12. Щракнете върху зелената икона с плюс, за да добавите броячи от лог файла
    Щракнете върху зелената икона с плюс, за да добавите броячи от лог файла в PerfMon.
  13. Изберете желаните броячи за показване
    Добавете желаните броячи към графиката в PerfMon.
  14. Кликнете OK

Графиката вече ще показва исторически данни от лог файла. Използвайте плъзгача „Времеви диапазон“ в „Свойства“, за да стесните избора на конкретни периоди от време за подробен анализ.

6.2 Експортиране на данни в Excel

Excel предоставя мощни възможности за анализ на данни от броячи на производителността:

  1. Отворете Performance Monitor със зареден лог файл
  2. Щракнете с десния бутон на мишката произволно място в областта на графиката
  3. Изберете Запазване на данните като
  4. Изберете местоположение за файла
  5. Изберете Текстов файл (разделен със запетаи) (.csv) от падащото меню
  6. Кликнете Спестявания
  7. Отворете CSV файла в Excel

Експортирайте данните във файл в PerfMon.

Форматирайте експортираните данни за по-добър анализ:

  1. Изтрийте полупразния ред 2 и изчистете клетка A1
  2. Форматирайте колона А като Дата/Час
  3. Форматирайте числови колони с нула десетични знаци и разделител за хиляди
  4. Намиране и замяна на имена на сървъри в заглавките (напр. замяна на „\\SERVERNAME“ с празно поле)
  5. Почистване на имената на обекти в заглавките (напр. „Памет“, „Физически диск“, „Процесор“)
  6. Намалете размера на шрифта на заглавката до 8 пункта за по-добра видимост

6.3 Интерпретиране на стойностите на броячите

6.3.1 Анализ на брояча на паметта

Когато анализирате броячите на паметта, търсете следните индикатори:

  • Налични мегабайти: Трябва да остане постоянно над 4096 MB
  • Продължителност на живота на страницата: Стойности над 300 секунди показват добра памет. По-ниските стойности предполагат напрежение в паметта.
  • Коефициент на попадение в кеша на буфера: Трябва да достигне или надвиши 99%. По-ниските стойности показват прекомерно четене на диска
  • Чакащи разрешения за памет: Винаги трябва да е 0. Всяка положителна стойност показва липса на памет.

6.3.2 Анализ на брояча на процесора

Показателите за производителност на процесора включват:

  • % Време на процесора: Продължителното използване над 75% показва проблеми с производителността. Скоковете до 100% са нормални, но не би трябвало да продължават.
  • Дължина на опашката на процесора: Стойности над 1 показват натоварване на процесора. Проверете диспечера на задачите, за да определите кои процеси консумират процесор.
  • % Привилегировано време: Трябва да остане между 5-10%. Стойности над 25% предполагат прекомерни входно-изходни операции

6.3.3 Анализ на дисковия брояч

Прагове на производителност на диска:

  • Средно време на диска (сек.)/четене и запис: Трябва да остане под 10-20ms. По-високите стойности показват бавни дискови подсистеми.
  • Дължина на опашката на диска: Стойности, постоянно над 2 (или 2 на диск в RAID), показват затруднения в I/O системата.
  • % Време на диска: Продължителните стойности над 85% показват насищане на диска

6.4 Използване на формули и статистика

Добавете статистически формули към Excel за бърз анализ:

  1. Вмъкнете 7 празни реда в горната част на електронната си таблица
  2. Добавете етикети в колона A: Средна стойност, Медиана, Мин., Макс., Стандартно отклонение
  3. В клетка B2 въведете: =AVERAGE(B9:B100) (коригирайте B100 до последния ред с данни)
  4. В клетка B3 въведете: =MEDIAN(B9:B100)
  5. В клетка B4 въведете: =MIN(B9:B100)
  6. В клетка B5 въведете: =MAX(B9:B100)
  7. В клетка B6 въведете: =STDEV(B9:B100)
  8. Копиране на формули във всички колони на брояча
  9. Изберете клетка B9 и натиснете Alt+W+F+Enter, за да замразите панелите

Тези статистически данни помагат за идентифициране на тенденции, отклонения и нормални работни диапазони за всеки брояч.

7. Инструмент за анализ на производителността за регистрационни файлове (PAL)

7.1 Въведение в PAL

Анализът на производителността за регистрационни файлове (PAL) е безплатен инструмент, разработен от Клинт Хъфман, който анализира регистрационните файлове на Performance Monitor и генерира HTML отчети с анализ на прагове. PAL сравнява данните за производителността ви с известни прагове и предоставя подробни препоръки за... SQL Server оптимизация на производителността.

Изтеглете PAL от хранилището на GitHub: https://github.com/clinthuffman/PAL External Link

7.2 Настройка на PAL

Инсталирайте PAL, като следвате тези стъпки:

  1. Изтеглете инсталационния файл за PAL от GitHub
  2. Стартирайте инсталатора
  3. Кликнете Следваща на началния екран
  4. Прегледайте и приемете инсталационната директория
  5. Кликнете Следваща продължавам
  6. Кликнете Инсталирайте за да започне инсталацията
  7. Изчакайте инсталирането да приключи
  8. Кликнете завършеност

7.3 Обработка на лог файлове с PAL

Анализирайте регистрационните файлове на Performance Monitor, използвайки PAL:

  1. Стартирайте PAL от менюто "Старт" или от инсталационната директория
  2. Кликнете върху менюто Дневник на брояча етикет
  3. Кликнете паса за да изберете вашия .blg файл
  4. Отидете до лог файла на вашия Performance Monitor
  5. Кликнете Отворете
  6. Кликнете върху менюто Файл с прагове етикет
  7. Изберете файл с праг от падащото меню (напр. „SQL Server 2016 ")
  8. Кликнете върху менюто въпроси етикет
  9. Отговорете на въпроси относно конфигурацията на вашата система
  10. Посочете дали вашият SQL Server е OLTP или склад за данни
  11. Въведете общата налична RAM памет
  12. Кликнете върху менюто Опции за изход етикет
  13. Изберете изходна директория за HTML отчета
  14. Проверка HTML изходен формат
  15. Кликнете върху менюто Изпълнение етикет
  16. Прегледайте избраните от вас
  17. Проверка Започнете изпълнението сега
  18. Кликнете завършеност

7.4 Анализиране на PAL отчети

След като PAL завърши анализа, той генерира HTML отчет, съдържащ:

  • Резюме на проблемите с изпълнението
  • Подробен брояч анализ с графики
  • Нарушенията на прага са маркирани с цвят
  • Конкретни препоръки за всеки проблем
  • Исторически тенденции и модели

Докладът използва цветово кодиране за обозначаване на сериозността: червено за критични проблеми, жълто за предупреждения и зелено за здрави показатели. Прегледайте всеки раздел, за да разберете пречките в производителността и да следвате препоръките на PAL за оптимизация.

8. Алтернатива SQL Server Инструменти за мониторинг

8.1 Вграден SQL Server Инструменти

8.1.1 SQL Server Дейност Monitor

SQL Server Дейност Monitor показва информация в реално време за SQL Server процеси и производителност:

  1. Отворете SQL Server Management Studio (SSMS) и свързване към вашия сървърен екземпляр
  2. Щракнете с десния бутон върху името на сървъра в Object Explorer
  3. Изберете Дейност Monitor
    Стартиране на Монитора на активността в SQL Server Студио за управление.

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

Монитор на активността в SQL Server

8.1.2 SQL Server Табло за изпълнение

SQL Server Management Studio включва вградени отчети за ефективността:

  1. In SQL Server Management Studio (SSMS), щракнете с десния бутон върху SQL Server екземпляр в Object Explorer
  2. Изберете Доклади -> Стандартни отчети
  3. Изберете от наличните отчети, като например Табло за изпълнение
    Отворете таблото за управление на производителността в SQL Server Студио за управление.

Таблото за управление на производителността предоставя визуална информация за SQL Server производителност на инстанцията, включително използване на системния процесор, текущи заявки за чакане и показатели за производителност. Достъп до него чрез менюто „Стандартни отчети“.

Табло за управление на производителността в SQL Server Студио за управление

8.1.3 SQL Server Profiler

SQL Server Profiler улавя и анализира SQL Server събития като изпълнение на заявки, операции по транзакции и дейности по влизане.

Да започна SQL Server Профайлър:

  1. In SQL Server Студио за управление, щракнете Инструменти -> SQL Server Profiler
    СТАРТ  SQL Server Профильор в SQL Server Студио за управление.

Profiler създава значителни разходи за производителност, така че го използвайте разумно и за предпочитане извън пиковите часове. В повечето сценарии, Extended Events осигурява по-добра производителност с по-малко въздействие.

SQL Server Profiler

8.1.4 Разширени събития

Разширени събития е лека система за наблюдение на производителността, вградена в SQL ServerТой замества SQL Server Профилер с по-добра производителност и по-ниски режийни разходи.

Основните характеристики включват:

  • Фино наблюдение на специфични събития
  • Минимално въздействие върху производителността
  • Персонализируеми сесии за събития
  • Интеграция със SSMS и други инструменти
  • Поддръжка за сложно филтриране и агрегиране

Създаване на разширени сесии за събития чрез SSMS:

  1. In Изследовател на обекти, разширете сървъра си и отидете на Управление -> Разширени събития -> Сесии
  2. Щракнете с десния бутон върху сесии И изберете Съветник за нова сесия
    Започнете нова сесия на разширени събития в SQL Server Студио за управление.
  3. Следвайте инструкциите, за да започнете нова сесия.

8.1.5 Динамични изгледи за управление (DMV)

DMV предоставят подробна информация за състоянието на сървъра за наблюдение на състоянието, диагностициране на проблеми и настройване на производителността. Ключови DMV включват:

  • sys.dm_exec_query_stats: Статистика за ефективността на заявките
  • sys.dm_os_wait_stats: Видове чакане, влияещи върху производителността на сървъра
  • sys.dm_os_performance_counters: SQL Server данни от брояча на производителността
  • sys.dm_exec_requests: В момента се изпълняват заявки
  • sys.dm_exec_sessions: Активни потребителски сесии

Изпращайте заявки към тези изгледи, използвайки T-SQL, за да получите достъп до данни за производителността в реално време и исторически показатели.

Основна употреба

-- See all active connections
SELECT * FROM sys.dm_exec_connections;

-- View current sessions
SELECT * FROM sys.dm_exec_sessions;

-- Check database file stats
SELECT * FROM sys.dm_io_virtual_file_stats(NULL, NULL);

8.2 Решения за мониторинг от трети страни

Redgate SQL монитор

Redgate SQL Monitor е специализиран в мониторинг SQL Server и среди на Azure SQL бази данни. Той осигурява мониторинг на цялото имение, персонализируеми предупреждения и табла за управление, подробни възможности за отчитане и интеграция с други инструменти на Redgate.

Редгейт SQL Server Монитор

SolarWinds SQL Server Инструмент за наблюдение

Слънчевите ветрове SQL Server Инструментът за наблюдение, известен също като SQL Sentry, е предназначен да диагностицира, разрешава и предотвратява сериозни проблеми с производителността на SQL Server.

SolarWinds SQL Server Инструмент за наблюдение

на IDERA SQL Server Инструмент за наблюдение на ефективността

IDERA SQL Diagnostic Manager е мощен SQL Server инструмент за наблюдение на производителността, предназначен да помогне за проактивно наблюдение на производителността, диагностика и настройка.

на IDERA SQL Server Инструмент за наблюдение на ефективността

SQL мониторинг на мениджъра на приложения

Applications Manager предлага Microsoft SQL Server Инструмент за наблюдение, който предоставя полезни ИТ решения. Той е предназначен да наблюдава ефективността на SQL базите данни, като едновременно с това идентифицира грешки и разрешава проблеми, които биха могли да доведат до спиране на работата на организацията.

SQL мониторинг на мениджъра на приложения

8.3 Инструменти за мониторинг с отворен код

DBA Dash

DBA Dash е безплатен инструмент за мониторинг с отворен код, който предоставя информация за SQL Server състояние, производителност и активност. Това е особено полезно за малки до средни среди и включва ежедневни проверки на администратора на бази данни, наблюдение на производителността и проследяване на конфигурацията.

SQLWATCH

SQLWATCH предлага децентрализирано, почти реално време SQL Server мониторинг с 5-секундна гранулираност за улавяне на пикове в натоварването. Поддържа Grafana за табла за управление в реално време и Power BI за задълбочен анализ. Инструментът предоставя обширни опции за конфигуриране, нулеви изисквания за поддръжка и неограничена мащабируемост.

Opserver

Разработен от Stack Exchange, Opserver наблюдава множество системи, включително SQL Server, Redis и Elasticsearch. Той предоставя изглед „всички сървъри“ за статистика за процесора, паметта, мрежата и хардуера във вашата инфраструктура.

sp_Кой е активен

sp_WhoIsActive е цялостна съхранена процедура за наблюдение на активността, създадена от Адам Маханик. Тя работи с всички SQL Server версии от 2005 г. до текущите издания и се използва широко от SQL Server DBA за наблюдение на активността в реално време.

За да използвате sp_WhoIsActive, изтеглете го от http://whoisactive.com/, инсталирайте го във вашата база данни и изпълнете:

EXEC sp_WhoIsActive

Процедурата показва текущо изпълняваните заявки, информация за чакане, подробности за блокиране и консумация на ресурси.

9. Най-добри практики за SQL Server Performance Monitor

9.1 Определяне на базови нива на ефективност

Базовите стойности на производителността установяват нормални оперативни параметри за вашата SQL Server среда. Без базови стойности не можете да определите дали текущите показатели показват проблеми или представляват типично поведение.

Създайте базови линии чрез:

  1. Събиране на данни за производителността по време на нормална работа в продължение на поне една седмица
  2. Заснемане на показатели както по време на пикови, така и извън пикови часове
  3. Документиране на типични стойности за ключови броячи
  4. Записване на сезонни колебания, ако е приложимо
  5. Съхраняване на базови данни за сравнение с бъдещи показатели

Актуализирайте базовите стойности на тримесечие или след значителни промени в инфраструктурата, актуализации на приложенията или модификации на базата данни.

9.2 Задаване на подходящи прагове за предупреждение

Конфигурирайте интелигентни прагове, за да получавате смислени известия, без да се обременявате с тях:

  • Чакащи грантове за памет > 0 показва натиск върху паметта
  • Дължина на опашката на процесора > 2 на ядро ​​предполага затруднения в процесора
  • Диск сек/Четене или Запис > 20ms показва бавен вход/изход
  • Блокирани процеси > 5 сигнала за проблеми със спорове
  • Продължителност на живота на страницата < 300 секунди показва натоварване на паметта

Настройте праговете въз основа на вашите базови данни и специфични характеристики на работното натоварване. Използвайте адаптивни прагове, които отчитат нормалните вариации във вашата среда.

9.3 Редовен преглед и анализ на данните

Планирайте редовни прегледи на ефективността, за да идентифицирате тенденции и възникващи проблеми:

  • Ежедневно: Преглед на показателите на високо ниво и последните сигнали
  • Седмично: Извършвайте задълбочен анализ на тенденциите в производителността
  • Месечно: Генериране на подробни отчети и сравнение с базовите стойности
  • Тримесечно: Преглед на планирането на капацитета и дългосрочните тенденции

Документирайте констатациите и проследявайте подобренията в производителността с течение на времето.

9.4 Разходи за балансиране на мониторинга

Самото наблюдение изразходва ресурси, така че балансирайте събирането на данни с въздействието върху производителността:

  • Използвайте интервали от 30-60 секунди за непрекъснато наблюдение
  • Използвайте интервали от 15 секунди само за активно отстраняване на неизправности
  • Ограничете продължителността на набора за събиране на данни, за да избегнете прекомерни данни
  • Съхранявайте лог файлове на отделни дискове от файловете на базата данни
  • Архивирайте стари данни за производителността, за да поддържате управляеми размери на файловете

Мониторът на производителността добавя минимални режийни разходи, когато е конфигуриран правилно, обикновено под 2% от системните ресурси.

9.5 Дългосрочно съхранение на данни

Запазете данните за производителността за смислен анализ на тенденциите и планиране на капацитета:

  • Съхранявайте данни за ефективността за поне 1-2 години
  • Архивирайте данните в отделно хранилище след 3-6 месеца
  • Компресирайте по-стари лог файлове, за да спестите място
  • Документирайте всички значими събития или промени, които влияят на производителността

Предвид относително малкия размер на данните от броячите на производителността, запазването им за неопределено време често е осъществимо и ценно за дългосрочен анализ.

9.6 Интегриране с DevOps практики

Включване на мониторинг на производителността на базата данни в CI/CD конвейери:

  • Включване на показатели за производителност на базата данни при валидирането на внедряването
  • Автоматизирайте тестването на производителността за нови издания
  • Проверете дали промените в кода не влияят негативно на производителността
  • Създайте показатели за производителност за всяка версия
  • Интегрирайте сигнали за мониторинг със системи за управление на инциденти

10. Отстраняване на често срещани проблеми с производителността

10.1 Идентифициране на пречки в процесора

Затрудненията в процесора се проявяват като бавно време за отговор на заявки и високо натоварване на процесора. Използвайте тези стъпки, за да диагностицирате проблеми с процесора:

  1. Проверете брояча за дължина на опашката на процесора. Стойности над 2 на ядро ​​показват натоварване на процесора.
  2. Преглед на процента процесорно време. Постоянните стойности над 75% предполагат затруднено място на процесора.
  3. Отдалечен работен плот към SQL Server
  4. Отворете диспечера на задачите (Ctrl+Shift+Esc)
  5. Кликнете върху менюто Процеси етикет
  6. Проверка Показване на процеси от всички потребители
  7. Кликнете върху менюто процесор заглавка на колоната за сортиране по използване на процесора
  8. Идентифицирайте кои процеси консумират ресурси на процесора

Ако не-SQL Server приложенията консумират значително количество процесор, премахнете ги от сървъра на базата данни. Ако sqlservr.exe използва много процесор, проверете, като използвате тези методи:

  • Проверете SQL компилации/сек и SQL рекомпилации/сек. Стойности над 10% от пакетните заявки/сек показват прекомерна компилация.
  • Заявка към sys.dm_exec_query_stats за идентифициране на заявки, изискващи интензивно използване на процесора
  • Прегледайте плановете за изпълнение за липсващи индекси или неефективни операции
  • Помислете за добавяне на индекси, за да намалите сканирането на таблици

10.2 Диагностициране на проблеми с паметта

Проблемите с паметта оказват значително влияние SQL Server производителност. Диагностицирайте проблеми с паметта, като използвате тези индикатори:

Налични капки памет

Ако наличните мегабайти (Available MBs) постоянно падат под 100 MB, операционната система е изправена пред недостиг на памет. Windows може да се откаже от страницата. SQL Server паметта на диска, което води до влошаване на производителността.

Ниска продължителност на живота на страницата

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

Ниско съотношение на попадения в кеша на буфера

Коефициент на попадение в буферния кеш под 99% означава SQL Server често чете данни от диска, а не от паметта. Това се случва, когато буферният пул е твърде малък или SQL Server все още загрява след рестартиране.

Чакащи предоставяния на памет

Всяка стойност над 0 за „Изчакващи грантове за памет“ показва, че заявките чакат грантове за памет. Това представлява критичен недостиг на памет, изискващ незабавно внимание.

За да разрешите проблеми с паметта:

  1. Определен SQL Server настройка за максимална памет, за да се остави достатъчно RAM памет за операционната система (обикновено 4-8 GB в зависимост от размера на сървъра)
  2. Активирайте разрешението „Заключване на страници в паметта“ за SQL Server акаунт за услуги
  3. Добавете още физическа RAM памет към сървъра, ако напрежението върху паметта продължава
  4. Идентифицирайте и оптимизирайте заявки, изискващи интензивно използване на паметта

10.3 Разрешаване на проблеми с входно/изходните операции на диска

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

Дължина на опашката с голям диск

Постоянно надвишаваща 2 дължина на опашката на диска (или 2 на диск за RAID) показва, че дисковата подсистема не може да се справи с I/O заявките. Това създава натрупване на чакащи операции.

Прекомерна латентност на диска

Стойностите на „Средно време на диск в секунда/четене“ и „Средно време на диск в секунда/запис“ над 10-20 ms показват бавен отговор на диска. Устройствата за регистрационни файлове на транзакции изискват особено бърза производителност, в идеалния случай под 5 ms за запис.

Висок % време на диска

Продължителният процент на дисково време над 85% показва насищане на диска. Дискът прекарва по-голямата част от времето си в обработка на входно/изходни заявки с малко оставащ капацитет за празен ход.

Преди да отстраните проблеми с диска, уверете се, че те не са симптоми на проблеми с паметта. Недостатъчно памет принуждава SQL Server да чете повече данни от диска, изкуствено завишавайки показателите на диска.

За да разрешите проблеми с входно/изходните данни на истински диск:

  • Надстройте до по-бързи дискове (SSD вместо HDD)
  • Внедрете RAID конфигурации за по-добра производителност
  • Разделете файловете на базата данни, регистрационните файлове на транзакциите и tempdb на различни физически устройства
  • Добавете повече памет, за да намалите четенето на диска
  • Оптимизирайте индексите, за да намалите ненужните входно-изходни операции
  • Прегледайте и оптимизирайте слабо представящите се заявки

10.4 Справяне с блокиране и безизходици

Блокиране възниква, когато една сесия задържа заключвания, които пречат на други сесии да продължат. Следете тези броячи, за да идентифицирате проблеми с блокирането:

  • Блокирани процеси: В идеалния случай трябва да е 0
  • Заключване на изчакване/сек: Брой заявки за заключване, изискващи изчакване
  • Средно време на изчакване: Средна продължителност на чакане на заключване

За да проучите блокирането:

  1. Отваряне на монитора на активността в SSMS
  2. Разширете Процеси раздел
  3. Търсете процеси с ненулево число Блокирано от ценности
  4. Идентифицирайте идентификатора на блокиращата сесия
  5. Прегледайте заявките, причиняващи блокиране

Използвайте sp_WhoIsActive за по-подробен анализ на блокирането. Прекомерните записи wait_info често показват спорове за tempdb или проблеми с блокирането.

За да намалите блокирането:

  • Минимизирайте продължителността на транзакцията
  • Използвайте подходящи нива на изолация
  • Добавете индекси, за да намалите продължителността на заключването
  • Помислете за изолиране на READ_COMMITTED_SNAPSHOT
  • Преглед и оптимизиране на дълго изпълняващи се заявки

10.5 Проблеми с производителността на заявките

Идентифицирането на скъпи заявки е от съществено значение за наблюдение на производителността на SQL. Използвайте тези методи, за да намерите проблемни заявки:

Използване на Монитор на активността

  1. В SSMS щракнете с десния бутон върху името на сървъра
  2. Изберете Дейност Monitor
  3. Разширете Последни скъпи запитвания
  4. Преглед на заявки с висок процесор, продължителност или логически четения

Използване на DMVs

Заявка към sys.dm_exec_query_stats за идентифициране на заявки, изискващи големи ресурси:

SELECT TOP 50
    total_worker_time/execution_count AS avg_cpu_time,
    total_logical_reads/execution_count AS avg_logical_reads,
    execution_count,
    SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset
            WHEN -1 THEN DATALENGTH(qt.text)
            ELSE qs.statement_end_offset
        END - qs.statement_start_offset)/2) + 1) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY total_worker_time DESC

Анализиране на планове за изпълнение

  1. В SSMS отворете нов прозорец за заявки
  2. Кликнете Показване на прогнозен план за изпълнение (Ctrl+L) или Включете действителния план за изпълнение (Ctrl+M)
  3. Изпълнете заявката си
  4. Прегледайте плана за изпълнение на скъпи операции
  5. Търсете сканиране на таблици, сканиране на индекси или операции с висока цена

Оптимизирайте заявките чрез:

  • Добавяне на подходящи индекси
  • Пренаписване на заявки, за да се избегнат скъпи операции
  • Актуализиране на статистиката
  • Използване на специфични имена на колони вместо SELECT *
  • Избягване на ненужни клаузи DISTINCT или ORDER BY

10.6 Откриване и отстраняване на повредена база данни

Повредата в базата данни може да причини влошаване на производителността, загуба на данни и системни повреди. Бързото откриване и отстраняване на повредите е от решаващо значение за поддържане на здравето на базата данни.

Индикатори за корупция в базата данни

Внимавайте за тези признаци на потенциална корупция:

  • Съобщения за грешки в SQL Server дневник на грешките (грешка 823, 824 или 825)
  • Неочаквани грешки в приложението при достъп до конкретни таблици
  • Бавна производителност на заявки при преди това бързи заявки
  • SQL Server сривове или неочаквани рестартирания
  • Подозрителни страници, появяващи се в таблицата msdb.dbo.suspect_pages

Използване на DBCC CHECKDB за откриване

DBCC CHECKDB е основният инструмент за откриване на корупция в базата данни. Стартирайте го редовно, за да откриете проблемите рано.

Мониторинг на подозрителни страници

SQL Server автоматично записва подозрителни страници в базата данни msdb:

SELECT 
    database_id,
    file_id,
    page_id,
    event_type,
    error_count,
    last_update_date
FROM msdb.dbo.suspect_pages
WHERE event_type IN (1,2,3)

Всички върнати редове показват проблеми с корупцията, изискващи незабавно внимание.

Стратегии за предотвратяване на корупцията

  • Активиране на проверка на страницата с опцията CHECKSUM
  • Поддържайте редовни резервни копия на базата данни
  • Използвайте надежден хардуер с корекция на грешки
  • Следете състоянието на диска, като използвате инструменти на производителя
  • Планирайте редовни изпълнения на DBCC CHECKDB
  • Държа SQL Server актуализиран с най-новите корекции

Опции за възстановяване и ремонт

Ако бъдат открити повреди, можете да опитате вградения инструмент DBCC CHECKDB за да ги поправите. Ако не успеете, използвайте инструменти на трети страни, като например DataNumen SQL Recovery който може да се справи с тежки корупции.

11. Усъвършенствани техники за мониторинг

11.1 Мониторинг на хранилището за заявки

Хранилище за заявки, въведено през SQL Server 2016, автоматично събира данни за производителността на заявките. Той предоставя ценна информация за поведението на заявките, плановете за изпълнение и тенденциите в производителността.

Активиране на хранилището за заявки

  1. В SSMS Object Explorer щракнете с десния бутон върху база данни
  2. Изберете Имоти
  3. Кликнете върху менюто Магазин за заявки страница
  4. In Режим на работа (заявено)изберете Чети пиши
  5. Конфигурирайте допълнителни настройки, ако е необходимо
  6. Кликнете OK

Мониторинг на производителността на заявките

Достъп до отчетите на хранилището за заявки чрез Object Explorer:

  1. Разгъване на базата данни в Object Explorer
  2. Разширете Магазин за заявки
  3. Изберете от наличните отчети:
    • Регресирани заявки
    • Общо потребление на ресурси
    • Най-често срещани заявки, изразходващи ресурси
    • Заявки с принудителни планове
    • Проследявани заявки

Откриване на регресия на плана

Хранилището за заявки автоматично открива кога плановете за изпълнение на заявки се променят и производителността се влошава. Прегледайте отчета за регресирани заявки, за да идентифицирате заявките, засегнати от промените в плана.

Управление на принудителния план

Когато Query Store идентифицира по-добър план за изпълнение, принудително SQL Server за да го използвам:

  1. Отворете заявката в хранилището за заявки
  2. Щракнете с десния бутон върху желания план
  3. Изберете План за сила

Това незабавно подобрява производителността, без да е необходима промяна на кода.

11.2 Мониторинг на поддръжката на индекси

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

Проверка на фрагментацията

Използвайте тази заявка, за да проверите фрагментацията на индекса:

SELECT 
    OBJECT_NAME(i.object_id) AS table_name,
    i.name AS index_name,
    ps.avg_fragmentation_in_percent,
    ps.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ps
INNER JOIN sys.indexes i ON ps.object_id = i.object_id 
    AND ps.index_id = i.index_id
WHERE ps.avg_fragmentation_in_percent > 10
    AND ps.page_count > 1000
ORDER BY ps.avg_fragmentation_in_percent DESC

Изпълнявайте тази заявка извън пиковите часове, тъй като може да е ресурсоемка.

Анализ на плътността на страниците

Плътността на страниците показва колко пълни са индексните страници. Ниската плътност води до загуба на място и намалява производителността:

SELECT 
    OBJECT_NAME(i.object_id) AS table_name,
    i.name AS index_name,
    ps.avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ps
INNER JOIN sys.indexes i ON ps.object_id = i.object_id 
    AND ps.index_id = i.index_id
WHERE ps.avg_page_space_used_in_percent < 75

Решения за реорганизация срещу решения за възстановяване

Изберете операции за поддръжка на индекси въз основа на нивата на фрагментация:

  • Фрагментация 10-30%: Използвайте ALTER INDEX REORGANIZE
  • Фрагментация > 30%: Използвайте ALTER INDEX REBUILD
  • Фрагментация < 10%: Не са необходими действия

Операциите по реорганизация изискват по-малко ресурси и могат да се изпълняват онлайн. Операциите по възстановяване са по-щателни, но консумират значителни ресурси.

11.3 Актуализации на статистиката на базата данни

Помощ за статистиката на базата данни SQL ServerОптимизаторът на заявки създава ефективни планове за изпълнение. Остарелите статистики водят до лоша производителност на заявките.

Автоматично възстановяване на статистиката

Активиране на автоматични актуализации на статистиката:

ALTER DATABASE DatabaseName SET AUTO_UPDATE_STATISTICS ON
ALTER DATABASE DatabaseName SET AUTO_CREATE_STATISTICS ON

Мониторинг на статистиката Здраве

Проверете кога е актуализирана статистиката за последен път:

SELECT 
    OBJECT_NAME(s.object_id) AS TableName,
    s.name AS StatisticsName,
    STATS_DATE(s.object_id, s.stats_id) AS LastUpdated,
    sp.rows,
    sp.modification_counter
FROM sys.stats s
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp
WHERE STATS_DATE(s.object_id, s.stats_id) < DATEADD(DAY, -7, GETDATE())
ORDER BY LastUpdated

Актуализирайте статистиката ръчно, когато е необходимо:

UPDATE STATISTICS TableName WITH FULLSCAN

11.4 Събиране на персонализирани данни за производителността

Създавайте персонализирани решения за наблюдение на производителността, като отправяте директни заявки към sys.dm_os_performance_counters и съхранявате резултатите в таблици.

Създаване на персонализирани скриптове за колекции

Създайте съхранена процедура за събиране на данни от брояча на производителността:

CREATE PROCEDURE dbo.CollectPerformanceCounters
AS
BEGIN
    INSERT INTO dbo.PerformanceHistory (
        SampleTime,
        CounterName,
        CounterValue
    )
    SELECT 
        GETDATE(),
        counter_name,
        cntr_value
    FROM sys.dm_os_performance_counters
    WHERE counter_name IN (
        'Page life expectancy',
        'Batch Requests/sec',
        'Buffer cache hit ratio'
    )
END

Използване на sys.dm_os_performance_counters

Директно заявяване на броячи на производителността:

SELECT 
    object_name,
    counter_name,
    instance_name,
    cntr_value,
    cntr_type
FROM sys.dm_os_performance_counters
WHERE object_name LIKE '%Buffer Manager%'
ORDER BY counter_name

Съхраняване на исторически данни

Създайте таблица за съхраняване на показатели за ефективност във времето:

CREATE TABLE dbo.PerformanceHistory (
    ID INT IDENTITY PRIMARY KEY,
    SampleTime DATETIME2 NOT NULL,
    PageLifeExpectancy BIGINT,
    BatchRequestsPerSec DECIMAL(18,4),
    BufferCacheHitRatio DECIMAL(5,2)
)

CREATE CLUSTERED COLUMNSTORE INDEX CCI_PerformanceHistory 
ON dbo.PerformanceHistory

Методи за съхранение на данни с въртящи се криви

Съхранявайте данните в обобщен формат с един ред на време на семплиране и една колона на брояч. Това намалява пространството за съхранение и подобрява производителността на заявките в сравнение със съхраняването на един ред на брояч на семпъл.

11.5 Многосървърно наблюдение

За среди с множество SQL Server случаи, внедрете централизирано наблюдение.

Подход за централизирано наблюдение

  • Създайте специална база данни за мониторинг на отделен сървър
  • Събиране на данни от всички сървъри в централното хранилище
  • Използвайте SQL Server Задачи на агенти за изпълнение на скриптове за събиране
  • Внедряване на събиране на броячи на производителността, достъпни за мрежата

Отдалечено наблюдение на сървъра

Конфигурирайте Performance Monitor да събира данни от отдалечени сървъри, като посочите имена на сървъри при добавяне на броячи. Уверете се, че правилата на защитната стена позволяват трафик на Performance Monitor.

Междусървърно отчитане

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

12. мониторинг SQL Server в облачни среди

12.1 Мониторинг на база данни Azure SQL

Базата данни Azure SQL предоставя вградени възможности за наблюдение, които се различават от локалните SQL Server.

Интеграция на Azure Monitor

Azure Monitor автоматично събира показатели от базата данни на Azure SQL, включително:

  • Използване на DTU или vCore
  • Съхранение ползване
  • Статистика за връзките
  • Безизходици и таймаути

Достъп до тези показатели чрез Azure Portal или Azure Monitor API.

Вградени функции за наблюдение

Базата данни Azure SQL включва:

  • Препоръки за автоматично настройване
  • Анализ на производителността на заявките
  • Интелигентни анализи за откриване на аномалии
  • Вградени предупреждения и диагностика

Анализ на производителността на заявките

Тази функция предоставя визуализация на заявките, които най-много консумират ресурси, анализ на продължителността на заявките и исторически тенденции в производителността. Достъп до нея можете да получите чрез портала на Azure под вашия ресурс на SQL база данни.

12.2 Инструменти за мониторинг, базирани на облака

Облачните платформи предлагат вградени решения за мониторинг, оптимизирани за техните среди:

  • Azure Monitor и Application Insights за база данни на Azure SQL
  • AWS CloudWatch за RDS SQL Server
  • Мониторинг на Google Cloud за облак SQL Server

Тези инструменти се интегрират безпроблемно с облачната инфраструктура и осигуряват унифицирано наблюдение на всички облачни ресурси.

Мониторинг на хибридна среда

За хибридни внедрявания, обхващащи локална и облачна среда, използвайте инструменти, които поддържат и двете среди, като Redgate SQL Monitor, SolarWinds DPA или персонализирани решения, използващи централизирано събиране на данни.

12.3 Разлики в производителността в облака

облак SQL Server среди имат уникални характеристики:

Модели за разпределение на ресурсите

Доставчиците на облачни услуги използват различни методи за разпределение на ресурси (DTU, vCores, безсървърни технологии), които влияят на начина, по който интерпретирате показателите за производителност. Разберете ограниченията и характеристиките на вашето ниво на обслужване.

Съображения за мащабиране

Облачните среди предлагат възможности за динамично мащабиране. Следете използването на ресурси, за да определите кога да увеличите или намалите мащаба. Много облачни платформи предоставят автоматично мащабиране въз основа на прагове на производителност.

13. Автоматизиране на мониторинга на производителността

13.1 SQL Server Работа на агенти

Автоматизирайте събирането на данни с помощта на SQL Server Задачи на агенти за последователно наблюдение без ръчна намеса.

Планирано събиране на данни

  1. В SSMS разгънете SQL Server Агент
  2. Щракнете с десния бутон Работа и изберете Нова работа
  3. Наименувайте задачата (напр. „Събиране на показатели за ефективност“)
  4. Кликнете Стъпки и добавете нова стъпка
  5. Задайте типа на Transact-SQL скрипт
  6. Въведете скрипта си за събиране на данни
  7. Кликнете Списъци и добавете график
  8. Конфигурирайте честотата (напр. на всеки 5 минути)
  9. Кликнете OK да създаде работното място

Автоматизирано отчитане

Създавайте задачи, които генерират отчети за ефективността и ги изпращат по имейл:

  1. Създайте съхранена процедура, която генерира отчети
  2. Използвайте Database Mail за изпращане на отчети по имейл
  3. Планирайте задачата да се изпълнява ежедневно или седмично

13.2 Автоматизация на PowerShell

PowerShell предоставя мощни възможности за автоматизация за SQL Server монитор за производителност.

Скриптове за събиране на броячи на производителността

$counters = @(
    '\Processor(_Total)\% Processor Time',
    '\Memory\Available MBytes',
    '\PhysicalDisk(_Total)\Avg. Disk sec/Read'
)

$data = Get-Counter -Counter $counters -ComputerName 'SQLServer01'
$data.CounterSamples | Export-Csv 'C:\PerfLogs\counters.csv' -Append

WMI заявки

Използвайте WMI за събиране на данни за производителността от отдалечени сървъри:

$cpu = Get-WmiObject Win32_Processor -ComputerName 'SQLServer01'
$memory = Get-WmiObject Win32_OperatingSystem -ComputerName 'SQLServer01'

Write-Host "CPU Usage: $($cpu.LoadPercentage)%"
Write-Host "Available Memory: $([math]::Round($memory.FreePhysicalMemory/1MB,2)) GB"

Автоматизирано известяване

Създайте PowerShell скриптове, които проверяват показатели и изпращат предупреждения, когато праговете са нарушени:

$cpuThreshold = 80
$cpu = (Get-Counter '\Processor(_Total)\% Processor Time').CounterSamples.CookedValue

if ($cpu -gt $cpuThreshold) {
    Send-MailMessage -To 'dba@company.com' -Subject 'High CPU Alert' `
        -Body "CPU usage is $cpu%" -SmtpServer 'smtp.company.com'
}

13.3 Създаване на табла за мониторинг

Визуализирайте данните за ефективността с интерактивни табла за управление за по-добра представа.

Интегриране на Power BI

  1. Свържете Power BI с таблиците си с данни за производителността
  2. Създавайте визуализации за ключови показатели
  3. Добавете слайсери за времеви диапазон и избор на сървър
  4. Публикуване на табла за управление в услугата Power BI
  5. Конфигуриране на графици за автоматично обновяване

Създаване на табло за управление в реално време

Използвайте инструменти като Grafana или персонализирани уеб приложения, за да създавате табла за управление в реално време, които директно запитват DMV и броячи на производителността.

Визуализация на историческите тенденции

Създайте линейни диаграми, показващи тенденциите във времето за:

  • Използване на процесора
  • Използване на паметта
  • Дисков вход/изход
  • Изпълнение на заявката
  • Брой връзки

14. Казуси и практически примери

14.1 Казус: Разрешаване на напрежението от паметта

Идентифициране на симптомите

Продукция SQL Server изпитваше бавно време за отговор на заявките по време на пиковите часове. Потребителите се оплакваха от изчакване на приложенията и влошена производителност.

Контраанализ

Разкрити данни от Performance Monitor:

  • Продължителността на живота на страницата е спаднала до 50 секунди (нормално: >300)
  • Коефициентът на попадение в буферния кеш падна до 85% (нормално: >99%)
  • Чакащите паметни гранта често показваха стойности от 5 до 10
  • Четенията на физически диск/сек се увеличиха значително

Стъпки за разрешаване

  1. Проверени SQL Server настройка за максимална памет – открих, че е зададена по подразбиране (неограничена)
  2. Преглед на общата памет на сървъра спрямо паметта на целевия сървър – показа значителна разлика
  3. Конфигурирана е максималната памет на сървъра, за да се оставят 8 GB за операционната система.
  4. Разрешението „Заключване на страници в паметта“ е активирано за SQL Server акаунт за услуги
  5. Добавени са 32 GB допълнителна RAM памет към сървъра
  6. Мониторирана производителност в продължение на една седмица – продължителността на живота на страницата се стабилизира над 500 секунди

Резултат: Времето за отговор на заявките се подобри с 60%, оплакванията на потребителите спряха и производителността на приложенията се върна към нормалното.

14.2 Казус: Оптимизация на производителността на процесора

Идентифициране на симптомите

A SQL Server постоянно показваше натоварване на процесора над 90% по време на работно време, което причиняваше бавна производителност на приложенията и неудовлетвореност на потребителите.

Контраанализ

Мониторингът на производителността разкри:

  • % Средно време на процесора 92% с чести пикове до 100%
  • Дължината на опашката на процесора постоянно над 4 (сървърът имаше 8 ядра)
  • SQL компилациите/сек бяха 25% от пакетните заявки/сек (трябва да са <10%)
  • SQL рекомпилациите/сек бяха 15% от пакетните заявки/сек

Стъпки за разрешаване

  1. Използвани са DMV за идентифициране на най-консумиращите CPU заявки
  2. Анализирани планове за изпълнение за идентифицирани заявки
  3. Открити са множество сканирания на големи таблици поради липсващи индекси
  4. Създадени са подходящи индекси въз основа на препоръките от плана за изпълнение
  5. Идентифициран динамичен SQL, причиняващ прекомерни компилации
  6. Модифициран код на приложението за използване на параметризирани заявки
  7. Ръководство за внедрен план за проблемни съхранени процедури
  8. Актуализирана статистика за интензивно използвани таблици

Резултат: Използването на процесора спадна средно до 45% през работно време. Времето за изпълнение на заявки се подобри със 70%. Отзивчивостта на приложенията се подобри значително.

14.3 Казус: Разрешаване на пречки при дисков вход/изход

Идентифициране на симптомите

Потребителите съобщиха за изключително бавна реакция на приложението по време на операции по зареждане на данни и вечерна пакетна обработка.

Контраанализ

Данните за производителността показаха:

  • Средното време за запис на диска в секунди надвишава 45 мс на устройството с регистрационния файл на транзакциите
  • Средна дължина на опашката на диска 12 на диск с файлове с данни
  • % дисково време остана над 95% в продължение на часове по време на пакетни задачи
  • Броят на записите на страници/сек беше изключително висок

Стъпки за разрешаване

  1. Проверените настройки на паметта бяха подходящи – не открихме проблеми с паметта
  2. Анализирана конфигурация на диска – открити са всички файлове на един и същ комплект шпиндели
  3. Отделни регистрационни файлове на транзакции на специални бързи SSD дискове
  4. Преместих tempdb на отделни SSD дискове
  5. Внедрени са множество tempdb файлове с данни (по един на ядро)
  6. Надстроени дискове с файлове с данни до конфигурация RAID 10 SSD
  7. Оптимизирани пакетни задачи за използване на по-малки партиди транзакции
  8. Добавени са индекси за намаляване на ненужните сканирания на таблици по време на пакетни операции

Резултат: Средното време за запис на диска в секунди падна до 3 мс. Средната дължина на опашката на диска е под 1. Времето за завършване на пакетни задачи е намалено със 75%.

15. Бъдещи тенденции в SQL Server Мониторинг

15.1 Интеграция на изкуствен интелект и машинно обучение

Изкуственият интелект и машинното обучение се трансформират SQL Server монитор за производителност.

Предсказуем анализ

Моделите за машинно обучение предвиждат бъдещи нужди от ресурси въз основа на исторически данни. Тези системи могат да прогнозират:

  • Кога капацитетът за съхранение ще бъде изчерпан
  • Очаквани изисквания за процесор и памет по време на пикови периоди
  • Влошаване на производителността на заявките, преди да се отрази на потребителите
  • Оптимални времена за дейности по поддръжка

Откриване на аномалии

Инструментите, базирани на изкуствен интелект, автоматично откриват необичайни модели в показателите за производителност. Те идентифицират аномалии, които човешките администратори биха могли да пропуснат, и разграничават нормалните вариации от истинските проблеми.

Автоматизирано отстраняване

Самовъзстановяващите се системи автоматично разрешават често срещани проблеми, когато бъдат открити:

  • Рестартирайте услугите, които са спрели
  • Преразпределете ресурси по време на пиково натоварване
  • Прилагане на актуални корекции за известни проблеми
  • Автоматично възстановяване на фрагментирани индекси

15.2 Еволюция на облачно-базирания мониторинг

Мониторингът на облака продължава да се развива с нови възможности.

Унифицирани платформи за мониторинг

Съвременните платформи осигуряват видимост през едно стъкло върху:

  • На място SQL Server случаи
  • Бази данни, хоствани в облака
  • Хибридни среди
  • Производителност на приложението
  • Инфраструктурни показатели

Тенденции на наблюдаемост

Преходът от наблюдение към наблюдаемост подчертава:

  • Разбиране на поведението на системата от изходите
  • Съпоставяне на показатели, лог файлове и трасирания
  • Задълбочени познания за разпределените системи
  • Диагностика на проблеми в реално време

15.3 Самовъзстановяващи се системи за бази данни

Бъдеще SQL Server версиите ще включват повече автономни възможности.

Автоматична оптимизация

Базите данни ще се оптимизират непрекъснато чрез:

  • Автоматично създаване и премахване на индекси въз основа на натоварването
  • Регулиране на настройките на конфигурацията за оптимална производителност
  • Прозрачно пренаписване на неефективни заявки
  • Динамично управление на разпределението на ресурсите

Интелигентна настройка

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

16. Заключение и ключови изводи

16.1 Обобщение на основните практики за мониторинг

Ефективен SQL Server Мониторът на производителността изисква цялостен подход, съчетаващ инструменти, техники и най-добри практики.

Обобщение на критичните броячи

Фокусирайте усилията си за наблюдение върху тези основни броячи:

  • Памет: Продължителност на живота на страницата, Коефициент на попадение в буферния кеш, Чакащи отпускания на памет
  • CPU: % процесорно време, дължина на опашката на процесора
  • Диск: Средно време на диска в секунда/четене и запис, дължина на опашката на диска
  • SQL ServerПакетни заявки/сек, Компилации/сек, Потребителски връзки

Обобщение на най-добрите практики

  • Установяване на базови линии по време на нормални операции
  • Задаване на интелигентни прагове за предупреждения въз основа на базови стойности
  • Редовно преглеждайте данните за ефективността
  • Мониторинг на баланса с детайлност на данните
  • Запазете дългосрочни данни за анализ на тенденциите
  • Използвайте подходящи инструменти за всеки сценарий на мониторинг

16.2 Подход за непрекъснато усъвършенстване

SQL Server Мониторът на ефективността не е еднократна дейност, а непрекъснат процес, изискващ непрекъснато усъвършенстване.

Редовни цикли на преглед

  • Ежедневно: Проверявайте известията и текущата производителност
  • Седмично: Преглед на тенденциите и идентифициране на нововъзникващи проблеми
  • Месечно: Анализирайте дългосрочните модели и нуждите от капацитет
  • Тримесечно: Актуализиране на базовите стойности и преглед на ефективността на мониторинга

Бъдете в крак с инструментите

Поддържайте инструментите и техниките за мониторинг актуални:

  • Оценете новите функции за мониторинг в SQL Server актуализации
  • Тествайте нововъзникващи инструменти на трети страни
  • Посещавайте обучения и конференции
  • Участват в SQL Server форуми на общността
  • Споделяйте знания с членовете на екипа

16.3 Следващи стъпки

Прилагане SQL Server систематично наблюдение на производителността:

Пътна карта за изпълнение

  1. Седмица 1: Настройте монитора на производителността с основни броячи
  2. Седмица 2: Създаване на набори от колектори на данни за автоматизирано събиране
  3. Седмица 3: Установяване на базови линии по време на нормални операции
  4. Седмица 4: Конфигуриране на предупреждения за критични прагове
  5. Месец 2: Внедряване на допълнителни инструменти за мониторинг (DMV, Extended Events)
  6. Месец 3: Разработване на персонализирани табла за управление и отчети
  7. Текущо: Усъвършенствайте мониторинга въз основа на опита и променящите се изисквания

Допълнителни ресурси

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

17. Често задавани въпроси (FAQ)

17.1 Кои са най-важните SQL Server броячи на производителността за наблюдение?

Най-критичното SQL Server броячите на производителността включват:

  • Памет: Очаквана продължителност на живота на страницата (трябва да бъде >300 секунди) и Коефициент на попадение в буферния кеш (трябва да бъде >99%)
  • CPU: % процесорно време (устойчиви стойности <75%) и дължина на опашката на процесора (трябва да бъде <2 на ядро)
  • Диск: Средно време на диска в секунди/четене и запис (трябва да е <10-20 ms) и дължина на опашката на диска (трябва да е <2 на диск)
  • SQL ServerПакетни заявки/сек, SQL компилации/сек и чакащи паметни грантове (трябва да е 0)

Тези броячи предоставят цялостна информация за състоянието на системата и помагат за бързото идентифициране на пречки.

17.2 Колко често трябва да събирам данни за производителността?

Честотата на събиране зависи от целите на мониторинга:

  • Мониторинг на базовата линия: На всяка 1 минута (60 секунди)
  • Активно отстраняване на неизправности: На всеки 15-30 секунди за кратки периоди
  • Дългосрочна тенденция: На всеки 5 минути

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

17.3 Каква е разликата между Performance Monitor и SQL Server Профайлър?

Монитор на производителността и SQL Server Профайлърите служат за различни цели:

Performance Monitor:

  • Монитори системата и SQL Server броячи на производителността
  • Проследява използването на ресурси (процесор, памет, диск)
  • Ниски режийни разходи, подходящи за непрекъснато наблюдение
  • Предоставя обобщени показатели във времето

SQL Server Профайлър:

  • Следи от индивид SQL Server събития и запитвания
  • Записва подробна информация за изпълнението на заявки
  • По-високи режийни разходи, не се препоръчва за непрекъсната употреба
  • Най-подходящ за отстраняване на проблеми със специфични заявки
  • Отхвърлено в полза на разширени събития

Използвайте Performance Monitor за цялостно системно наблюдение и Extended Events (не Profiler) за подробен анализ на ниво заявка.

17.4 Въздействие на монитора за производителност на Can SQL Server производителност?

Когато е конфигуриран правилно, Performance Monitor има минимално влияние върху SQL Server производителност, обикновено по-малко от 2% режийни разходи. Прекомерното наблюдение обаче може да причини проблеми:

  • Твърде многото броячи увеличават разходите
  • Много кратките интервали на вземане на проби (под 15 секунди) натоварват ресурсите
  • Непрекъснатото високочестотно събиране генерира големи лог файлове

За да се сведе до минимум въздействието:

  • Следете само необходимите броячи
  • Използвайте подходящи интервали от време за вземане на проби (60 секунди за рутинен мониторинг)
  • Съхранявайте лог файлове на дискове отделно от файловете на базата данни
  • Планирайте ресурсоемко наблюдение извън пиковите часове

17.5 Колко дълго трябва да съхранявам данни от мониторинг на производителността?

Съхранението зависи от вашите аналитични нужди и капацитет за съхранение:

  • минимум: 3 месеца за отстраняване на скорошни проблеми
  • Препоръчва се: 1-2 години за планиране на капацитета и анализ на тенденциите
  • Оптимално: Неограничено, ако съхранението позволява, тъй като историческите данни стават по-ценни с течение на времето

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

17.6 Кои са добрите прагови стойности за ключовите броячи на ефективността?

Препоръчителни прагови стойности за алармиране:

  • Чакащи се разрешения за памет: Предупреждение, когато > 0
  • Продължителност на живота на страницата: Предупреждение при < 300 секунди
  • % Време на процесора: Предупреждение, когато > 80% за 5 минути
  • Дължина на опашката на процесора: Предупреждение, когато > 2 на ядро
  • Средно време на диска (сек.)/четене или запис: Предупреждение при > 20 мс
  • Дължина на опашката на диска: Предупреждение, когато > 2 на диск
  • Блокирани процеси: Предупреждение, когато > 5

Коригирайте тези прагове въз основа на вашите базови данни и специфични характеристики на работното натоварване. Това, което е нормално за една среда, може да показва проблеми в друга.

17.7 Как да наблюдавам SQL Server изпълнение от разстояние?

Дистанционно управление на монитора SQL Server случаи, използващи тези методи:

  1. Performance Monitor: Посочете името на отдалечения компютър, когато добавяте броячи
  2. PowerShell: Използвайте параметъра -ComputerName с Get-Counter
  3. КАТ: Свързване с отдалечени сървъри чрез SSMS и заявки към DMVs
  4. Инструменти на трети страни: Повечето инструменти за мониторинг поддържат отдалечено наблюдение на сървъри

Уверете се, че правилата на защитната стена позволяват трафик на Performance Monitor и че имате съответните разрешения на отдалечения сървър. За множество сървъри, помислете за внедряване на централизирано наблюдение със специален сървър за наблюдение и база данни.

17.8 Кой е най-добрият безплатен инструмент за SQL Server монитор за производителност?

Налични са няколко отлични безплатни инструмента за мониторинг SQL Server производителност:

  • Монитор на производителността на Windows: Вграден, изчерпателен и надежден
  • Монитор на активността на SSMS: Мониторинг в реално време без допълнителна инсталация
  • Разширени събития: Вградено леко наблюдение на събития SQL Server
  • sp_Кой е активен: Популярна безплатна съхранена процедура за подробно наблюдение на активността
  • DBA Dash: Инструмент за мониторинг с отворен код и обширни функции
  • SQLWATCH: Отворен код с възможности за наблюдение в почти реално време

За повечето организации, Performance Monitor, комбиниран с SSMS инструменти и sp_WhoIsActive, предоставя отлични възможности за мониторинг без допълнителни разходи.

17.9 Как да експортирам данни от PerfMon за анализ?

Експортиране на данни от монитора на производителността чрез следните методи:

Експортиране в CSV:

  1. Отворете Performance Monitor със зареден лог файл
  2. Щракнете с десния бутон върху графиката и изберете Запазване на данните като
  3. Изберете Текстов файл (разделен със запетаи) (.csv)
  4. Изберете местоположение и запазете
  5. Отвори в Excel за анализ

Използвайте командата Relog:

relog input.blg -f csv -o output.csv

Тази помощна програма за команден ред конвертира двоични лог файлове (.blg) във CSV формат за по-лесен анализ в приложения за електронни таблици.

17.10 Кога трябва да използвам инструменти за наблюдение на трети страни вместо вградени опции?

Обмислете инструменти на трети страни, когато:

  • Управление на голям брой SQL Server случаи (10+)
  • Изискване за централизирано наблюдение в множество центрове за данни
  • Нуждаете се от разширени функции като прогнозен анализ или откриване на аномалии
  • Желание за интегрирано предупреждение със системи за управление на инциденти
  • Изискване за отчитане на съответствието и исторически анализ
  • Липса на ресурси на администратори на бази данни за изграждане и поддръжка на персонализирани решения
  • Мониторинг на хетерогенни среди на бази данни (SQL Server, Oracle, MySQL и др.)

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

18. Допълнителни ресурси

18.1 Официална документация

Microsoft предоставя обширна документация за SQL Server монитор за производителност:

18.2 Препоръчителни инструменти и файлове за изтегляне

Основни инструменти за SQL Server монитор за производителност:

  • PAL инструмент: https://github.com/clinthuffman/PAL
  • sp_Кой е активен: http://whoisactive.com/
  • DBA Dash: https://dbadash.com/
  • SQLWATCH: https://github.com/marcingminski/sqlwatch
  • Комплект за първа помощ (Брент Озар): https://www.brentozar.com/first-aid/
  • SQL Server Студио за управление: https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms

18.3 Ресурси на общността

Учете се от SQL Server общност:

  • SQL Server Централната: https://www.sqlservercentral.com/
  • Блог на Брент Озар: https://www.brentozar.com/blog/
  • SQL Shack: https://www.sqlshack.com/
  • Съвети за MSSQL: https://www.mssqltips.com/
  • Reddit r/SQLServer: https://www.reddit.com/r/SQLServer/
  • Преливане на стека SQL Server етикет: https://stackoverflow.com/questions/tagged/sql-server

Тези ресурси предоставят уроци, съвети за отстраняване на неизправности и най-добри практики от опитни SQL Server професионалисти. Участието в обществени форуми ви помага да се учите от опита на другите и да споделяте собствените си знания.


За автора

Юан Шенг е старши администратор на бази данни (DBA) с над 10 години опит в SQL Server среди и управление на корпоративни бази данни. Той е разрешил успешно стотици сценарии за възстановяване на бази данни във финансови услуги, здравеопазване и производствени организации.

Юан е специализиран в SQL Server възстановяване на база данни, решения с висока наличности оптимизация на производителността. Неговият богат практически опит включва управление на многотерабайтови бази данни, внедряване Винаги включени групи за наличности разработване на автоматизирани стратегии за архивиране и възстановяване за критично важни бизнес системи.

Чрез техническата си експертиза и практичен подход, Юан се фокусира върху създаването на изчерпателни ръководства, които помагат на администраторите на бази данни и ИТ специалистите да решават сложни задачи. SQL Server предизвикателствата ефикасно. Той е в крак с най-новото SQL Server издания и развиващите се технологии за бази данни на Microsoft, като редовно тества сценарии за възстановяване, за да гарантира, че препоръките му отразяват най-добрите практики в реалния свят.

Имате въпроси относно SQL Server възстановяване или имате нужда от допълнителни насоки за отстраняване на проблеми с базата данни? Юан приветства обратна връзка и предложения за подобряване на тези технически ресурси.

Споделете сега: