Sqlserver
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Sqlserver

Phục hồi cơ sở dữ liệu được tăng tốc trong SQL Server 2019

Tổng quan về Khôi phục truyền thống

Như với tất cả các hệ thống cơ sở dữ liệu quan hệ, SQL Server đảm bảo độ bền của dữ liệu bằng cách thực hiện khôi phục sự cố. Độ bền trong từ viết tắt ACID đề cập đến đặc điểm của các giao dịch trong cơ sở dữ liệu quan hệ có nghĩa là chúng ta có thể yên tâm rằng nếu cơ sở dữ liệu bị lỗi đột ngột, dữ liệu của chúng ta vẫn an toàn.

SQL Server thực hiện khả năng này bằng cách sử dụng nhật ký giao dịch. Các thay đổi được thực hiện bởi tất cả các Thao tác thao tác dữ liệu trong SQL Server được ghi lại trong nhật ký giao dịch trước khi được áp dụng cho các tệp dữ liệu (thông qua quy trình điểm kiểm tra) trong trường hợp cần khôi phục hoặc chuyển tiếp.

Quá trình khôi phục sự cố ba giai đoạn trong SQL Server như sau:

  • Phân tích - SQL Server đọc nhật ký giao dịch từ điểm kiểm tra mới nhất đến cuối nhật ký giao dịch

  • Làm lại - SQL Server phát lại nhật ký từ giao dịch không được cam kết cũ nhất đến cuối nhật ký

  • Hoàn tác - SQL Server đọc nhật ký từ cuối nhật ký đến giao dịch không được cam kết cũ nhất và hoàn nguyên tất cả các giao dịch đang hoạt động trong sự cố

Những DBA có kinh nghiệm sẽ có lúc nào đó hay thời điểm khác trong sự nghiệp của họ phải trải qua kinh nghiệm thất vọng khi chờ đợi quá trình khôi phục sự cố được hoàn thành trên một cơ sở dữ liệu rất lớn một cách bất lực. ROLLBACK giao dịch sử dụng một cơ chế tương tự như quá trình khôi phục sự cố. Microsoft đã nâng cao quá trình khôi phục đáng kể trong SQL Server 2019.

Phục hồi cơ sở dữ liệu được tăng tốc

Phục hồi cơ sở dữ liệu được tăng tốc là một tính năng mới dựa trên việc lập phiên bản giúp tăng đáng kể tốc độ khôi phục trong trường hợp ROLLBACK hoặc khôi phục sau sự cố.

Trong SQL Server 2019, ba cơ chế mới trong công cụ SQL Server sửa đổi cách xử lý quá trình khôi phục và giảm hiệu quả thời gian cần thiết để thực hiện khôi phục / chuyển tiếp.

  • Cửa hàng phiên bản ổn định (PVS) - Chụp các phiên bản hàng trong cơ sở dữ liệu được đề cập. Kho lưu trữ phiên bản liên tục có thể được xác định trong một nhóm tệp riêng biệt vì lý do hiệu suất hoặc kích thước

  • Hoàn nguyên lôgic - Sử dụng các phiên bản hàng được lưu trữ trong PVS để thực hiện khôi phục khi yêu cầu khôi phục cho một giao dịch cụ thể hoặc khi giai đoạn hoàn tác của khôi phục sự cố được gọi.

  • sLog - Điều này có thể là viết tắt của thứ cấp nhật ký . Đó là luồng nhật ký trong bộ nhớ được sử dụng để ghi lại các hoạt động không thể tạo phiên bản. Khi ADR được bật trong cơ sở dữ liệu, sLog luôn được xây dựng lại trong giai đoạn phân tích khôi phục sự cố. Trong quá trình làm lại giai đoạn, sLog được sử dụng thay vì nhật ký giao dịch thực tế, làm cho quá trình nhanh hơn vì nó nằm trong bộ nhớ và chứa ít giao dịch hơn. Quy trình khôi phục truyền thống xử lý các giao dịch từ điểm kiểm tra cuối cùng. SLog cũng được sử dụng trong quá trình hoàn tác giai đoạn.

  • Dọn dẹp hơn - Loại bỏ các phiên bản hàng không cần thiết khỏi PVS. Microsoft cũng cung cấp một quy trình được lưu trữ để buộc dọn dẹp các phiên bản hàng không cần thiết theo cách thủ công. 

