Einführung
Jeder Sicherungsvorgang in SQL Server wird in das SQL Server-Fehlerprotokoll geschrieben. Dies schließt Transaktionsprotokollsicherungen ein, selbst wenn sie als Teil einer Transaktionsprotokoll-Versandkonfiguration auftreten. Manchmal kann das Protokollieren der gesamten Protokollsicherung im SQL Server-Fehlerprotokoll störend sein und muss verwaltet werden. Das Ablaufverfolgungsflag 3226 wird verwendet, um eine solche Protokollierung zu unterdrücken, und wir werden in diesem Artikel zeigen, wie dies geschehen kann.
Konfigurieren des Transaktionsprotokollversands
Um den Wert dieses Ablaufverfolgungsflags zu demonstrieren, implementieren wir eine kleine Protokollversandkonfiguration mit einer SQL Server 2017-Datenbank namens Practice2017 . Unsere primäre Instanz ist EPG-KIGIRI\I2017 und wir replizieren diese Datenbank auf eine SQL Server 2019-Instanz EPG-KIGIRI\I2019 (Siehe Abb. 2). Das gesamte Konfigurationsskript ist in Listing 1 dargestellt.
Abb. 1 Protokollversandkonfiguration auf Primär
[expand title =”Code „]
-- 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] ******
[/expandieren]
Sicherungs-, Kopier- und Wiederherstellungsjobs werden planmäßig alle fünf Minuten ausgeführt, und wann immer dies geschieht, schreibt die Datenbank-Engine auch einen Eintrag in das Fehlerprotokoll. Dies kann als überflüssig angesehen werden, da wir die Log-Sicherungen mithilfe des Jobverlaufs des SQL-Agenten leicht verfolgen können.
Abb. 2 Sicherungseinträge für den Versand im SQL-Fehlerprotokoll protokollieren
Trace-Flag 3226 aktivieren
Normalerweise können wir Trace-Flags entweder für die aktuelle Verbindung oder global aktivieren. Wir können T-SQL verwenden, um Trace-Flags zu aktivieren oder das Trace-Flag in den SQL Server-Startparametern zu implementieren. Es wird empfohlen, dass Sie den Startparameteransatz verwenden, um Ablaufverfolgungsflags zu aktivieren, die Sie auf die Instanz anwenden möchten. Gehen Sie folgendermaßen vor, um das Ablaufverfolgungsflag 3226 in den SQL Server-Startparametern anzuwenden:
- Führen Sie den SQL Server-Konfigurationsmanager als Administrator aus
Abb. 3 Führen Sie den SQL Server-Konfigurations-Manager als Administrator aus
- Klicken Sie mit der rechten Maustaste auf die gewünschte Instanz und klicken Sie auf Eigenschaften .
Abb. 4 Öffnen Sie die Instanzeigenschaften
- Wählen Sie die Startparameter aus
Abb. 5 Startparameter
- Im Textfeld Startparameter angeben , geben Sie –T3226 ein und klicken Sie auf Hinzufügen .
Abb. 6 Ablaufverfolgungsflag 3226 als Startparameter hinzufügen
- Einmal –T3226 wurde zur Liste der vorhandenen Parameter hinzugefügt , klicken Sie auf 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
Das SQL Server-Fehlerprotokoll zeigt, dass das Ablaufverfolgungsflag beim Start aktiviert ist. (Siehe Abb. 8)
Abb. 8 Startparameter, die im SQL Server-Fehlerprotokoll angegeben sind
Anzeigen der Ergebnisse
Nachdem bestätigt wurde, dass das Ablaufverfolgungsflag funktioniert, stellen wir fest, dass das SQL Server-Fehlerprotokoll keine Protokollsicherungen mehr in das Fehlerprotokoll schreibt, die mit dem Protokollversand (oder einer anderen Protokollsicherung) verbunden sind. Achten Sie genau auf Abb. 9, die zeigt, dass alle im Sicherungsauftragsverlauf gespeicherten Protokollsicherungen nicht in das Fehlerprotokoll geschrieben werden. Dies stimmt mit dem Punkt überein, an dem wir das Ablaufverfolgungsflag 3226 aktiviert haben (etwa 20:15 Uhr).
Abb. 9 Keine Protokollsicherungen im SQL Server-Fehlerprotokoll aufgezeichnet
Wenn wir auch das Ablaufverfolgungsflag 3226 auf der sekundären Instanz EPG-KIGIRI\I2019, aktivieren Wir stellen fest, dass die Protokollwiederherstellungsvorgänge auch nicht mehr in das Fehlerprotokoll geschrieben werden, da wir das Ablaufverfolgungsflag 3226 auf der sekundären Instanz gegen 20:30 Uhr aktiviert haben. (Siehe Abb. 10)
Schlussfolgerung
In diesem Artikel haben wir gezeigt, wie wir das Ablaufverfolgungsflag 3226 verwenden können, um die Protokollierung von Transaktionsprotokollsicherungen auf der primären Instanz zu unterdrücken, und das Transaktionsprotokoll stellt die Protokollversandeinstellungen auf der sekundären Instanz wieder her. Dies ist sehr nützlich, um unnötige Protokollierung zu vermeiden, die echte Probleme „verbergen“ könnte, die im Fehlerprotokoll auftauchen.
Referenzen
DBCC TraceOn Trace-Flags
