Проактивни проверки на състоянието на SQL Server, част 4:ERRORLOG

Има толкова много, които можете да кажете за историята и значението. История на една страна, на цивилизацията, на всеки от нас. Обичам цитати и харесвам този от Теди Рузвелт (готин човек):

Защо съм поетичен (или се опитвам) за историята в блог за SQL Server? Защото историята в SQL Server също е важна. Когато има проблем с производителността в SQL Server, идеално е проблемът да се отстрани на живо, но в някои случаи историческата информация може да осигури пушещ пистолет или поне отправна точка. Страхотен източник на историческа информация в SQL Server е ERRORLOG. Споменах в оригиналната си публикация, Проблеми с производителността:Първата среща, че ERRORLOG преди беше закъснял за мен. Няма повече. По време на одитите на клиента ние винаги улавяме ERRORLOG и макар да сме уведомени за всякакви сигнали с висока степен на сериозност (които се записват в регистрационния файл), не е нещо нечувано да намерим друга интересна информация в дневника. Ние се подготвяме за бъдещето, като използваме историческата информация в регистрационните файлове; информацията може да ни помогне да отстраним проблем или потенциален проблем, преди да е станал катастрофален.

Преглед на ERRORLOG

Първо, ще прегледаме някои опции за преглед на ERROLOG. Ако съм свързан с екземпляр, обикновено ще се придвижвам до него чрез SSMS (Управление | Регистрации на SQL Server, щракнете с десния бутон върху регистър и изберете Преглед на регистрационния файл на SQL Server). От този прозорец мога просто да превъртя дневника или да използвам опциите Филтър или Търсене, за да стесня набора от резултати. Мога също да преглеждам множество файлове, като ги избера в левия панел.

Ако разглеждам данни, заснети в един от нашите одити на здравето, просто ще отворя регистрационните файлове в текстов редактор и ще ги прегледам (имам възможност да вляза във визуализатора и да ги заредя). Регистрационните файлове съществуват в папката с регистрационни файлове (местоположение по подразбиране:C:\Program Files\Microsoft SQL Server\MSSQL12.SQL2014\MSSQL\Log), ако някога съм искал да ги разгледам на сървъра. Много от вас може да предпочетат да преглеждат и/или търсят регистрационния файл с помощта на недокументираната процедура sp_readerrorlog или разширената съхранена процедура xp_readerrorlog.

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

Какво има в ERRORLOG?

И така, каква информация можем да намерим в ERRORLOG, освен грешките? По-долу изброих много от елементите, които намерих за най-полезни. Имайте предвид, че това не е изчерпателен списък (и съм сигурен, че много от вас ще имат предложения какво може да се добави – не се колебайте да публикувате коментар и мога да го актуализирам!), но отново, това съм аз търси първия когато проактивно разглеждам екземпляр.

• Дали сървърът е физически или виртуален (потърсете записа System Manufacturer)
• Флаговете за проследяване са активирани при стартиране
  • В записа за параметрите за стартиране на системния регистър, ако превъртите докрай надясно, ще видите дали някакви флагове за проследяване са активирани:
    
    Флаговете за проследяване са активирани при стартиране
• Флаговете за проследяване са активирани или деактивирани след стартиране на екземпляра
  • Ако потребителите (или приложение) активират или деактивират флаг за проследяване с помощта на DBCC TRACEON или DBCC TRACEOFF, запис се появява в регистрационния файл
• Брой ядра и гнезда, открити от SQL Server
  • Винаги искам да проверя дали SQL Server вижда целия наличен хардуер – и ако не, това е червен флаг за по-нататъшно проучване. За добър пример вижте публикацията на Джонатан, Проблеми с производителността с SQL Server 0212 Enterprise Edition при лицензиране на CAL, и публикацията на Glenn, Балансиране на наличните ви лицензи за SQL Server за ядрото равномерно в NUMA възли, която също включва някои удобни TSQL за запитване на дневника.
  • Обърнете внимание, че текстът за този запис варира между версиите на SQL Server.
