Bagikan melalui

Pemulihan database dipercepat

Berlaku untuk: SQL Server 2019 (15.x) dan versi yang lebih baru Azure SQL DatabaseAzure SQL Managed InstanceSQL database di Microsoft Fabric

Pemulihan database yang dipercepat (ADR) meningkatkan ketersediaan database, terutama di hadapan transaksi yang berjalan lama, dengan mendesain ulang proses pemulihan mesin database.

ADR diperkenalkan di SQL Server 2019 (15.x) dan ditingkatkan di SQL Server 2022 (16.x) dan SQL Server 2025 (17.x). ADR juga tersedia di Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (khusus kumpulan SQL khusus), dan database SQL di Microsoft Fabric.

Note

ADR selalu diaktifkan di Azure SQL Database, Azure SQL Managed Instance, dan database SQL di Fabric.

Artikel ini menyediakan gambaran umum ADR. Untuk bekerja dengan ADR, tinjau Mengelola pemulihan database yang dipercepat.

Untuk informasi selengkapnya tentang log transaksi dan pemulihan database, lihat Arsitektur Log Transaksi SQL Server dan Panduan Manajemen dan Ringkasan Pengembalian dan Pemulihan (SQL Server).

Overview

Keuntungan utama ADR adalah:

  • Pemulihan database yang cepat dan konsisten

    Transaksi jangka panjang tidak memengaruhi waktu pemulihan keseluruhan, memungkinkan pemulihan database yang cepat dan konsisten terlepas dari jumlah transaksi aktif dalam sistem atau ukurannya.

  • Pemutaran kembali transaksi seketika

    Pembatalan transaksi seketika, terlepas dari waktu transaksi telah aktif atau jumlah pembaruan yang telah dibuat.

  • Pemotongan log agresif

    Log transaksi dipangkas secara intensif, meskipun ada transaksi aktif yang berlangsung lama, sehingga mencegah pertumbuhannya menjadi tidak terkendali.

Proses pemulihan database tradisional

Tanpa ADR, pemulihan database mengikuti ARIES model pemulihan dan terdiri dari tiga fase, yang diilustrasikan dan dijelaskan secara lebih rinci dalam diagram berikut:

Diagram proses pemulihan saat ini.

  • Fase analisis

    Mesin database melakukan pemindaian maju log transaksi dari awal titik pemeriksaan terakhir yang berhasil (atau nomor urutan log halaman kotor terlama (LSN)) hingga akhir, untuk menentukan status setiap transaksi pada saat mesin berhenti.

  • Fase ulang

    Mesin database melakukan pemindaian maju log transaksi dari transaksi terlama yang tidak dilakukan hingga akhir. Proses ini mengulangi semua operasi yang diterapkan untuk memulihkan database ke statusnya pada saat crash.

  • Batalkan tahap

    Untuk setiap transaksi yang aktif pada saat crash, mesin database melintasi log mundur, membatalkan operasi yang dilakukan transaksi ini.

  • Dengan proses pemulihan database tradisional, pemulihan setelah crash dapat memakan waktu lama jika transaksi yang berjalan lama aktif.

    Waktu bagi mesin database untuk pulih dari hidupkan ulang yang tidak terduga adalah (kira-kira) sebanding dengan ukuran transaksi aktif terpanjang dalam sistem pada saat crash. Pemulihan membutuhkan pemutaran kembali semua transaksi yang tidak lengkap. Lamanya waktu yang dibutuhkan sebanding dengan pekerjaan yang telah dilakukan transaksi dan durasi waktu aktifnya.

  • Membatalkan transaksi besar dapat memakan waktu lama, karena menggunakan fase pemulihan pembatalan yang sama seperti yang dijelaskan sebelumnya.

  • Mesin database tidak dapat memotong log transaksi ketika ada transaksi yang berjalan lama karena catatan log yang sesuai diperlukan untuk proses pemulihan dan pembatalan. Akibatnya, log transaksi dapat tumbuh sangat besar dan mengonsumsi banyak ruang penyimpanan.

Proses pemulihan database yang dipercepat

ADR mengatasi masalah sebelumnya dengan model pemulihan tradisional dengan sepenuhnya mendesain ulang proses pemulihan mesin database untuk:

  • Buat konstanta waktu pemulihan karena tidak ada lagi kebutuhan untuk memindai log transaksi dari awal transaksi aktif terlama. Dengan ADR, log transaksi hanya diproses dari checkpoint terakhir yang berhasil (atau nomor urut log (LSN) halaman kotor terlama). Akibatnya, waktu pemulihan tidak terpengaruh oleh transaksi yang berjalan lama dan biasanya seketika.

  • Minimalkan ruang log transaksi yang diperlukan karena tidak ada lagi kebutuhan untuk menyimpan log untuk seluruh transaksi. Akibatnya, log transaksi dapat dipotong secara agresif saat titik pemeriksaan dan pencadangan terjadi.

