sql >> Base de Datos >  >> RDS >> Database

Uso de Trace Flag 3226 para suprimir el registro de copia de seguridad del registro

Introducción

Cada operación de copia de seguridad en SQL Server se escribe en el registro de errores de SQL Server. Esto incluye las copias de seguridad del registro de transacciones incluso cuando se producen como parte de una configuración de envío del registro de transacciones. A veces, registrar toda la copia de seguridad del registro puede ser una molestia en el registro de errores de SQL Server y debe administrarse. Trace Flag 3226 se usa para suprimir dicho registro y demostraremos cómo se puede hacer esto en este artículo.

Configuración del envío del registro de transacciones

Para demostrar el valor de esta marca de seguimiento, implementaremos una pequeña configuración de envío de registros utilizando una base de datos de SQL Server 2017 llamada Practice2017 . Nuestra instancia principal es EPG-KIGIRI\I2017 y estamos replicando esta base de datos a una instancia de SQL Server 2019 EPG-KIGIRI\I2019 (Ver Fig. 2). El script de configuración completo se muestra en el Listado 1.

fig. 1 Configuración de envío de registros en principal

[expandir título =”Código “]

-- 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] ******

[/expandir]

Los trabajos de copia de seguridad, copia y restauración están programados para ejecutarse cada cinco minutos y, cada vez que esto sucede, el motor de la base de datos también escribe una entrada en el registro de errores. Esto puede considerarse superfluo, ya que podemos rastrear fácilmente las copias de seguridad de registros utilizando el historial de trabajos del Agente SQL.

fig. 2 Registro de entradas de copia de seguridad de envío en el registro de errores de SQL

Habilitación del indicador de seguimiento 3226

Por lo general, podemos habilitar indicadores de rastreo para la conexión actual o globalmente. Podemos usar T-SQL para habilitar indicadores de seguimiento o implementar el indicador de seguimiento en los parámetros de inicio de SQL Server. Se recomienda que utilice el enfoque de parámetros de inicio para habilitar las marcas de rastreo que desea aplicar a la instancia. Para aplicar el indicador de seguimiento 3226 en los parámetros de inicio de SQL Server, siga estos pasos:

  1. Ejecute el Administrador de configuración de SQL Server como Administrador

fig. 3 Ejecute el Administrador de configuración de SQL Server como administrador

  1. Haga clic derecho en la instancia deseada y haga clic en Propiedades .

fig. 4 Abrir propiedades de instancia

  1. Seleccione los Parámetros de inicio

fig. 5 parámetros de inicio

  1. En el cuadro de texto etiquetado como Especifique un parámetro de inicio , escriba –T3226 y haga clic en Agregar .

fig. 6 Adición de Trace Flag 3226 como parámetro de inicio

  1. Una vez –T3226 se ha agregado a la lista de Parámetros existentes , haga clic en Aceptar .

-- 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

El registro de errores de SQL Server muestra que el indicador de seguimiento está habilitado en el inicio. (Ver Fig. 8)

fig. 8 Parámetros de inicio indicados en el registro de errores de SQL Server

Ver los resultados

Una vez que se confirma que el indicador de seguimiento funciona, descubrimos que el registro de errores de SQL Server ya no escribe copias de seguridad de registros asociadas con el envío de registros (o cualquier otra copia de seguridad de registros) en el registro de errores. Preste mucha atención a la Fig. 9 que muestra que todas las copias de seguridad de registros almacenadas en el historial de trabajos de copia de seguridad no se escriben en el registro de errores. Esto se alinea con el punto en el que habilitamos el indicador de rastreo 3226 (alrededor de las 8:15 p. m.).

fig. 9 No hay copias de seguridad registradas en el registro de errores de SQL Server

Si también habilitamos el indicador de rastreo 3226 en la instancia secundaria EPG-KIGIRI\I2019, encontramos que las operaciones de restauración del registro ya no se escriben en el registro de errores desde que habilitamos el indicador de seguimiento 3226 en la instancia secundaria aproximadamente a las 8:30 p.m. (Ver Fig. 10)

Conclusión

En este artículo, hemos demostrado cómo podemos usar el indicador de seguimiento 3226 para suprimir el registro de las copias de seguridad del registro de transacciones en la instancia principal, y el registro de transacciones restaura la configuración de envío de registros en la instancia secundaria. Esto será muy útil para evitar registros innecesarios que podrían "ocultar" problemas reales que aparecen en el registro de errores.

Referencias

Indicadores de rastreo DBCC TraceOn