• Обем памет, открит от SQL Server
  • Отново искам да проверя дали SQL Server вижда цялата памет, която му е налична.
• Потвърждение, че заключените страници в паметта (LPIM) са активирани
  • Докато тази опция е активирана чрез правилата за сигурност на Windows, можете да потвърдите, че е активирана, като потърсите съобщението „Използване на заключени страници в мениджъра на паметта“ в регистрационния файл.
  • Обърнете внимание, че ако използвате Trace Flag 834, тогава съобщението няма да казва заключени страници, а че големи страници се използват за буферния пул.
• Използвана версия на CLR
• Успешна или неуспешна регистрация на името на главния служител на услугата (SPN)
• Колко време отнема база данни да влезе онлайн
  • Регистърът записва при стартиране на базата данни и когато е онлайн – проверявам дали на някоя база данни е необходимо твърде много време, за да се появи.
• Състояние на крайните точки на брокера на услуги и копиране на база данни – важно, ако използвате някоя от функциите
• Потвърждение, че незабавната инициализация на файл (IFI) е активирана*
  • По подразбиране тази информация не се записва, но ако активирате Trace Flag 3004 (и 3605 за принудително извеждане в регистрационния файл), когато създадете или увеличите файл с данни, ще видите съобщения в регистрационния файл, за да посочите дали IFI използва се или не.
• Състояние на SQL Traces
  • Когато стартирате или спрете SQL Trace, той се регистрира и аз проверявам дали съществуват следи извън трасирането по подразбиране (временно или дългосрочно). Ако използвате инструмент за наблюдение на трета страна, като например SQL Sentry's Performance Advisor, може да видите активна трасировка, която винаги се изпълнява, но улавя само конкретни събития, или може да видите начало на проследяване, което се изпълнява за кратко време, след което Спри се. Не се притеснявам за една или две допълнителни следи, освен ако не улавят много събития, но определено обръщам внимание, когато се изпълняват множество проследявания.