Secara umum, ADR mencapai pemulihan database yang cepat dengan membuat versi baru dari semua modifikasi database fisik dan hanya membatalkan operasi nonversi, yang terbatas dan dapat dibatalkan dalam waktu singkat. Setiap transaksi yang aktif pada saat crash ditandai sebagai dibatalkan dan, oleh karena itu, versi apa pun yang dihasilkan oleh transaksi ini dapat diabaikan oleh kueri pengguna bersamaan.

Proses pemulihan ADR memiliki tiga fase yang sama dengan proses pemulihan tradisional. Bagaimana fase ini beroperasi dengan ADR diilustrasikan dalam diagram berikut:

Diagram proses pemulihan ADR.

  • Fase analisis

    Prosesnya tetap sama dengan model pemulihan tradisional dengan penambahan rekonstruksi aliran log sekunder (SLOG) dan menyalin catatan log untuk operasi nonversi.

  • Fase ulang

    Dipecah menjadi dua subfase

    • Subfase 1

      Ulangi dari SLOG (transaksi terlama yang tidak dilakukan hingga titik pemeriksaan terakhir). Redo adalah operasi cepat karena mungkin hanya perlu memproses beberapa catatan dari SLOG.

    • Subfase 2

      Redo dari log transaksi dimulai dari titik pemeriksaan terakhir yang berhasil (bukan transaksi yang belum diselesaikan).

  • Batalkan tahap

    Fase pembatalan dengan ADR selesai hampir seketika dengan menggunakan SLOG untuk mengurungkan operasi nonversi dan penyimpanan versi persisten (PVS) menggunakan pengembalian logis untuk melakukan pembatalan berbasis versi pada tingkat baris.

Untuk penjelasan tentang pemulihan database yang dipercepat, tonton video delapan menit ini:

Komponen pemulihan ADR

Empat komponen utama ADR adalah:

  • penyimpanan versi persisten (PVS)

    Penyimpanan versi persisten (PVS) adalah mekanisme mesin database untuk mempertahankan versi baris dalam database itu sendiri alih-alih di penyimpanan versi tradisional di database tempdb. PVS memungkinkan isolasi sumber daya dan meningkatkan ketersediaan sekunder yang dapat dibaca.

    PVS menyimpan versi baris baik secara langsung di halaman data yang dimodifikasi, atau dalam tabel sistem terpisah. Untuk informasi selengkapnya, lihat Space yang digunakan oleh penyimpanan versi persisten (PVS).

  • Pembalikan Logis

    Pengembalian logis adalah proses asinkron yang bertanggung jawab untuk melakukan pembatalan berbasis versi tingkat baris - menyediakan pembatalan transaksi instan dan membatalkan untuk semua operasi versi.

    • Melacak semua transaksi yang dibatalkan
    • Melakukan putar kembali menggunakan PVS untuk semua transaksi pengguna
    • Melepaskan semua kunci segera setelah transaksi dibatalkan

  • SLOG

    SLOG adalah aliran log dalam memori sekunder yang menyimpan rekaman log untuk operasi nonversi (seperti invalidasi cache metadata, akuisisi kunci, dan sebagainya). SLOG adalah:

    • Bervolume rendah dan di dalam memori
    • Disimpan pada disk selama proses checkpoint
    • Dipotong secara berkala saat transaksi dilakukan
    • Mempercepat redo dan undo dengan hanya memproses operasi non-versi
    • Memungkinkan pemotongan log transaksi yang agresif dengan hanya mempertahankan catatan log yang diperlukan

  • Cleaner

    Pembersih adalah proses asinkron yang bangun secara berkala dan membersihkan versi baris usang dari PVS.

Beban kerja yang mendapat manfaat dari ADR

ADR menguntungkan sebagian besar beban kerja dengan meningkatkan ketersediaan database, dan sangat bermanfaat untuk beban kerja yang memiliki:

  • Transaksi jangka panjang.
  • Transaksi aktif yang menyebabkan log transaksi tumbuh secara signifikan.
  • Periode panjang tidak tersedianya database karena pemulihan yang berjalan lama (seperti dari mulai ulang layanan yang tidak terduga atau pembatalan transaksi manual).