-- LISTING 1: INVOKE THE BACKGROUND CLEANER

USE TSQLV4_ADR
GO
EXECUTE sys.sp_persistent_version_cleanup;

USE master
GO
EXECUTE master.sys.sp_persistent_version_cleanup 'TSQLV4_ADR';

Phục hồi Cơ sở dữ liệu Tăng tốc được TẮT theo Mặc định

Việc ADR bị tắt trong SQL Server 2019 theo mặc định có thể gây ngạc nhiên cho một số DBA vì nó có vẻ là một tính năng tuyệt vời như vậy. ADR sử dụng lập phiên bản trong cơ sở dữ liệu người dùng mà nó được kích hoạt. Điều này có thể ảnh hưởng đáng kể đến kích thước cơ sở dữ liệu. Ngoài ra, bạn có thể cần phải lập kế hoạch cho sự phát triển cơ sở dữ liệu cũng như vị trí có thể có của PVS để đảm bảo hiệu suất tốt nếu ADR được bật. Vì vậy, việc cố ý bật chức năng này là rất hợp lý.

Thử nghiệm:Giai đoạn Chuẩn bị

Chúng tôi đã thiết lập một thử nghiệm để khám phá tính năng mới và xem tác động của ADR đến kích thước của nhật ký giao dịch cũng như tốc độ của ROLLBACK. Trong thử nghiệm của chúng tôi, chúng tôi tạo hai cơ sở dữ liệu giống hệt nhau bằng cách sử dụng một bộ sao lưu duy nhất và sau đó chúng tôi chỉ bật ADR trên một trong những cơ sở dữ liệu này. Liệt kê 2 cho thấy các giai đoạn chuẩn bị cho nhiệm vụ.

[expand title =”Mã”] 

-- LISTING 2: PREPARE THE DATABASES AND CONFIGURE ADR

-- 2a. Backup a sample database and restore as two identical databases

BACKUP DATABASE TSQLV4 TO DISK='TSQLV4.BAK' WITH COMPRESSION;

-- Restore Database TSQLV4_NOADR (ADR will not be enabled)
RESTORE DATABASE TSQLV4_NOADR FROM DISK='TSQLV4.BAK' WITH 
MOVE 'TSQLV4' TO 'C:\MSSQL\DATA\TSQLV4_NOADR.MDF',
MOVE 'TSQLV4_log' TO 'E:\MSSQL\LOG\TSQLV4_NOADR_LOG.LDF';

-- Restore Database TSQLV4_ADR (ADR will be enabled)
RESTORE DATABASE TSQLV4_ADR FROM DISK='TSQLV4.BAK' WITH 
MOVE 'TSQLV4' TO 'C:\MSSQL\DATA\TSQLV4_ADR.MDF',
MOVE 'TSQLV4_log' TO 'E:\MSSQL\LOG\TSQLV4_ADR_LOG.LDF';

-- 2b. Enable ADR in TSQLV4_ADR
USE [master]
GO

-- First create a separate filegroup and add a file to the filegroup
ALTER DATABASE [TSQLV4_ADR] ADD FILEGROUP [ADR_FG];
ALTER DATABASE [TSQLV4_ADR] ADD FILE ( NAME = N'TSQLV4_ADR01', FILENAME = N'C:\MSSQL\Data\TSQLV4_ADR01.ndf' , 
SIZE = 8192KB , FILEGROWTH = 65536KB ) TO FILEGROUP [ADR_FG]
GO

-- Enable ADR
ALTER DATABASE TSQLV4_ADR SET ACCELERATED_DATABASE_RECOVERY = ON (PERSISTENT_VERSION_STORE_FILEGROUP = ADR_FG);
GO

-- 2c. Check if all ADR is enabled as planned
SELECT name
, compatibility_level
, snapshot_isolation_state_desc
, recovery_model_desc
, target_recovery_time_in_seconds
, is_accelerated_database_recovery_on FROM SYS.DATABASES
WHERE name LIKE 'TSQLV4_%';


-- 2d. Check sizes of all files in the databases
SELECT DB_NAME(database_id) AS database_name
, name AS file_name
, physical_name
, (size * 8)/1024 AS [size (MB)]
, type_desc
FROM SYS.master_files
WHERE DB_NAME(database_id) LIKE 'TSQLV4_%';


