Въведение
Тази статия е кратък преглед на основната планова поддръжка с база данни на денонощната информационна система, която няма престой, както и подходи за тяхното изпълнение в MS SQL Server.
Всички коментари и актуализации към статията са много благодарни.
Планирана поддръжка
Има следната планирана поддръжка, която бих искал да отбележа:
- Планирани резервни копия с допълнителна проверка без възстановяване
- Насрочено възстановяване на резервни копия за проверка на тяхната ефективност
- Анализ на устройство за съхранение на данни, което съдържа системата и всички необходими бази данни
- Планово тестване на необходимите услуги
- Планирана оптимизация на производителността на системата
- Планирана поддръжка на целостта на данните
- Планирана поддръжка на проверката на данните
Първите три точки са най-важни, тъй като осигуряват възстановяване на системата след различни повреди. Въпреки това бих препоръчал да се изпълнят и най-малко три точки, така че потребителите да могат да работят спокойно (по този начин всички заявки трябва да се изпълняват бързо) и така данните да бъдат валидирани във всички системи за отчитане.
За да се автоматизира планираната поддръжка, е възможно да се подредят нейните части в агента или Windows Scheduler.
Шестата точка е базирана на командата CHECKDB.
Седмата точка е реализирана към областта на домейна, използвана в информационната система.
Ще говоря подробно за първите пет точки.
Насрочено архивиране с допълнителна проверка без възстановяване
Тъй като има много статии по тази тема, трябва да се отбележи, че е необходимо редовно да се извършва тази планирана поддръжка на резервен сървър, а не на основния сървър. Този резервен сървър трябва да съдържа актуални данни (например тази, която е получена с репликация). Освен това трябва да архивирате всички системни бази данни (с изключение на tempdb) на всеки екземпляр на MS SQL Server.
Когато архивирането е неуспешно или сканирането на архивиране идентифицира проблем, е необходимо да докладвате тази информация на администраторите. Например можете да им изпратите имейл.
Важно е да се определи стратегия за архивиране, която ще отговори на следните въпроси:
- Колко често и кога трябва да архивираме данни (пълен, диференциален и регистър на транзакциите)?
- Колко време и кога трябва да изтрием резервните копия?
Насрочено възстановяване на резервни копия за проверка на тяхната ефективност
Препоръчвам да изпълните тази процедура на резервен сървър с помощни програми на трети страни или ВЪЗСТАНОВЯВАНЕ команда.
Когато възстановяването на архива не успее, е необходимо да докладвате тази информация на администраторите. Например можете да им изпратите имейл.
Освен това е необходимо да се възстановят резервни копия на системни бази данни. За да направите това, трябва да ги възстановите като обикновена потребителска база данни с име, което се различава от имената на системните бази данни.
Анализ на устройства за съхранение на данни, които съдържат система и всички необходими бази данни
Трябва да анализирате колко място заема всяка база данни, как се променят размерите на файловете и как се променят размерите на свободното пространство в цялото устройство за съхранение. Например, можете да изпълните тази задача частично с автоматично събиране на данни за файлове на бази данни и логически устройства на операционната система в MS SQL Server.
Можете да правите тази проверка всеки ден и след това да изпращате резултати. Както обикновено, можете да ги изпратите на имейл.
Също така е необходимо да наблюдавате системните бази данни, за да сте сигурни, че всичко работи правилно.
Освен това е важно да тествате устройствата за съхранение, за да проверите дали има амортизация или лоши сектори.
Имайте предвид, че по време на тестване едно устройство трябва да не работи и всички данни трябва да бъдат копирани на друго устройство, тъй като тестването натоварва устройството драстично.
Тази задача е строго свързана със задълженията на системния администратор, така че ще я оставим настрана. За да поемете пълния контрол върху случая, трябва да автоматизирате доставката на отчети по имейл.
Бих препоръчал този тест да се изпълнява два пъти годишно.
Планово тестване на необходимите услуги
Прекъсването на услугата е лоша практика. Следователно резервният сървър ще влезе в действие в случай на повреда. Все пак е необходимо да проверявате журналите от време на време. Освен това можете да мислите и за автоматично събиране на данни с допълнително уведомяване до администратор, като изпратите имейл.
Необходимо е да проверите задачите на SQL Server Agent или Windows Scheduler с автоматично събиране на данни за изпълнени задачи в MS SQL Server.
Планирана оптимизация на производителността на системата
Тя включва следните аспекти:
- Автоматизиране на дефрагментирането на индекса в бази данни на MS SQL Server
- Автоматизиране на събирането на данни за промени в схемите на базата данни в MS SQL Server. Можете да възстановите резервно копие и да сравните промените, например с помощта на dbForge
- Автоматизирано почистване на блокирани процеси в MS SQL Server
- Почистване на кеша на процедурите. Тук трябва да определите кога и какво трябва да се почисти
- Внедряване на индикатор за ефективност
- Разработване и модифициране на клъстерирани индекси
Освен това препоръчвам да изключите AUTO_CLOSE функция.
Понякога по различни причини оптимизаторът паралелизира заявка, което не винаги е оптимално.
Ето защо има някои препоръки, които трябва да имате предвид:
- Ако получите много данни, оставете паралелизъм.
- Ако получите малко данни, не използвайте паралелизъм.
Има два параметъра в настройките на екземпляра на SQL Server, отговорни за паралелизма:
- максимална степен на паралелизъм. За да изключите паралелизма, задайте „1“ като стойност, което означава, че само един процесор ще изпълнява код.
- праг на разходите за паралелизъм. Трябва да бъде зададено по подразбиране.
Има две основни опашки:
- опашка за времето на процесора (QCPU опашка). То се извършва, когато заявката е активирана и се чака процесор да я изпълни.
- опашка за ресурси (QR опашка). То се осъществява, когато заявка чака ресурсите да бъдат освободени, за да изпълни процеса.
Следната формула описва изпълнението на заявката (T):
T=TP+TQR+TCPU+TQCPU, където:
- TP е време за компилиране на план
- TQR е времето на опашката за ресурси (QR опашка)
- TQCPU е времето на опашката за освобождаване на ресурсите (QCPU опашка)
- TCPU е време за изпълнение на заявка
В системния изглед sys.dm_exec_query_stats:
- total_worket_time =TP+TCPU+TQCPU
- total_elapsed_time =TQR+TCPU
Вградените инструменти не позволяват прецизна оценка на времето за изпълнение на заявката.
В повечето случаи total_elapsed_time Ви предоставя времето, което е близко до времето за изпълнение на заявката.
Можете да определите времето за изпълнение на заявката по-точно, като използвате трасиране. Като алтернатива можете да регистрирате началния и крайния час на заявката. Внимавайте със следите, тъй като те значително натоварват системата. По този начин е по-добре да го изпълните на резервен сървър и да събирате данни от основния сървър. В този случай ще бъде заредена само мрежата.
При паралелизиране SQL Server разпределя N процеса на заявка (в изданието Standard n<=4). Всеки процес изисква процесорно време за изпълнение на заявка (един процес не винаги трябва да се изпълнява на всяко ядро).
Колкото повече процеси имате, толкова повече са шансовете някои да бъдат заменени с други, което води до увеличаване на TQCPU.
Може да отнеме много повече време за изпълнение на заявка при паралелизиране в следните случаи:
- Ниска пропускателна способност на дисковата подсистема. В този случай разлагането на заявката отнема много повече време.
- Данните може да са блокирани за процеса.
- Няма индекс за предиката, който води до сканиране на таблицата.
Забележки:
Трябва да деактивирате паралелните заявки на сървъри, където няма нужда да извършвате огромна селекция (total_worket_time трябва да се намали поради възможно намаляване на TCPU и TQCPU). За да направите това, трябва да зададете функцията за максимална степен на паралелизъм на „1“, за да работи само един процесор.
Освен това можете да използвате други рамки за изграждане на система, която определя високоскоростната производителност на базите данни . Важно е да разберете как работят тези рамки и как да интерпретирате извлечените числа.
Що се отнася до разработването и модифицирането на индекси, а именно клъстерирани индекси, основното е да се разбере как се задава логиката на индексите и как работи.
Имайте предвид, че първичният и клъстерираният ключ не означават едно и също:
Първичен ключ е колона или набор от колони, които правят записа уникален в таблицата. За първичния ключ можете да създадете уникален клъстериран или неклъстериран индекс. Първичният ключ се използва в други таблици като външен ключ за осигуряване на целостта на данните.
Клъстериран индекс е B-дърво или негова модификация. Листата съдържат самите данни, докато възлите съдържат информация за индекса. В допълнение, клъстерираният индекс може да бъде и неуникален. Все пак препоръчвам да бъде уникален.
Бих искал да напомня, че B-дървото е структура, която съхранява данни в реда, филтриран от клъстериран индекс. Поради това е важно полетата, избрани като клъстериран индекс, да се групират в низходящ или възходящ ред. За клъстериран индекс можете да използвате колони с цяло число (идентичност), както и данни и време. Все пак колони като уникален идентификатор не са подходящи, тъй като последният ще доведе до редовно преструктуриране на B-дърво, което ще увеличи количеството показания и записи на устройство за съхранение, където се намира базата данни.
Освен това трябва да се уверите, че индексът се използва със системния изглед sys.dm_db_index_usage_stats.
P.S. Необходимо е да се провери дали данните са актуални на резервен сървър, както и да се провери система, която синхронизира тези данни (например репликации).
Прочетете също:
Автоматизиране на дефрагментацията на индекса в бази данни на MS SQL Server
Автоматично събиране на данни за промени в схемата на базата данни в MS SQL Server
Автоматично изтриване на блокирани процеси в MS SQL Server
Отстраняване на неизправности при продължителни заявки в MS SQL Server
Внедряване на индикатор за ефективност
