Introduzione
Ogni operazione di backup in SQL Server viene scritta nel log degli errori di SQL Server. Ciò include i backup del registro delle transazioni anche quando si verificano come parte di una configurazione di spedizione del registro delle transazioni. A volte la registrazione dell'intero backup del registro può essere una seccatura nel registro degli errori di SQL Server e deve essere gestita. Il flag di traccia 3226 viene utilizzato per eliminare tale registrazione e in questo articolo dimostreremo come farlo.
Configurazione della spedizione del registro delle transazioni
Per dimostrare il valore di questo flag di traccia, implementeremo una piccola configurazione di log shipping utilizzando un database SQL Server 2017 chiamato Pratica2017 . La nostra istanza principale è EPG-KIGIRI\I2017 e stiamo replicando questo database su un'istanza di SQL Server 2019 EPG-KIGIRI\I2019 (Vedere Fig. 2). L'intero script di configurazione è mostrato nel Listato 1.
Fig. 1 Configurazione Log Shipping su Primario
[expand title =”Codice “]
-- 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] ******
[/espandi]
I processi di backup, copia e ripristino vengono eseguiti ogni cinque minuti e, ogni volta che ciò si verifica, il motore di database scrive anche una voce nel registro degli errori. Questo può essere considerato superfluo, poiché possiamo facilmente tenere traccia dei backup dei log utilizzando la cronologia dei processi di SQL Agent.
Fig. 2 Registra le voci del backup di spedizione nel registro degli errori SQL
Abilitazione del flag di traccia 3226
In genere, possiamo abilitare i flag di traccia sia per la connessione corrente che a livello globale. Possiamo usare T-SQL per abilitare i flag di traccia o implementare il flag di traccia nei parametri di avvio di SQL ServerSQL Server. Si consiglia di utilizzare l'approccio dei parametri di avvio per abilitare i flag di traccia che si desidera applicare all'istanza. Per applicare il flag di traccia 3226 nei parametri di avvio di SQL Server, attenersi alla seguente procedura:
- Esegui SQL Server Configuration Manager come amministratore
Fig. 3 Eseguire SQL Server Configuration Manager come amministratore
- Fare clic con il pulsante destro del mouse sull'istanza desiderata e fare clic su Proprietà .
Fig. 4 Apri Proprietà istanza
- Seleziona i Parametri di avvio
Fig. 5 Parametri di avvio
- Nella casella di testo Specifica un parametro di avvio , digita –T3226 e fai clic su Aggiungi .
Fig. 6 Aggiunta del flag di traccia 3226 come parametro di avvio
- Una volta –T3226 è stato aggiunto all'elenco dei Parametri esistenti , fai clic su 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
Il log degli errori di SQL Server mostra che il flag di traccia è abilitato all'avvio. (Vedi Fig. 8)
Fig. 8 Parametri di avvio indicati nel log degli errori di SQL Server
Visualizzazione dei risultati
Una volta confermato che il flag di traccia funziona, scopriamo che il log degli errori di SQL Server non scrive più i backup dei log associati al log shipping (o qualsiasi altro backup del log) nel log degli errori. Prestare particolare attenzione alla Fig. 9 che mostra che tutti i backup dei log archiviati nella cronologia dei processi di backup non vengono scritti nel log degli errori. Questo è in linea con il punto in cui abbiamo abilitato il flag di traccia 3226 (circa 20:15).
Fig. 9 Nessun backup del registro registrato nel registro degli errori di SQL Server
Se abilitiamo anche il flag di traccia 3226 sull'istanza secondaria EPG-KIGIRI\I2019, scopriamo che anche le operazioni di ripristino del registro non vengono più scritte nel registro degli errori poiché abbiamo abilitato il flag di traccia 3226 sull'istanza secondaria verso le 20:30 circa. (Vedi Fig. 10)
Conclusione
In questo articolo, abbiamo dimostrato come utilizzare il flag di traccia 3226 per sopprimere la registrazione dei backup del registro delle transazioni nell'istanza primaria e il registro delle transazioni ripristina le impostazioni di distribuzione del registro nell'istanza secondaria. Ciò sarà molto utile per evitare registrazioni non necessarie che potrebbero "nascondere" problemi reali che si verificano nel registro degli errori.
Riferimenti
Flag di traccia DBCC TraceOn