Manfaat ADR memerlukan penyimpanan versi dan pemrosesan tambahan, yang mungkin memperkenalkan overhead performa untuk beban kerja tertentu. Misalnya, dengan beban kerja intensif tulis yang menghasilkan banyak versi baris, halaman data mungkin lebih sering dibagi untuk mengakomodasi versi dalam baris . Karena semua versi baris dicatat, jumlah log transaksi yang dihasilkan juga dapat meningkat.

Untuk sebagian besar beban kerja, overhead performa ADR berkisar dari tidak dapat dideteksi hingga kecil. Dalam strategi manajemen database yang optimal, Anda menyeimbangkan manfaat ADR tertentu terhadap beban kinerja potensial.

ADR tidak didukung dalam database yang menggunakan pencerminan database , sebuah fitur ketersediaan tinggi yang sudah lama dan tidak lagi digunakan.

Praktik terbaik untuk ADR

  • Hindari transaksi jangka panjang yang tidak perlu. Meskipun ADR mempercepat pemulihan database bahkan dengan transaksi yang berjalan lama, transaksi tersebut dapat menunda pembersihan versi dan meningkatkan ukuran PVS.

  • Hindari transaksi besar yang mencakup operasi DDL. ADR menggunakan mekanisme aliran log sekunder (SLOG) untuk melacak operasi DDL yang digunakan dalam pemulihan. SLOG hanya digunakan saat transaksi aktif. SLOG dicatat, sehingga dengan menghindari transaksi besar yang menggunakan SLOG, kinerja keseluruhan dapat ditingkatkan. Skenario ini dapat menyebabkan SLOG memakan lebih banyak ruang:

    • Banyak DLL dijalankan dalam satu transaksi. Misalnya, dalam satu transaksi, membuat dan menghilangkan tabel sementara dengan cepat.
    • Tabel memiliki jumlah partisi/indeks yang sangat besar yang dimodifikasi. Misalnya, operasi DROP TABLE pada tabel tersebut akan memerlukan reservasi memori SLOG yang besar, yang akan menunda pemotongan log transaksi dan menunda fungsi undo/redo. Sebagai solusinya, hilangkan indeks satu per satu dan secara bertahap, lalu jatuhkan tabel.

    Untuk informasi selengkapnya tentang SLOG, lihat komponen pemulihan ADR.

  • Mencegah atau mengurangi transaksi yang dibatalkan yang tidak perlu. Tingkat pembatalan transaksi yang tinggi memberikan tekanan pada pembersih PVS dan menurunkan performa ADR. Pembatalan mungkin berasal dari tingkat kebuntuan yang tinggi, kunci duplikat, pelanggaran batasan, batas waktu kueri, atau pengecualian lainnya. DMV sys.dm_tran_aborted_transactions menunjukkan semua transaksi yang dibatalkan pada instans mesin database. Kolom nested_abort menunjukkan bahwa transaksi yang dilakukan tetapi ada bagian yang dibatalkan (titik simpan atau transaksi berlapis) yang juga dapat menunda proses pembersihan PVS.

  • Pastikan ada cukup ruang dalam database untuk memperhitungkan penggunaan PVS. Jika database tidak memiliki cukup ruang bagi PVS untuk tumbuh, ADR mungkin gagal menghasilkan versi, menyebabkan pernyataan DML gagal.

  • Ketika ADR diaktifkan dengan beban kerja intensif tulis, tingkat pembuatan log transaksi dapat meningkat secara substansial karena versi baris yang ditulis ke PVS dicatat. Ini mungkin dapat meningkatkan ukuran pencadangan log transaksi.

  • Saat Anda menggunakan replikasi transaksional, replikasi rekam jepret, atau penangkapan data perubahan (CDC), perilaku agresif pemotongan log ADR dinonaktifkan untuk memungkinkan pembaca log mengumpulkan perubahan dari log transaksi. Pastikan bahwa log transaksi cukup besar.

    Jika menggunakan CDC atau mengubah umpan di Azure SQL Database, Anda mungkin perlu meningkatkan tingkat layanan atau ukuran komputasi Anda untuk memastikan bahwa ruang log transaksi yang memadai tersedia untuk kebutuhan semua beban kerja Anda. Demikian pula, di Azure SQL Managed Instance Anda mungkin perlu meningkatkan ukuran penyimpanan maksimum instans Anda.

  • Untuk SQL Server, ketika penyimpanan performa berjenjang tersedia, pertimbangkan untuk menempatkan grup file PVS pada penyimpanan tingkat yang lebih tinggi. Untuk informasi selengkapnya, lihat Mengubah grup file PVS.

  • Dimulai dengan SQL Server 2022 (16.x), pertimbangkan untuk mengaktifkan pembersihan PVS multithreading jika performa pembersih satu utas tidak mencukupi. Untuk informasi selengkapnya, lihat konfigurasi server : Jumlah Utas Pembersih ADR.

  • Dimulai dengan SQL Server 2025 (17.x), jika Anda mengaktifkan ADR di tempdb, Anda mungkin perlu mengalokasikan ruang tambahan untuk data PVS dalam tempdb file data. Ukuran PVS dapat tempdb dengan cara yang sama seperti dalam database pengguna.

  • Jika Anda mengamati masalah seperti penggunaan ruang database tinggi oleh PVS atau pembersihan PVS yang lambat, lihat Memantau dan memecahkan masalah pemulihan database yang dipercepat.