-- 2e. Check size of log used

CREATE TABLE ##LogSpaceUsage (database_name VARCHAR(50)
, database_id INT, total_log_size_in_bytes BIGINT
, used_log_space_in_bytes BIGINT
, used_log_space_in_percent BIGINT
, log_space_in_bytes_since_last_backup BIGINT)

INSERT INTO ##LogSpaceUsage
EXEC sp_MSforeachdb @command1='
IF ''?'' LIKE ("TSQLV4_%")
SELECT DB_NAME(database_id), * FROM ?.SYS.dm_db_log_space_usage;'

SELECT * FROM ##LogSpaceUsage;

DROP TABLE ##LogSpaceUsage;

[/ mở rộng]

Hình 1 cho thấy đầu ra của câu lệnh SQL trong Liệt kê 2 phần 2c. Chúng tôi cũng nắm bắt được kích thước của các tệp cơ sở dữ liệu và việc sử dụng tệp nhật ký giao dịch. (xem Hình 3).

Hình. 1 Xác nhận ADR được định cấu hình

Hình. 2 Xem lại kích thước tệp dữ liệu cơ sở dữ liệu

Hình. 3 Kiểm tra kích thước nhật ký được sử dụng cho cả hai cơ sở dữ liệu

Thử nghiệm:Giai đoạn Thực thi

Khi chúng tôi đã nắm bắt được các chi tiết cần tiếp tục, sau đó chúng tôi thực thi mã SQL từ Danh sách 3 và 4 theo từng giai đoạn. Hai danh sách tương đương nhau, nhưng chúng tôi đang thực thi chúng trên hai cơ sở dữ liệu giống hệt nhau một cách riêng biệt. Đầu tiên, chúng ta thực hiện CHÈN (Liệt kê 3, 3a), sau đó chúng ta thực hiện XÓA (Liệt kê 3, 3b) mà sau đó chúng ta sẽ quay trở lại. Lưu ý rằng trong cả INSERT và DELETE, chúng ta đã gói gọn các thao tác trong các giao dịch. Ngoài ra, hãy lưu ý rằng INSERT được thực hiện 50 lần. Ở mỗi giai đoạn thực thi, tức là từ 3a, 3b và 3c, chúng tôi nắm bắt việc sử dụng nhật ký giao dịch với sự trợ giúp của mã trong Liệt kê 2,2e. Điều này cũng tương tự đối với các phần 4a, 4b và 4c. 

-- LISTING 3: EXECUTE DML IN TSQLV4_NOADR DATABASE

-- 3a. Execute INSERT Statement in TSQLV4_NOADR Database

USE TSQLV4_NOADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
SELECT * INTO [Sales].[OrderDetails_noadr] FROM [Sales].[OrderDetails];
GO
INSERT INTO [Sales].[OrderDetails_noadr] 
SELECT * FROM [Sales].[OrderDetails];
GO 50

COMMIT;

-- 3b. Execute DELETE in TSQLV4_NOADR Database

USE TSQLV4_NOADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
DELETE FROM [Sales].[OrderDetails_noadr]
GO

-- 3c. Perform Rollback and Capture Time
ROLLBACK;

Hình. 4 và 5 cho chúng ta thấy rằng thao tác CHỌN INTO mất thêm 6 mili giây trong cơ sở dữ liệu TSQLV4_ADR nơi chúng tôi đã bật Phục hồi cơ sở dữ liệu được tăng tốc. Chúng tôi cũng thấy trong Hình 6 rằng chúng tôi có mức sử dụng nhật ký giao dịch lớn hơn trong cơ sở dữ liệu TSQLV4_ADR. Tôi đặc biệt ngạc nhiên về điều này, vì vậy tôi đã lặp lại thử nghiệm nhiều lần để đảm bảo rằng tôi nhận được kết quả này một cách nhất quán.

Hình. 4 Chèn thời gian thực thi cho TSQLV4_NOADR

Hình. 5 Chèn thời gian thực thi cho TSQLV4_ADR

Hình. 6 Sử dụng Nhật ký Giao dịch Sau khi Chèn 

-- LISTING 4: EXECUTE DML IN TSQLV4_ADR DATABASE

-- 4a. Execute INSERT Statement in TSQLV4_ADR Database

