Introduktion
Hver backup-handling i SQL Server skrives til SQL Server-fejlloggen. Dette inkluderer sikkerhedskopiering af transaktionslog, selv når de forekommer som en del af en forsendelseskonfiguration for transaktionslog. Nogle gange kan logning af hele Log Backup være en gene i SQL Server Error Log og skal administreres. Trace Flag 3226 bruges til at undertrykke sådan logning, og vi vil demonstrere, hvordan dette kan gøres i denne artikel.
Konfiguration af transaktionslogforsendelse
For at demonstrere værdien af dette sporingsflag vil vi implementere en lille logforsendelseskonfiguration ved hjælp af en SQL Server 2017-database kaldet Practice2017 . Vores primære instans er EPG-KIGIRI\I2017 og vi replikerer denne database til en SQL Server 2019-instans EPG-KIGIRI\I2019 (Se fig. 2). Hele konfigurationsscriptet er vist i liste 1.
Fig. 1 Log forsendelseskonfiguration på Primær
[expand title =”Kode “]
-- 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] ******
[/udvid]
Sikkerhedskopierings-, kopierings- og gendannelsesjob er planlagt til at køre hvert femte minut, og hver gang dette sker, skriver databasemotoren også en post i fejlloggen. Dette kan betragtes som overflødigt, da vi nemt kan spore log backups ved hjælp af SQL Agent-jobhistorikken.
Fig. 2 Log forsendelsessikkerhedskopieringsposter i SQL-fejllog
Aktivering af sporingsflag 3226
Typisk kan vi aktivere sporingsflag enten for den aktuelle forbindelse eller globalt. Vi kan bruge T-SQL til at aktivere sporingsflag eller implementere sporingsflaget i SQL Server-startparametrene. Det anbefales, at du bruger opstartsparametre-tilgangen til at aktivere sporingsflag, du vil anvende på forekomsten. Følg disse trin for at anvende sporingsflaget 3226 i SQL Server-startparametrene:
- Kør SQL Server Configuration Manager som Administrator
Fig. 3 Kør SQL Server Configuration Manager som administrator
- Højreklik på den ønskede forekomst, og klik på Egenskaber .
Fig. 4 Åbn Instance Properties
- Vælg Opstartsparametre
Fig. 5 opstartsparametre
- I tekstboksen mærket Angiv en startparameter , skriv –T3226 og klik på Tilføj .
Fig. 6 Tilføjelse af sporingsflag 3226 som en startparameter
- En gang –T3226 er blevet tilføjet til listen over Eksisterende parametre , klik på 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-fejlloggen viser, at sporingsflaget er aktiveret ved opstart. (Se fig. 8)
Fig. 8 Opstartsparametre angivet i SQL Server-fejlloggen
Visning af resultaterne
Når det er bekræftet, at sporingsflaget virker, opdager vi, at SQL Server-fejlloggen ikke længere skriver log-backups forbundet med logforsendelse (eller enhver anden log-backup) til fejlloggen. Vær meget opmærksom på Fig. 9, der viser, at alle log-backups, der er gemt i backupjobhistorikken, ikke skrives til fejlloggen. Dette stemmer overens med det punkt, hvor vi aktiverede sporingsflag 3226 (ca. 20:15).
Fig. 9 Ingen log-sikkerhedskopier registreret i SQL Server-fejllog
Hvis vi også aktiverer sporingsflag 3226 på den sekundære instans EPG-KIGIRI\I2019, vi opdager, at loggendannelsesoperationerne heller ikke længere skrives til fejlloggen, da vi aktiverede sporingsflag 3226 på den sekundære instans omkring kl. 20.30. (Se fig. 10)
Konklusion
I denne artikel har vi demonstreret, hvordan vi kan bruge sporingsflag 3226 til at undertrykke logning af transaktionslogsikkerhedskopier på den primære instans, og transaktionsloggen gendanner logforsendelsesindstillingerne på den sekundære instans. Dette vil være meget nyttigt for at undgå unødvendig logning, der kunne "skjule" reelle problemer, der dukker op i fejlloggen.
Referencer
DBCC TraceOn Trace Flags