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

…инга
YPermitin · May 1, 2023 · 7db60fb · 7db60fb
1 parent 36954e0
commit 7db60fb
Showing 1 changed file with 24 additions and 19 deletions.
diff --git a/SQL-Server-Maintenance/Service-Database/Readme.md b/SQL-Server-Maintenance/Service-Database/Readme.md
@@ -27,6 +27,7 @@
       - [Настройка приоритета и исключений для индексов](#настройка-приоритета-и-исключений-для-индексов)
       - [Логи обслуживания статистик](#логи-обслуживания-статистик)
     - [Сервисные функции](#сервисные-функции)
+      - [Контроль логов транзакций](#контроль-логов-транзакций)
       - [Исправление системного кэша объектов для реплик AlwaysOn](#исправление-системного-кэша-объектов-для-реплик-alwayson)
 
 Далее рассмотрим примеры работы с этой базой данных.
@@ -41,18 +42,18 @@
 
 Таким образом, алгоритм создания служебно базы будет следующим:
 
-* Создаем вручную пустую базу с именем **SQLServerMaintenance**.
-* В котнексте созданной базы выполняем [скрипт](CreateServiceDatabaseScript.sql).
+- Создаем вручную пустую базу с именем **SQLServerMaintenance**.
+- В котнексте созданной базы выполняем [скрипт](CreateServiceDatabaseScript.sql).
 
 Все, база готова для использования.
 
 **Плюсы:**
 
-* Простота создания базы с нуля.
+- Простота создания базы с нуля.
 
 **Минусы:**
 
-* Нет возможности простой установки обновлений на эту базу данных. При необходимости обновления чаще всего нужно будет "вычленять" изменения вручную из новых версий скриптов.
+- Нет возможности простой установки обновлений на эту базу данных. При необходимости обновления чаще всего нужно будет "вычленять" изменения вручную из новых версий скриптов.
 
 ### Миграции с поддержкой версионирования и обновления
 
@@ -68,8 +69,8 @@ V<ВерсияМиграции>__<ИмяМиграции>.sql
 
 Использовать миграции также можно двумя путями:
 
-* Запускать последовательно скрипты мигарций на пустой базе. А при появлении новых миграций - запускать их уже на существующей базе для обновления.
-* Использовать решение [Evolve](https://github.com/lecaillon/Evolve), которе авматизирует процесс применения данных миграций на базе данных. Вместо ручного запуска можно выполнить команду вида:
+- Запускать последовательно скрипты мигарций на пустой базе. А при появлении новых миграций - запускать их уже на существующей базе для обновления.
+- Использовать решение [Evolve](https://github.com/lecaillon/Evolve), которе авматизирует процесс применения данных миграций на базе данных. Вместо ручного запуска можно выполнить команду вида:
 
 ```pwsh
 # **migrate** - говорим, что нужно применить миграции.
@@ -84,12 +85,12 @@ V<ВерсияМиграции>__<ИмяМиграции>.sql
 
 **Плюсы:**
 
-* Прозрачный процесс создания и обновления базы данных.
-* Возможность автоматизации обновления базы. CI/CD и все дела.
+- Прозрачный процесс создания и обновления базы данных.
+- Возможность автоматизации обновления базы. CI/CD и все дела.
 
 **Минусы:**
 
-* Сложнее, чем один единственный скрипт.
+- Сложнее, чем один единственный скрипт.
 
 Рекомендую использовать именно миграции.
 
@@ -412,7 +413,7 @@ EXECUTE [SQLServerMaintenance].[dbo].[sp_IndexMaintenance]
 
 Лог операций обслуживания индексов хранится в таблице "MaintenanceActionsLog" и имеет примерно такой вид.
 
-| Id | Period           | TableName     | IndexName        | Operation     | RunDate          | StartDate        | FinishDate       | DatabaseName | UseOnlineRebuild | Comment | IndexFragmentation | RowModCtr | SQLCommand | TransactionLogUsageBeforeMB | TransactionLogUsageAfterMB | 
+| Id | Period           | TableName     | IndexName        | Operation     | RunDate          | StartDate        | FinishDate       | DatabaseName | UseOnlineRebuild | Comment | IndexFragmentation | RowModCtr | SQLCommand | TransactionLogUsageBeforeMB | TransactionLogUsageAfterMB |
 | -- | ---------------- | ------------- | ---------------- | ------------- | ---------------- | ---------------- | ---------------- | ------------ | ---------------- | ------- | ------------------ | --------- | ------------------------------------------------------------------------------------- | --- | --- |
 | 1  | 03.01.2022 11:36 | \_InfoRg931551 | \_InfoRg931551\_1 | REBUILD INDEX | 03.01.2022 11:36 | 03.01.2022 11:36 | 03.01.2022 11:36 | SomeDatabase     | 0                |         | 99                 | 0         | ALTER INDEX \[\_InfoRg931551\_1\] ON \[dbo\].\[\_InfoRg31551\] REBUILD WITH (MAXDOP=8) | 10 | 230 |
 | 2  | 03.01.2022 11:36 | \_InfoRg931551 | \_InfoRg931551\_2 | REBUILD INDEX | 03.01.2022 11:36 | 03.01.2022 11:36 | 03.01.2022 11:36 | SomeDatabase     | 0                |         | 90                 | 0         | ALTER INDEX \[\_InfoRg931551\_2\] ON \[dbo\].\[\_InfoRg31551\] REBUILD WITH (MAXDOP=8) | 230 | 340 |
@@ -507,7 +508,7 @@ GO
 
 Лог операций обслуживания статистики хранится в таблице "MaintenanceActionsLog" и имеет примерно такой вид.
 
-|   | Id | Period           | TableName                     | IndexName                                          | Operation         | RunDate          | StartDate        | FinishDate       | DatabaseName | UseOnlineRebuild | Comment | IndexFragmentation | RowModCtr | SQLCommand | TransactionLogUsageBeforeMB | TransactionLogUsageAfterMB | 
+|   | Id | Period           | TableName                     | IndexName                                          | Operation         | RunDate          | StartDate        | FinishDate       | DatabaseName | UseOnlineRebuild | Comment | IndexFragmentation | RowModCtr | SQLCommand | TransactionLogUsageBeforeMB | TransactionLogUsageAfterMB |
 | - | -- | ---------------- | ----------------------------- | -------------------------------------------------- | ----------------- | ---------------- | ---------------- | ---------------- | ------------ | ---------------- | ------- | ------------------ | --------- | --- | --- | --- |
 | 1 | 1  | 03.01.2022 10:48 | service\_broker\_map          | I\_CLUST                                           | UPDATE STATISTICS | 03.01.2022 10:48 | 03.01.2022 10:48 | 03.01.2022 10:48 | tempdb       | 0                |         | 0                  | 129       | UPDATE STATISTICS \[sys\].\[service\_broker\_map\] \[I\_CLUST\]                                                    | 1 | 2 |
 | 2 | 2  | 03.01.2022 10:48 | service\_broker\_map          | I\_SECONDARY                                       | UPDATE STATISTICS | 03.01.2022 10:48 | 03.01.2022 10:48 | 03.01.2022 10:48 | tempdb       | 0                |         | 0                  | 129       | UPDATE STATISTICS \[sys\].\[service\_broker\_map\] \[I\_SECONDARY\]                                                | 2 | 4 |
@@ -543,20 +544,20 @@ GO
 
 В операциях обслуживания индекса процедуры "sp_IndexMaintenance" имеются несколько параметров для контроля работы:
 
-* Время выполнения контролируется параметрами начала и окончания работы скрипта (@timeFrom и @timeTo).
-* Условия выполнения при заполненном логе транзакций контролируются параметром @maxTransactionLogSizeUsagePercent, который содержит процент заполнения журнала транзакций, после которого операции обслуживания останавливаются.
+- Время выполнения контролируется параметрами начала и окончания работы скрипта (@timeFrom и @timeTo).
+- Условия выполнения при заполненном логе транзакций контролируются параметром @maxTransactionLogSizeUsagePercent, который содержит процент заполнения журнала транзакций, после которого операции обслуживания останавливаются.
 
 Данный вид контроля работает отлично, но не во всех случаях. Например, если перестроение индекса идет длительное время и журнал транзакций при этом уже заполнен более чем на указанный в ограничениях процент, то никаких проверок по логу транзакций не сработает. Это происходит потому что процент заполнения лога транзакций проверяется перед каждой операцией обслуживания, а не во время их выполнения.
 
 В тех случаях, когда контроль нужно выполнять на постоянной основе и это может оказаться критичным для работоспособности базы данных, то можно включить дополнительный контроль через процедуру "sp_ControlTransactionLogUsage". Суть работы процедуры заключается в следующем:
 
 1. Сначала в таблице **LogTransactionControlSettings** нужно указать список параметров для контроля:
 
-  * **DatabaseName** - имя базы данных, для которой необходимо выполнять контроль.
-  * **MinDiskFreeSpace** - минимальный объем свободного места на диске (в МБ), на котором расположен файл лога транзакций.
-  * **MaxLogUsagePercentThreshold** - максимальный процент использования файла лога транзакций, после которого начинается проверка свободного места на диске. По умолчанию 90%.
+- **DatabaseName** - имя базы данных, для которой необходимо выполнять контроль.
+- **MinDiskFreeSpace** - минимальный объем свободного места на диске (в МБ), на котором расположен файл лога транзакций.
+- **MaxLogUsagePercentThreshold** - максимальный процент использования файла лога транзакций, после которого начинается проверка свободного места на диске. По умолчанию 90%.
 
-2. Затем необходимо запускать процедуру контроля использования логов транзакций. Можно это делать вручную, но лучше сделать задание на автоматический запуск раз в 15 секунд. Контролья для всех баз выглядит так:
+2. Затем необходимо запускать процедуру контроля использования логов транзакций. Можно это делать вручную, но лучше сделать задание на автоматический запуск раз в 15 секунд. Контроль для всех баз выглядит так:
 
 ```sql
 EXECUTE [SQLServerMaintenance].[dbo].[sp_ControlTransactionLogUsage] 
@@ -570,10 +571,14 @@ EXECUTE [SQLServerMaintenance].[dbo].[sp_ControlTransactionLogUsage]
   ,@showDiagnosticMessages = 1
 ```
 
-Сбрасываться будут только текущие запросы обслуживания индексов (операции перестроения и организации индексов в текущей базе).
-
 Отладочные сообщения нужны лишь для помощи отладки проверок.
 
+Сбрасываться будут только текущие запросы обслуживания индексов (операции перестроения и организации индексов в текущей базе). При каждом запуске выполняется проверка для каждого отдельного файла лога транзакций в базе (файлов логов транзакций может быть несколько):
+
+- Место на диске больше минимального значения, указанного в таблице настроек.
+- Если места свободного меньше, чем нужно, то выполняется проверка заполненности лога транзакций. Если лог заполнен более чем указанный % в настройках, то все запросы обслуживания баз данных принудительно завершаются.
+- Кроме этого выполняется проверка заполнености лога транзакций с учетом максимального его размера. Максимальный размер лога определяется ограничениями роста файла лога транзакций, которые могут быть установлены явно или установлены не явно. Например, если ограничений не установлено, то максимальный размер файла лога равен 2 ТБ (это системные ограничения). В тех случаях, если файл лога транзакций становится заполненным более чем на 90% от его максимально возможного размера, то текущие операции обслуживания также прекращаются.
+
 Таким образом, можно контролировать рост файла лога транзакций не допуская его переполнения до 100%. Особенно это может быть критично, если база включена в группу доступности AlwaysOn. При заполнении лога транзакций до 100% ошибку можно будет "вылечить" чаще всего путем "разбора" группы доступности и следующим освобождением файла лога. Такой маневр иногда может стоить большого количества времени и простоя реплик.
 
 #### Исправление системного кэша объектов для реплик AlwaysOn