Въведение
Всяка операция за архивиране в SQL Server се записва в регистъра за грешки на SQL Server. Това включва резервни копия на регистрационните файлове на транзакциите, дори когато се появяват като част от конфигурация за доставка на регистрационните файлове на транзакциите. Понякога регистрирането на цялото архивиране на регистрационни файлове може да бъде неудобство в регистъра за грешки на SQL Server и трябва да се управлява. Trace Flag 3226 се използва за потискане на такова регистриране и ние ще демонстрираме как това може да се направи в тази статия.
Конфигуриране на доставка на регистрационни файлове на транзакциите
За да демонстрираме стойността на този флаг за проследяване, ще приложим малка конфигурация за доставка на дневници, използвайки база данни на SQL Server 2017, наречена Practice2017 . Основният ни пример е EPG-KIGIRI\I2017 и репликираме тази база данни в екземпляр на SQL Server 2019 EPG-KIGIRI\I2019 (Виж фиг. 2). Целият конфигурационен скрипт е показан в листинг 1.
Фиг. 1 Конфигурация за доставка на регистрационни файлове на Основно
[expand title =”Код “]
-- Listing 1: Transaction Log Shipping Configuration Script -- Execute the following statements on the primary to configure log shipping -- for database [EPG-KIGIRI\I2017].[Practice2017], -- The script is to be run on the primary in the context of the [msdb] database. ------------------------------------------------------------------------------------- -- Adding the log shipping configuration -- ****** Begin: Script to be run on the primary: [EPG-KIGIRI\I2017] ****** DECLARE @LS_BackupJobId AS uniqueidentifier DECLARE @LS_PrimaryId AS uniqueidentifier DECLARE @SP_Add_RetCode As int EXEC @SP_Add_RetCode = master.dbo.sp_add_log_shipping_primary_database @database = N'Practice2017' ,@backup_directory = N'G:\Backup\LogShip\' ,@backup_share = N'\\Epg-kigiri\g$\Backup\LogShip\' ,@backup_job_name = N'LSBackup_Practice2017' ,@backup_retention_period = 1440 ,@backup_compression = 2 ,@monitor_server = N'EPG-KIGIRI\I2017' ,@monitor_server_security_mode = 1 ,@backup_threshold = 60 ,@threshold_alert_enabled = 1 ,@history_retention_period = 2880 ,@backup_job_id = @LS_BackupJobId OUTPUT ,@primary_id = @LS_PrimaryId OUTPUT ,@overwrite = 1 IF (@@ERROR = 0 AND @SP_Add_RetCode = 0) BEGIN DECLARE @LS_BackUpScheduleUID As uniqueidentifier DECLARE @LS_BackUpScheduleID AS int EXEC msdb.dbo.sp_add_schedule @schedule_name =N'LSBackupSchedule_EPG-KIGIRI\I20171' ,@enabled = 1 ,@freq_type = 4 ,@freq_interval = 1 ,@freq_subday_type = 4 ,@freq_subday_interval = 5 ,@freq_recurrence_factor = 0 ,@active_start_date = 20190113 ,@active_end_date = 99991231 ,@active_start_time = 0 ,@active_end_time = 235900 ,@schedule_uid = @LS_BackUpScheduleUID OUTPUT ,@schedule_id = @LS_BackUpScheduleID OUTPUT EXEC msdb.dbo.sp_attach_schedule @job_id = @LS_BackupJobId ,@schedule_id = @LS_BackUpScheduleID EXEC msdb.dbo.sp_update_job @job_id = @LS_BackupJobId ,@enabled = 1 END EXEC master.dbo.sp_add_log_shipping_primary_secondary @primary_database = N'Practice2017' ,@secondary_server = N'EPG-KIGIRI\I2019' ,@secondary_database = N'Practice2017' ,@overwrite = 1 -- ****** End: Script to be run on the primary: [EPG-KIGIRI\I2017] ****** -- Execute the following statements on the secondary to configure log shipping -- for database [EPG-KIGIRI\I2019].[Practice2017], -- the script to be run on the secondary in the context of the [msdb] database. ------------------------------------------------------------------------------------- -- Adding the log shipping configuration -- ****** Begin: Script to be run on the secondary: [EPG-KIGIRI\I2019] ****** DECLARE @LS_Secondary__CopyJobId AS uniqueidentifier DECLARE @LS_Secondary__RestoreJobId AS uniqueidentifier DECLARE @LS_Secondary__SecondaryId AS uniqueidentifier DECLARE @LS_Add_RetCode As int EXEC @LS_Add_RetCode = master.dbo.sp_add_log_shipping_secondary_primary @primary_server = N'EPG-KIGIRI\I2017' ,@primary_database = N'Practice2017' ,@backup_source_directory = N'\\Epg-kigiri\g$\Backup\LogShip\' ,@backup_destination_directory = N'G:\Backup\LogShipCopy\' ,@copy_job_name = N'LSCopy_EPG-KIGIRI\I2017_Practice2017' ,@restore_job_name = N'LSRestore_EPG-KIGIRI\I2017_Practice2017' ,@file_retention_period = 1440 ,@monitor_server = N'EPG-KIGIRI\I2017' ,@monitor_server_security_mode = 1 ,@overwrite = 1 ,@copy_job_id = @LS_Secondary__CopyJobId OUTPUT ,@restore_job_id = @LS_Secondary__RestoreJobId OUTPUT ,@secondary_id = @LS_Secondary__SecondaryId OUTPUT IF (@@ERROR = 0 AND @LS_Add_RetCode = 0) BEGIN DECLARE @LS_SecondaryCopyJobScheduleUID As uniqueidentifier DECLARE @LS_SecondaryCopyJobScheduleID AS int EXEC msdb.dbo.sp_add_schedule @schedule_name =N'DefaultCopyJobSchedule' ,@enabled = 1 ,@freq_type = 4 ,@freq_interval = 1 ,@freq_subday_type = 4 ,@freq_subday_interval = 15 ,@freq_recurrence_factor = 0 ,@active_start_date = 20190114 ,@active_end_date = 99991231 ,@active_start_time = 0 ,@active_end_time = 235900 ,@schedule_uid = @LS_SecondaryCopyJobScheduleUID OUTPUT ,@schedule_id = @LS_SecondaryCopyJobScheduleID OUTPUT EXEC msdb.dbo.sp_attach_schedule @job_id = @LS_Secondary__CopyJobId ,@schedule_id = @LS_SecondaryCopyJobScheduleID DECLARE @LS_SecondaryRestoreJobScheduleUID As uniqueidentifier DECLARE @LS_SecondaryRestoreJobScheduleID AS int EXEC msdb.dbo.sp_add_schedule @schedule_name =N'DefaultRestoreJobSchedule' ,@enabled = 1 ,@freq_type = 4 ,@freq_interval = 1 ,@freq_subday_type = 4 ,@freq_subday_interval = 15 ,@freq_recurrence_factor = 0 ,@active_start_date = 20190114 ,@active_end_date = 99991231 ,@active_start_time = 0 ,@active_end_time = 235900 ,@schedule_uid = @LS_SecondaryRestoreJobScheduleUID OUTPUT ,@schedule_id = @LS_SecondaryRestoreJobScheduleID OUTPUT EXEC msdb.dbo.sp_attach_schedule @job_id = @LS_Secondary__RestoreJobId ,@schedule_id = @LS_SecondaryRestoreJobScheduleID END DECLARE @LS_Add_RetCode2 As int IF (@@ERROR = 0 AND @LS_Add_RetCode = 0) BEGIN EXEC @LS_Add_RetCode2 = master.dbo.sp_add_log_shipping_secondary_database @secondary_database = N'Practice2017' ,@primary_server = N'EPG-KIGIRI\I2017' ,@primary_database = N'Practice2017' ,@restore_delay = 0 ,@restore_mode = 0 ,@disconnect_users = 0 ,@restore_threshold = 45 ,@threshold_alert_enabled = 1 ,@history_retention_period = 2880 ,@overwrite = 1 END IF (@@error = 0 AND @LS_Add_RetCode = 0) BEGIN EXEC msdb.dbo.sp_update_job @job_id = @LS_Secondary__CopyJobId ,@enabled = 1 EXEC msdb.dbo.sp_update_job @job_id = @LS_Secondary__RestoreJobId ,@enabled = 1 END -- ****** End: Script to be run on the secondary: [EPG-KIGIRI\I2019] ******
[/expand]
Задачите за архивиране, копиране и възстановяване са планирани да се изпълняват на всеки пет минути и винаги, когато това се случи, механизмът на базата данни също записва запис в регистъра за грешки. Това може да се счита за излишно, тъй като можем лесно да проследяваме архивите на регистрационните файлове, използвайки историята на заданията на SQL Agent.
Фиг. 2 Резервни записи за доставка на регистрационни файлове в дневника за грешки в SQL
Активиране на Trace Flag 3226
Обикновено можем да активираме флагове за проследяване или за текущата връзка, или глобално. Можем да използваме T-SQL, за да активираме флагове за проследяване или да внедрим флага за проследяване в параметрите за стартиране на SQL Server. Препоръчително е да използвате подхода на стартовите параметри, за да активирате флаговете за проследяване, които искате да приложите към потребителския модел. За да приложите флага за проследяване 3226 в параметрите за стартиране на SQL Server, следвайте тези стъпки:
- Изпълнете SQL Server Configuration Manager като Администратор
Фиг. 3 Стартирайте SQL Server Configuration Manager като администратор
- Щракнете с десния бутон върху желания екземпляр и щракнете върху Свойства .
Фиг. 4 Отворете свойствата на екземпляра
- Изберете Параметри за стартиране
Фиг. 5 параметри за стартиране
- В текстовото поле с надпис Посочете стартов параметър , тип –T3226 и щракнете върху Добавяне .
Фиг. 6 Добавяне на флаг за проследяване 3226 като стартов параметър
- Веднъж –T3226 е добавен към списъка със Съществуващи параметри , щракнете върху OK .
-- Listing 2: Enable a Trace Flag -- Turn on a trace flag for the current connection DBCC TRACEON (3205); GO -- Turn on a trace flag globally DBCC TRACEON (3205, -1); GO
Регистърът за грешки на SQL Server показва, че флагът за проследяване е активиран при стартиране. (Вижте Фиг. 8)
Фиг. 8 Параметри при стартиране Посочени в регистъра за грешки на SQL Server
Преглед на резултатите
След като се потвърди, че флагът за проследяване работи, откриваме, че регистрационният файл за грешки на SQL Server вече не записва резервни копия на регистрационни файлове, свързани с доставка на регистрационни файлове (или друго архивиране на регистрационни файлове), в регистъра за грешки. Обърнете внимание на Фиг. 9, показваща, че всички архивни копия на регистрационни файлове, съхранени в хронологията на заданията за архивиране, не се записват в регистъра за грешки. Това е в съответствие с точката, в която сме активирали флаг за проследяване 3226 (около 20:15).
Фиг. 9 Няма записани резервни копия на регистрационни файлове в регистъра за грешки на SQL Server
Ако активираме и флаг за проследяване 3226 на вторичния екземпляр EPG-KIGIRI\I2019, откриваме, че операциите за възстановяване на регистрационни файлове също вече не се записват в регистъра за грешки, тъй като активирахме флаг за проследяване 3226 на вторичния екземпляр около 20:30. (Вижте Фиг. 10)
Заключение
В тази статия ние демонстрирахме как можем да използваме флаг за проследяване 3226, за да потиснем регистрирането на резервни копия на регистрационните файлове на транзакциите на първичния екземпляр, а регистърът на транзакциите възстановява настройките за доставка на регистрационни файлове на вторичния екземпляр. Това ще бъде много полезно, за да избегнете ненужно регистриране, което може да „скрие“ реални проблеми, изскачащи в регистъра за грешки.
Препратки
Флагове за проследяване на DBCC TraceOn
