Wprowadzenie
Każda operacja tworzenia kopii zapasowej w programie SQL Server jest zapisywana w dzienniku błędów programu SQL Server. Obejmuje to kopie zapasowe dziennika transakcji, nawet jeśli występują w ramach konfiguracji wysyłki dziennika transakcji. Czasami rejestrowanie całej kopii zapasowej dziennika może być uciążliwe w dzienniku błędów programu SQL Server i wymaga zarządzania. Trace Flag 3226 służy do blokowania takiego rejestrowania. W tym artykule pokażemy, jak można to zrobić.
Konfigurowanie wysyłki dziennika transakcji
Aby zademonstrować wartość tej flagi śledzenia, zaimplementujemy małą konfigurację wysyłania dziennika przy użyciu bazy danych SQL Server 2017 o nazwie Practice2017 . Nasza główna instancja to EPG-KIGIRI\I2017 i replikujemy tę bazę danych do instancji SQL Server 2019 EPG-KIGIRI\I2019 (Patrz rys. 2). Cały skrypt konfiguracyjny jest pokazany na Listingu 1.
Rys. 1 konfiguracja wysyłki dziennika na poziomie podstawowym
[rozwiń tytuł =”Kod „]
-- 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] ******
[/rozwiń]
Zadania tworzenia kopii zapasowych, kopiowania i przywracania są zaplanowane co pięć minut, a za każdym razem silnik bazy danych zapisuje również wpis w dzienniku błędów. Można to uznać za zbędne, ponieważ możemy łatwo śledzić kopie zapasowe dzienników za pomocą historii zadań SQL Agent.
Rys. 2 wpisy kopii zapasowej dziennika wysyłki w dzienniku błędów SQL
Włączanie flagi śledzenia 3226
Zazwyczaj możemy włączyć flagi śledzenia dla bieżącego połączenia lub globalnie. Możemy użyć T-SQL, aby włączyć flagi śledzenia lub zaimplementować flagę śledzenia w parametrach uruchamiania programu SQL Server. Zaleca się użycie podejścia z parametrami uruchamiania, aby włączyć flagi śledzenia, które chcesz zastosować do wystąpienia. Aby zastosować flagę śledzenia 3226 w parametrach uruchamiania programu SQL Server, wykonaj następujące kroki:
- Uruchom program SQL Server Configuration Manager jako administrator
Rys. 3 Uruchom SQL Server Configuration Manager jako administrator
- Kliknij prawym przyciskiem myszy żądaną instancję i kliknij opcję Właściwości .
Rys. 4 Otwórz właściwości instancji
- Wybierz Parametry uruchamiania
Rys. 5 parametrów uruchamiania
- W polu tekstowym oznaczonym Określ parametr startowy , wpisz –T3226 i kliknij Dodaj .
Rys. 6 Dodawanie flagi śledzenia 3226 jako parametru startowego
- Raz –T3226 został dodany do listy Istniejących parametrów , kliknij 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
Dziennik błędów programu SQL Server pokazuje, że flaga śledzenia jest włączona podczas uruchamiania. (patrz rys. 8)
Rys. 8 parametrów uruchamiania wskazanych w dzienniku błędów SQL Server
Wyświetlanie wyników
Po potwierdzeniu, że flaga śledzenia działa, odkrywamy, że dziennik błędów programu SQL Server nie zapisuje już kopii zapasowych dziennika związanych z wysyłaniem dziennika (lub jakiejkolwiek innej kopii zapasowej dziennika) w dzienniku błędów. Zwróć szczególną uwagę na rys. 9, który pokazuje, że wszystkie kopie zapasowe dziennika przechowywane w historii zadania kopii zapasowej nie są zapisywane w dzienniku błędów. Jest to zgodne z punktem, w którym włączyliśmy flagę śledzenia 3226 (około 20:15).
Rys. 9 Brak kopii zapasowych dziennika zapisanych w dzienniku błędów serwera SQL
Jeśli włączymy również flagę śledzenia 3226 w wystąpieniu dodatkowym EPG-KIGIRI\I2019, stwierdzamy, że operacje przywracania dziennika nie są już zapisywane w dzienniku błędów, ponieważ włączyliśmy flagę śledzenia 3226 w wystąpieniu pomocniczym około godziny 20:30. (patrz rys. 10)
Wniosek
W tym artykule pokazaliśmy, jak możemy użyć flagi śledzenia 3226, aby pominąć rejestrowanie kopii zapasowych dziennika transakcji w wystąpieniu podstawowym, a dziennik transakcji przywraca ustawienia wysyłania dziennika w wystąpieniu pomocniczym. Będzie to bardzo przydatne, aby uniknąć niepotrzebnego rejestrowania, które mogłoby „ukryć” prawdziwe problemy pojawiające się w dzienniku błędów.
Referencje
Flagi śledzenia DBCC TraceOn