Peningkatan ADR di SQL Server 2025

  • ADR dalam tempdb

    Dimulai dengan SQL Server 2025 (17.x), ADR dapat diaktifkan dalam database tempdb.

    Tanpa ADR, dan bahkan dengan pencatatan minimal yang digunakan dalam tempdb, transaksi yang melibatkan objek seperti tabel sementara, variabel tabel, atau tabel non-sementara yang dibuat dalam tempdb dapat dipengaruhi oleh waktu pembatalan yang lama dan penggunaan log transaksi yang tinggi. Kehabisan tempdb ruang log transaksi dapat menyebabkan gangguan yang signifikan dan waktu henti aplikasi.

    SQL Server 2025 (17.x) menyediakan keuntungan pembatalan transaksi seketika dan pemotongan log agresif dari ADR untuk beban kerja yang menggunakan transaksi di tempdb.

    Untuk mengaktifkan ADR di tempdb, lihat Mengaktifkan ADR.

Peningkatan ADR di SQL Server 2022

Ada beberapa peningkatan untuk mengatasi penyimpanan penyimpanan versi persisten (PVS) dan meningkatkan skalabilitas keseluruhan. Untuk informasi selengkapnya tentang fitur baru SQL Server 2022 (16.x), lihat Apa yang baru di SQL Server 2022.

Peningkatan yang sama juga tersedia di Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (khusus kumpulan SQL khusus), dan database SQL di Microsoft Fabric.

  • Pembersihan transaksi pengguna

    Membersihkan halaman yang tidak dapat dibersihkan melalui proses reguler karena kegagalan mendapatkan kunci.

    Fitur ini memungkinkan transaksi pengguna untuk menjalankan pembersihan pada halaman yang tidak dapat diatasi oleh proses pembersihan reguler karena konflik kunci tingkat tabel. Peningkatan ini membantu memastikan bahwa proses pembersihan ADR tidak gagal tanpa batas waktu karena beban kerja pengguna tidak dapat memperoleh kunci tingkat tabel.

  • Kurangi jejak memori untuk pelacak halaman PVS

    Peningkatan ini melacak halaman PVS pada tingkat cakupan, untuk mengurangi penggunaan memori yang dibutuhkan untuk memelihara halaman yang memiliki versi.

  • peningkatan pembersih PVS

    Pembersih PVS telah meningkatkan efisiensi pemrosesan versi untuk meningkatkan kinerja mesin database dalam melacak dan merekam versi baris pada transaksi yang dibatalkan. Hal ini menyebabkan peningkatan dalam penggunaan memori dan penyimpanan.

  • penyimpanan versi persisten tingkat transaksi (PVS)

    Peningkatan ini memungkinkan ADR untuk membersihkan versi yang termasuk dalam transaksi yang telah berkomitmen, terlepas dari apakah ada transaksi yang dibatalkan dalam sistem. Dengan peningkatan ini, halaman PVS dapat dibebaskan alokasinya, bahkan jika pembersihan tidak dapat menyelesaikan pemeriksaan yang berhasil untuk memangkas peta transaksi yang dibatalkan.

    Hasil dari peningkatan ini adalah berkurangnya pertumbuhan PVS bahkan jika pembersihan PVS lambat atau gagal.

  • Pembersihan versi multi-utas

    Pada SQL Server 2019 (15.x), proses pembersihan menggunakan utas tunggal dalam instance mesin database.

    Dimulai dengan SQL Server 2022 (16.x), pembersihan versi multi-utas didukung. Ini memungkinkan beberapa database pada instans mesin database yang sama dibersihkan secara paralel, atau database tunggal dibersihkan lebih cepat. Untuk informasi selengkapnya, lihat konfigurasi server : Jumlah Utas Pembersih ADR.

    Peristiwa baru yang diperluas, tx_mtvc2_sweep_stats, telah ditambahkan untuk pemantauan pembersih versi multi-utas ADR PVS.

Konten terkait

  • Last updated on