Pengantar
Setiap operasi pencadangan di SQL Server ditulis ke log galat SQL Server. Ini termasuk Cadangan Log Transaksi meskipun terjadi sebagai bagian dari Konfigurasi Pengiriman Log Transaksi. Terkadang mencatat seluruh Cadangan Log dapat menjadi gangguan di Log Kesalahan SQL Server dan perlu dikelola. Trace Flag 3226 digunakan untuk menekan logging tersebut dan kami akan menunjukkan bagaimana hal ini dapat dilakukan dalam artikel ini.
Mengonfigurasi Pengiriman Log Transaksi
Untuk mendemonstrasikan nilai tanda pelacakan ini, kami akan menerapkan konfigurasi pengiriman log kecil menggunakan database SQL Server 2017 yang disebut Practice2017 . Instance utama kami adalah EPG-KIGIRI\I2017 dan kami mereplikasi database ini ke instance SQL Server 2019 EPG-KIGIRI\I2019 (Lihat Gambar 2). Seluruh skrip konfigurasi ditampilkan di Listing 1.
Gbr. 1 Log Konfigurasi Pengiriman di Utama
[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] ******
[/expand]
Pekerjaan pencadangan, penyalinan, dan pemulihan dijadwalkan untuk dijalankan setiap lima menit, dan kapan pun ini terjadi, mesin basis data juga menulis entri di log kesalahan. Ini mungkin dianggap berlebihan, karena kami dapat dengan mudah melacak cadangan log menggunakan riwayat pekerjaan Agen SQL.
Gbr. 2 Log Entri Cadangan Pengiriman di Log Kesalahan SQL
Mengaktifkan Tanda Pelacakan 3226
Biasanya, kami dapat mengaktifkan tanda pelacakan baik untuk koneksi saat ini atau secara global. Kita dapat menggunakan T-SQL untuk mengaktifkan flag trace atau mengimplementasikan flag trace di parameter startup SQL Server. Sebaiknya Anda menggunakan pendekatan parameter startup untuk mengaktifkan tanda pelacakan yang ingin Anda terapkan ke instans. Untuk menerapkan bendera pelacakan 3226 di parameter startup SQL Server, ikuti langkah-langkah berikut:
- Jalankan SQL Server Configuration Manager sebagai Administrator
Gbr. 3 Jalankan SQL Server Configuration Manager sebagai Administrator
- Klik kanan instance yang diinginkan dan klik Properties .
Gbr. 4 Buka Properti Instance
- Pilih Parameter Startup
Gbr. 5 Parameter Startup
- Dalam kotak teks berlabel Tentukan parameter startup , ketik –T3226 dan klik Tambah .
Gbr. 6 Menambahkan Trace Flag 3226 sebagai Parameter Startup
- Sekali –T3226 telah ditambahkan ke daftar Parameter yang Ada , klik Oke .
-- 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
Log galat SQL Server menunjukkan bahwa bendera pelacakan diaktifkan saat startup. (Lihat Gambar 8)
Gbr. 8 Parameter Startup Ditunjukkan dalam log kesalahan SQL Server
Melihat Hasil
Setelah dikonfirmasi bahwa bendera pelacakan berfungsi, kami menemukan bahwa log kesalahan SQL Server tidak lagi menulis cadangan log yang terkait dengan pengiriman log (atau cadangan log lainnya) ke log kesalahan. Perhatikan baik-baik Gambar 9 yang menunjukkan bahwa semua cadangan log yang disimpan dalam riwayat pekerjaan pencadangan tidak ditulis ke log kesalahan. Ini sejalan dengan titik di mana kami mengaktifkan tanda jejak 3226 (sekitar 20:15).
Gbr. 9 Tidak Ada Cadangan Log yang Tercatat di Log Kesalahan SQL Server
Jika kami juga mengaktifkan tanda pelacakan 3226 pada instance sekunder EPG-KIGIRI\I2019, kami menemukan bahwa operasi pemulihan log juga tidak lagi ditulis ke log kesalahan karena kami mengaktifkan tanda pelacakan 3226 pada instans sekunder sekitar pukul 20:30. (Lihat Gambar 10)
Kesimpulan
Dalam artikel ini, kami telah menunjukkan bagaimana kami dapat menggunakan bendera pelacakan 3226 untuk menekan pencatatan log cadangan transaksi pada instans utama, dan log transaksi memulihkan pengaturan pengiriman log pada instans sekunder. Ini akan sangat berguna untuk menghindari pencatatan yang tidak perlu yang dapat “menyembunyikan” masalah nyata yang muncul di log kesalahan.
Referensi
Tanda Pelacakan DBCC TraceOn
