Présentation
Chaque opération de sauvegarde dans SQL Server est écrite dans le journal des erreurs SQL Server. Cela inclut les sauvegardes du journal des transactions, même lorsqu'elles se produisent dans le cadre d'une configuration d'envoi du journal des transactions. Parfois, la journalisation de l'intégralité de la sauvegarde du journal peut être une nuisance dans le journal des erreurs SQL Server et doit être gérée. Trace Flag 3226 est utilisé pour supprimer une telle journalisation et nous montrerons comment cela peut être fait dans cet article.
Configuration de l'envoi des journaux de transactions
Afin de démontrer la valeur de cet indicateur de trace, nous allons implémenter une petite configuration d'envoi de journaux à l'aide d'une base de données SQL Server 2017 appelée Practice2017 . Notre instance principale est EPG-KIGIRI\I2017 et nous répliquons cette base de données sur une instance SQL Server 2019 EPG-KIGIRI\I2019 (Voir figure 2). Le script de configuration complet est présenté dans le Listing 1.
Fig. 1 Configuration de l'envoi de journaux sur le primaire
[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] ******
[/expand]
Les tâches de sauvegarde, de copie et de restauration sont planifiées pour s'exécuter toutes les cinq minutes, et chaque fois que cela se produit, le moteur de base de données écrit également une entrée dans le journal des erreurs. Cela peut être considéré comme superflu, car nous pouvons facilement suivre les sauvegardes des journaux à l'aide de l'historique des tâches de l'Agent SQL.
Fig. 2 entrées de sauvegarde d'envoi de journaux dans le journal des erreurs SQL
Activation de l'indicateur de trace 3226
En règle générale, nous pouvons activer les indicateurs de trace pour la connexion actuelle ou globalement. Nous pouvons utiliser T-SQL pour activer les indicateurs de trace ou implémenter l'indicateur de trace dans les paramètres de démarrage de SQL Server. Il est recommandé d'utiliser l'approche des paramètres de démarrage pour activer les indicateurs de trace que vous souhaitez appliquer à l'instance. Pour appliquer l'indicateur de trace 3226 dans les paramètres de démarrage de SQL Server, procédez comme suit :
- Exécuter le gestionnaire de configuration SQL Server en tant qu'administrateur
Fig. 3 Exécutez le gestionnaire de configuration SQL Server en tant qu'administrateur
- Faites un clic droit sur l'instance souhaitée et cliquez sur Propriétés .
Fig. 4 Ouvrir les propriétés de l'instance
- Sélectionnez les Paramètres de démarrage
Fig. 5 paramètres de démarrage
- Dans la zone de texte intitulée Spécifier un paramètre de démarrage , saisissez –T3226 et cliquez sur Ajouter .
Fig. 6 Ajout de l'indicateur de trace 3226 en tant que paramètre de démarrage
- Une fois –T3226 a été ajouté à la liste des paramètres existants , cliquez sur 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
Le journal des erreurs SQL Server indique que l'indicateur de trace est activé au démarrage. (Voir fig. 8)
Fig. 8 Paramètres de démarrage indiqués dans le journal des erreurs SQL Server
Affichage des résultats
Une fois qu'il est confirmé que l'indicateur de trace fonctionne, nous découvrons que le journal des erreurs SQL Server n'écrit plus les sauvegardes de journal associées à l'envoi de journaux (ou à toute autre sauvegarde de journal) dans le journal des erreurs. Portez une attention particulière à la Fig. 9 montrant que toutes les sauvegardes de journaux stockées dans l'historique des tâches de sauvegarde ne sont pas écrites dans le journal des erreurs. Cela correspond au point auquel nous avons activé l'indicateur de trace 3226 (environ 20h15).
Fig. 9 Aucune sauvegarde de journal enregistrée dans le journal des erreurs SQL Server
Si nous activons également l'indicateur de trace 3226 sur l'instance secondaire EPG-KIGIRI\I2019, nous constatons que les opérations de restauration du journal ne sont plus écrites dans le journal des erreurs puisque nous avons activé l'indicateur de trace 3226 sur l'instance secondaire vers 20h30. (Voir fig. 10)
Conclusion
Dans cet article, nous avons montré comment nous pouvons utiliser l'indicateur de trace 3226 pour supprimer la journalisation des sauvegardes du journal des transactions sur l'instance principale, et le journal des transactions restaure les paramètres d'envoi de journaux sur l'instance secondaire. Cela sera très utile pour éviter une journalisation inutile qui pourrait "masquer" les vrais problèmes apparaissant dans le journal des erreurs.
Références
Drapeaux de suivi DBCC TraceOn
