Sqlserver
 sql >> Teknologi Basis Data >  >> RDS >> Sqlserver

Pemulihan Database yang Dipercepat di SQL Server 2019

Ikhtisar Pemulihan Tradisional

Seperti semua sistem database relasional, SQL Server menjamin ketahanan data dengan menerapkan pemulihan kerusakan. Durability dalam akronim ACID yang mengacu pada karakteristik transaksi dalam database relasional berarti bahwa kita dapat yakin bahwa jika database gagal tiba-tiba, data kita aman.

SQL Server mengimplementasikan kemampuan ini menggunakan log transaksi. Perubahan yang dibuat oleh semua Operasi Manipulasi Data di SQL Server dicatat dalam log transaksi sebelum diterapkan ke file data (melalui proses pos pemeriksaan) jika diperlukan untuk memutar mundur atau maju.

Proses pemulihan crash tiga fase di SQL Server adalah sebagai berikut:

  • Analisis – SQL Server membaca log transaksi dari pos pemeriksaan terbaru hingga akhir log transaksi

  • Ulangi – SQL Server memutar ulang log dari transaksi tertua yang tidak dikomit hingga akhir log

  • Urungkan – SQL Server membaca log dari akhir log ke transaksi tertua yang tidak dikomit dan mengembalikan semua transaksi yang aktif selama crash

DBA yang berpengalaman pada suatu saat dalam karier mereka memiliki pengalaman yang mengecewakan karena menunggu tanpa daya untuk pemulihan kerusakan diselesaikan pada database yang sangat besar. Transaksi ROLLBACK menggunakan mekanisme yang mirip dengan proses pemulihan kerusakan. Microsoft telah meningkatkan proses pemulihan secara signifikan di SQL Server 2019.

Pemulihan Basis Data yang Dipercepat

Pemulihan Basis Data yang Dipercepat adalah fitur baru berdasarkan versi yang secara signifikan meningkatkan tingkat pemulihan dalam kasus ROLLBACK atau pemulihan dari kerusakan.

Di SQL Server 2019, tiga mekanisme baru dalam mesin SQL Server mengubah cara penanganan pemulihan dan secara efektif mengurangi waktu yang diperlukan untuk melakukan rollback/rollforward.

  • Persistent Version Store (PVS) – Menangkap versi baris dalam database yang bersangkutan. Persistent Version Store dapat didefinisikan dalam grup file terpisah karena alasan performa atau ukuran

  • Pengembalian Logis – Menggunakan versi baris yang disimpan di PVS untuk melakukan rollback saat rollback dipanggil untuk transaksi tertentu atau saat fase undo dari pemulihan kerusakan dipanggil.

  • sLog – Ini mungkin singkatan dari sekunder log . Ini adalah aliran log dalam memori yang digunakan untuk menangkap operasi yang tidak dapat diversi. Saat ADR diaktifkan di database, sLog selalu dibangun kembali selama fase analisis pemulihan kerusakan. Selama mengulang fase, sLog digunakan daripada log transaksi yang sebenarnya membuat proses lebih cepat karena berada di memori dan berisi lebih sedikit transaksi. Proses pemulihan tradisional menangani transaksi dari pos pemeriksaan terakhir. sLog juga digunakan selama undo fase.

  • Pembersih – Menghapus versi baris yang tidak perlu dari PVS. Microsoft juga menyediakan prosedur tersimpan untuk memaksa pembersihan versi baris yang tidak perlu secara manual.

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

Pemulihan Basis Data yang Dipercepat DIMATIKAN secara Default

Fakta bahwa ADR dimatikan di SQL Server 2019 secara default mungkin tampak mengejutkan bagi beberapa DBA mengingat fitur ini tampak hebat. ADR menggunakan pembuatan versi di database pengguna yang mengaktifkannya. Hal ini dapat mempengaruhi ukuran database secara signifikan. Selain itu, Anda mungkin perlu merencanakan pertumbuhan basis data serta kemungkinan lokasi PVS untuk memastikan kinerja yang baik jika ADR diaktifkan. Jadi masuk akal untuk secara sengaja mengaktifkan fungsi ini.

Eksperimen:Tahap Persiapan

Kami menyiapkan eksperimen untuk menjelajahi fitur baru dan melihat dampak ADR pada ukuran log transaksi serta kecepatan ROLLBACK. Dalam percobaan kami, kami membuat dua database identik menggunakan satu set cadangan dan kemudian kami mengaktifkan ADR hanya pada salah satu database ini. Daftar 2 menunjukkan tahapan persiapan untuk tugas tersebut.

[expand title =”Kode”]

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

[/expand]

Gambar 1 menunjukkan output dari pernyataan SQL pada Listing 2 bagian 2c. Kami juga menangkap ukuran file database dan penggunaan file log transaksi. (lihat Gambar 3).

Gbr. 1 Konfirmasikan ADR Dikonfigurasi

Gbr. 2 Tinjau Ukuran File Data Basis Data

Gbr. 3 Periksa Ukuran Log yang Digunakan untuk Kedua Basis Data

Eksperimen:Tahap Eksekusi