• Последният път, когато CHECKDB беше завършен
  • Това съобщение често се разбира неправилно от хората – когато екземплярът се стартира, той чете страницата за зареждане за всяка база данни и отбелязва кога CHECKDB за последно е стартиран успешно. Повечето хора не четат цялото съобщение:
    
    Дата на последното успешно завършване на DBCC CHECKDB

    Дата за завършване на CHECKDB е 11 ноември 2012 г., но датата на ERRORLOG е 7 юли 2015 г. Важно е да разберете, че SQL Server не стартирайте CHECKDB срещу бази данни при стартиране, той проверява стойността на dbcclastknowngood на страницата за зареждане (за да видите кога се актуализира, вижте публикацията ми, Какво проверява Update dbcclastknowngood. Също така, ако DBCC CHECKDB никога не е бил стартиран срещу база данни, тогава няма запис ще се покаже за базата данни тук.

• Завършване на ПРОВЕРЕТЕ БД
  • Когато CHECKDB се изпълнява срещу база данни, изходът се записва в дневника.
• Промени в настройките на екземпляра
  • Ако промените настройките на ниво екземпляр (напр. максимална памет на сървъра, праг на разходите за паралелизъм) с помощта на sp_configure или чрез потребителския интерфейс (имайте предвид, че не регистрира кой го промени).

• Промени в настройките на базата данни
  • Някой активирал ли е AUTO_SHRINK? Промяна на опцията ВЪЗСТАНОВЯВАНЕ на ПРОСТО и след това обратно на ПЪЛНО? Ще го намерите тук.
• Промени в състоянието на базата данни
  • Ако някой вземе база данни ОФЛАЙН (или я пренесе ОНЛАЙН), това се регистрира.
• Информация за блокиране*
  • Ако трябва да уловите информация за блокиране, не искате да изпълнявате проследяване, и използвате SQL Server 2005 до 2008R2, използвайте флаг за проследяване 1222, за да запишете информация за блокиране в регистъра в XML формат. За тези от вас, които използват SQL Server 2000 и по-долу, можете да проследите флаг 1204 (този флаг за проследяване е наличен и в SQL Server 2005+, но извежда минимална информация). Ако използвате SQL Server 2012 или по-нова версия, това не е необходимо, тъй като сесията на събитието system_health улавя тази информация (и тя е там и през 2008 и 20082, но трябва да я изтеглите от ring_buffer спрямо целта на event_file).
• FlushCache съобщения
  • Ако кешът се промива от SQL Server, тъй като процесът на контролна точка надвишава интервала за възстановяване на базата данни, ще видите набор от FlushCache съобщения в регистрационния файл (вижте тази публикация от Боб Дор за повече информация). Не бъркайте тези съобщения с тези, които се показват, когато стартирате DBCC FREEPROCCACHE или DBCC FREESYSTEMCACHE:
    
    Съобщение след стартиране на DBCC FREEPROCCACHE или DBCC FREESYSTEMCACHE

• Съобщения за разтоварване на AppDomain
  • В регистрационния файл също се отбелязва кога са създадени AppDomains и ще видите едното и другото само ако използвате CLR. Ако видя AppDomain да разтовари съобщения поради натиск в паметта, това е нещо, което трябва да се проучи допълнително.

В регистрационния файл има друга информация, която е полезна, като използван режим на удостоверяване, дали е активирана специалната администраторска връзка (DAC) и т.н., но мога също да получа това от sys.configurations и проверявам тези с базовите линии на екземпляра Обсъждах по-рано (Проактивни проверки на състоянието на SQL Server, част 3:Настройки на инстанция и база данни).

Какво не е в ERROLOG, което може да очаквате?

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

• Добавяне или премахване на файлове на база данни или файлови групи
• Стартиране или спиране на сесии с разширени събития
  • Ако обаче внедрите DDL задействане на ниво сървър или известие за събитие, можете да регистрирате тази информация. Вижте публикацията на Джонатан, Регистриране на разширени събития, промени в ERRORLOG, за повече подробности.
• Изпълнението на DBCC DROPCLEANBUFFERS се показва в регистъра на грешките

Управление на регистрационния файл

Не забравяйте, че по подразбиране SQL Server запазва само последните шест (6) регистрационни файла (в допълнение към текущия файл) и регистрационният файл се преобръща всеки път, когато SQL Server се рестартира. В резултат на това понякога можете да имате изключително големи регистрационни файлове, чието отваряне отнема известно време и е трудно да се разровите. От друга страна, ако попаднете на случай, при който екземплярът се рестартира няколко пъти, може да загубите важна информация. Препоръчително е да увеличите броя на запазените файлове до по-висока стойност (напр. 30) и да създадете задание на агент, за да превъртате файла веднъж седмично, като използвате sp_cycle_errorlog.

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

Архивирането завърши успешно

Ако имате екземпляр с множество бази данни и резервните копия на регистрационните файлове на транзакциите се правят редовно (например на всеки 15 минути), ще видите, че дневникът бързо се запълва със съобщения, което прави намирането на истински проблем по-трудно. За щастие можете да използвате флаг за проследяване 3226, за да деактивирате успешните съобщения за архивиране (грешките все още ще се показват в дневника и всички записи ще продължат да съществуват в msdb).

Друг набор от съобщения, които претрупват дневника, са съобщенията за успешно влизане. Това е опция, която конфигурирате за екземпляра в раздела Защита:

Опция за сигурност за регистриране на успешни и/или неуспешни влизания

Ако регистрирате успешни влизания или неуспешни и успешни влизания, можете да имате много големи регистрационни файлове, дори ако превъртате файловете ежедневно (това ще зависи от това колко потребители се свързват). Препоръчвам да записвате само неуспешни влизания. За фирми, които имат изискване да регистрират успешни влизания, помислете за използването на функцията за одит, добавена в SQL Server 2008. Странична бележка:Ако промените настройката за одит на влизане, тя няма да влезе в сила, докато не рестартирате потребителския модел.

Не подценявайте ERRORLOG

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

Вижте другите части от тази серия:

• Част 1:Дисково пространство
• Част 2:Поддръжка
• Част 3:Настройки за екземпляр и база данни