Giới thiệu
Mọi thao tác sao lưu trong SQL Server đều được ghi vào nhật ký Lỗi SQL Server. Điều này bao gồm Sao lưu nhật ký giao dịch ngay cả khi chúng xảy ra như một phần của Cấu hình vận chuyển nhật ký giao dịch. Đôi khi việc ghi lại toàn bộ Bản sao lưu Nhật ký có thể gây phiền toái trong Nhật ký Lỗi SQL Server và cần được quản lý. Cờ theo dõi 3226 được sử dụng để ngăn chặn việc ghi nhật ký như vậy và chúng tôi sẽ trình bày cách thực hiện điều này trong bài viết này.
Định cấu hình Vận chuyển nhật ký giao dịch
Để chứng minh giá trị của cờ theo dõi này, chúng tôi sẽ triển khai cấu hình vận chuyển nhật ký nhỏ bằng cách sử dụng cơ sở dữ liệu SQL Server 2017 có tên là Practice2017 . Phiên bản chính của chúng tôi là EPG-KIGIRI \ I2017 và chúng tôi đang sao chép cơ sở dữ liệu này sang phiên bản SQL Server 2019 EPG-KIGIRI \ I2019 (Xem Hình 2). Toàn bộ tập lệnh cấu hình được hiển thị trong Liệt kê 1.
Hình. Cấu hình 1 nhật ký vận chuyển trên chính
[expand title =” Mã “]
-- 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] ******
[/ mở rộng]
Các công việc sao lưu, sao chép và khôi phục được lên lịch chạy năm phút một lần và bất cứ khi nào điều này xảy ra, công cụ cơ sở dữ liệu cũng ghi một mục vào nhật ký lỗi. Điều này có thể được coi là thừa, vì chúng tôi có thể dễ dàng theo dõi các bản sao lưu nhật ký bằng lịch sử công việc SQL Agent.
Hình. 2 Nhật ký Vận chuyển Các mục nhập sao lưu trong Nhật ký Lỗi SQL
Bật cờ theo dõi 3226
Thông thường, chúng tôi có thể bật cờ theo dõi cho kết nối hiện tại hoặc trên toàn cầu. Chúng ta có thể sử dụng T-SQL để kích hoạt cờ theo dõi hoặc triển khai cờ theo dõi trong các tham số khởi động SQL Server. Bạn nên sử dụng phương pháp tham số khởi động để bật cờ theo dõi mà bạn muốn áp dụng cho phiên bản. Để áp dụng cờ theo dõi 3226 trong tham số khởi động SQL Server, hãy làm theo các bước sau:
- Chạy Trình quản lý cấu hình SQL Server với tư cách là Quản trị viên
Hình. 3 Chạy Trình quản lý cấu hình SQL Server với tư cách là Quản trị viên
- Nhấp chuột phải vào phiên bản mong muốn và nhấp vào Thuộc tính .
Hình. 4 Thuộc tính Phiên bản Mở
- Chọn Tham số Khởi động
Hình. 5 Tham số Khởi động
- Trong hộp văn bản có nhãn Chỉ định tham số khởi động , nhập –T3226 và nhấp vào Thêm .
Hình. 6 Thêm cờ theo dõi 3226 làm thông số khởi động
- Một lần –T3226 đã được thêm vào danh sách Thông số hiện có , nhấp vào 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
Nhật ký lỗi SQL Server cho thấy rằng cờ theo dõi được bật khi khởi động. (Xem Hình 8)
Hình. 8 Tham số khởi động được chỉ ra trong nhật ký lỗi SQL Server
Xem kết quả
Sau khi xác nhận rằng cờ theo dõi đang hoạt động, chúng tôi phát hiện ra rằng nhật ký lỗi SQL Server không còn ghi các bản sao lưu nhật ký liên quan đến vận chuyển nhật ký (hoặc bất kỳ sao lưu nhật ký nào khác) vào nhật ký lỗi. Hãy chú ý đến Hình 9 cho thấy rằng tất cả các bản sao lưu nhật ký được lưu trữ trong lịch sử công việc sao lưu không được ghi vào nhật ký lỗi. Điều này phù hợp với điểm mà chúng tôi đã bật cờ theo dõi 3226 (khoảng 8:15 tối).
Hình. 9 Không có bản sao lưu nhật ký nào được ghi trong nhật ký lỗi máy chủ SQL
Nếu chúng tôi cũng bật cờ theo dõi 3226 trên phiên bản phụ EPG-KIGIRI \ I2019, chúng tôi thấy rằng các hoạt động khôi phục nhật ký cũng không còn được ghi vào nhật ký lỗi vì chúng tôi đã bật cờ theo dõi 3226 trên phiên bản phụ vào khoảng 8:30 tối. (Xem Hình 10)
Kết luận
Trong bài viết này, chúng tôi đã trình bày cách chúng tôi có thể sử dụng cờ theo dõi 3226 để ngăn ghi nhật ký sao lưu nhật ký giao dịch trên phiên bản chính và nhật ký giao dịch khôi phục cài đặt vận chuyển nhật ký trên phiên bản phụ. Điều này sẽ rất hữu ích để tránh việc ghi nhật ký không cần thiết có thể “ẩn” các vấn đề thực sự xuất hiện trong nhật ký lỗi.
Tài liệu tham khảo
Các cờ theo dõi DBCC theo dõi