USE TSQLV4_ADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
SELECT * INTO [Sales].[OrderDetails_adr] FROM [Sales].[OrderDetails];
GO
INSERT INTO [Sales].[OrderDetails_adr] 
SELECT * FROM [Sales].[OrderDetails];
GO 50

COMMIT;


-- 4b. Execute DELETE in TSQLV4_ADR Database

USE TSQLV4_ADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
DELETE FROM [Sales].[OrderDetails_adr]
GO

-- 4c. Perform Rollback and Capture Time
ROLLBACK;

Hình. 7 và 8 cho chúng tôi thấy rằng thao tác DELETE mất nhiều thời gian hơn đáng kể để hoàn thành trong cơ sở dữ liệu TSQLV4_ADR nơi chúng tôi đã bật Phục hồi cơ sở dữ liệu được tăng tốc mặc dù số hàng như nhau đã bị xóa trong cả hai cơ sở dữ liệu. Tuy nhiên, khoảng thời gian này, chúng tôi sử dụng nhật ký giao dịch nhiều hơn trong cơ sở dữ liệu TSQLV4_NOADR.

Hình. 7 Xóa Thời gian Thực thi cho TSQLV4_NOADR

Hình. 8 Xóa thời gian thực thi cho TSQLV4_ADR

Hình. 9 Việc sử dụng nhật ký giao dịch sau khi xóa

Đến nay, rõ ràng là các thao tác DML mất nhiều thời gian hơn trong cơ sở dữ liệu có bật ADR. Điều này phần nào giải thích tại sao tính năng này bị tắt ngay từ đầu. Suy nghĩ sâu về nó, nó có ý nghĩa vì SQL Server phải lưu trữ các phiên bản hàng trong PVS trong khi thao tác chèn, cập nhật hoặc xóa đang chạy. Dù DML mất khoảng thời gian nào đi nữa, chúng tôi thấy rằng việc phát ra một ROLLBACK với ADR được BẬT chỉ mất ít hơn 1 mili giây (xem Hình 10 - 13). Trong một số trường hợp, khôi phục nhanh có thể bù đắp cho chi phí của chính DML, nhưng không phải trong mọi trường hợp!

Hình. 10 Thời gian thực thi cho ROLLBACK (Sau khi XÓA) trên TSQLV4_NOADR

Hình. 11 Thời gian thực thi cho ROLLBACK (Sau khi XÓA) trên TSQLV4_ADR

Hình. 12 Thời gian thực thi cho ROLLBACK (Sau khi CHÈN) trên TSQLV4_NOADR

Hình. 13 Thời gian thực thi cho ROLLBACK (Sau khi XÓA) trên TSQLV4_ADR

Kết luận

Accelerated Database Recovery là một trong những tính năng tuyệt vời được phát hành trong SQL Server 2019. Tuy nhiên, như với tất cả những điều cực kỳ tốt đẹp trong cuộc sống, ai đó phải trả tiền cho nó. ADR có thể có tác động tiêu cực đến hiệu suất trong một số tình huống nhất định, vì vậy điều quan trọng là phải đánh giá kỹ kịch bản của bạn trước khi triển khai ADR trong cơ sở dữ liệu sản xuất của bạn. Microsoft đặc biệt khuyến nghị Phục hồi cơ sở dữ liệu được tăng tốc cho các cơ sở dữ liệu hỗ trợ khối lượng công việc có các giao dịch đang hoạt động rất lâu, tăng trưởng nhật ký giao dịch quá mức hoặc sự cố thường xuyên liên quan đến quá trình khôi phục trong thời gian dài.

Tài liệu tham khảo

  1. Phục hồi Cơ sở dữ liệu Cấp tốc

  2. Phục hồi cơ sở dữ liệu được tăng tốc hoạt động như thế nào?

  3. Phục hồi Cơ sở dữ liệu Cấp tốc


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Chế độ xem trong SQL Server

  2. Đổi tên khóa ngoại trong SQL Server bằng T-SQL

  3. Cách lấy ngày hiện tại trong SQL Server

  4. Tôi đã nâng cấp Trình điều khiển ODBC SQL Server và hiệu suất đã bị ảnh hưởng tiêu cực. Tôi có thể làm gì?

  5. Tính tổng số đang chạy trong SQL Server