Setelah kami menangkap detail yang kami perlukan untuk melanjutkan, kami kemudian mengeksekusi kode SQL dari Daftar 3 dan 4 secara bertahap. Kedua daftar tersebut setara, tetapi kami menjalankannya pada dua database yang identik secara terpisah. Pertama, kami melakukan INSERT (Listing 3, 3a), kemudian kami melakukan DELETE (Listing 3, 3b) yang selanjutnya akan kami putar kembali. Perhatikan bahwa baik di INSERT dan DELETE, kami telah merangkum operasi dalam transaksi. Juga, perhatikan bahwa INSERT dijalankan 50 kali. Pada setiap tahap eksekusi, yaitu antara 3a, 3b, dan 3c, kami menangkap penggunaan log transaksi dengan bantuan kode di Listing 2,2e. Ini sama untuk bagian 4a, 4b, dan 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;

Gbr. 4 dan 5 menunjukkan kepada kita bahwa operasi SELECT INTO membutuhkan waktu 6 milidetik lebih banyak di database TSQLV4_ADR tempat kami mengaktifkan Accelerated Database Recovery. Kita juga melihat pada Gambar 6 bahwa kita memiliki penggunaan log transaksi yang lebih besar dalam database TSQLV4_ADR. Saya sangat terkejut dengan hal ini, jadi saya mengulangi eksperimen beberapa kali untuk memastikan saya mendapatkan hasil ini secara konsisten.

Gbr. 4 Masukkan Waktu Eksekusi untuk TSQLV4_NOADR

Gbr. 5 Masukkan Waktu Eksekusi untuk TSQLV4_ADR

Gbr. 6 Penggunaan Log Transaksi Setelah Sisipan 

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

Gbr. 7 dan 8 menunjukkan kepada kita bahwa operasi DELETE membutuhkan lebih banyak waktu untuk diselesaikan dalam database TSQLV4_ADR tempat kami mengaktifkan Pemulihan Database yang Dipercepat meskipun jumlah baris yang sama telah dihapus di kedua database. Namun kali ini, kami memiliki penggunaan log transaksi yang lebih besar di database TSQLV4_NOADR.

Gbr. 7 Hapus Waktu Eksekusi untuk TSQLV4_NOADR

Gbr. 8 Hapus Waktu Eksekusi untuk TSQLV4_ADR

Gbr. 9 Penggunaan Log Transaksi Setelah Dihapus

Sekarang menjadi jelas bahwa operasi DML memakan waktu lebih lama di database dengan ADR diaktifkan. Ini sebagian menjelaskan mengapa fitur tersebut tidak aktif sejak awal. Memikirkannya secara mendalam, masuk akal karena SQL Server harus menyimpan versi baris di PVS saat operasi penyisipan, pembaruan, atau penghapusan sedang berjalan. Berapa pun waktu yang dibutuhkan DML, kami menemukan bahwa mengeluarkan ROLLBACK dengan ADR AKTIF membutuhkan waktu kurang dari 1 milidetik (lihat Gambar 10 – 13). Dalam beberapa kasus, rollback cepat dapat mengkompensasi overhead DML itu sendiri, tetapi tidak dalam semua kasus!

Gbr. 10 Waktu Eksekusi untuk ROLLBACK (Setelah DELETE) pada TSQLV4_NOADR

Gbr. 11 Waktu Eksekusi untuk ROLLBACK (Setelah DELETE) pada TSQLV4_ADR

Gbr. 12 Waktu Eksekusi untuk ROLLBACK (Setelah INSERT) pada TSQLV4_NOADR

Gbr. 13 Waktu Eksekusi untuk ROLLBACK (Setelah DELETE) di TSQLV4_ADR

Kesimpulan

Pemulihan Basis Data yang Dipercepat adalah salah satu fitur hebat yang dirilis di SQL Server 2019. Namun, seperti semua hal yang sangat menyenangkan dalam hidup, seseorang harus membayarnya. ADR dapat memiliki dampak kinerja yang negatif dalam skenario tertentu, jadi penting untuk mengevaluasi skenario Anda dengan cermat sebelum menerapkan ADR di database produksi Anda. Microsoft secara khusus merekomendasikan Pemulihan Basis Data yang Dipercepat untuk basis data yang mendukung beban kerja dengan transaksi yang berjalan sangat lama, pertumbuhan log transaksi yang berlebihan, atau pemadaman yang sering terkait dengan pemulihan yang berjalan lama.

Referensi

  1. Pemulihan Basis Data yang Dipercepat

  2. Bagaimana Cara Kerja Pemulihan Basis Data yang Dipercepat?

  3. Pemulihan Basis Data yang Dipercepat


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

  1. Gunakan DATABASEPROPERTYEX() untuk Mengembalikan Pengaturan Database di SQL Server

  2. Fungsi Partisi COUNT() OVER mungkin menggunakan DISTINCT

  3. Bandingkan tanggal dalam T-SQL, abaikan bagian waktu

  4. Menghapus Profil Email Database di SQL Server (T-SQL)

  5. Cara Mengganti Nama Nama Tabel di SQL Server