Bagikan melalui

Kompresi cadangan (SQL Server)

  • Artikel

Berlaku untuk: SQL Server

Artikel ini menjelaskan kompresi cadangan SQL Server, termasuk pembatasan, trade-off performa pencadangan kompresi, konfigurasi kompresi cadangan, dan rasio kompresi. Kompresi cadangan didukung pada edisi SQL Server: Perusahaan, Standar, dan Pengembang. Setiap edisi SQL Server 2008 (10.0.x) dan yang lebih baru dapat memulihkan cadangan terkompresi.

Keuntungan

  • Karena pencadangan terkompresi lebih kecil dari pencadangan tidak terkompresi dari data yang sama, mengompresi cadangan biasanya membutuhkan lebih sedikit I/O perangkat dan oleh karena itu biasanya meningkatkan kecepatan pencadangan secara signifikan.

    Untuk informasi selengkapnya, lihat Dampak Performa Kompresi Cadangan, nanti di artikel ini.

Batasan

Pembatasan berikut berlaku untuk pencadangan terkompresi:

  • Pencadangan terkompresi dan tidak dikompresi tidak dapat berdampingan dalam set media.

  • Versi SQL Server sebelumnya tidak dapat membaca cadangan terkompresi.

  • NTbackups tidak dapat berbagi pita dengan cadangan SQL Server terkompresi.

Dampak performa kompresi cadangan

Secara default, kompresi secara signifikan meningkatkan penggunaan CPU, dan CPU tambahan yang digunakan oleh proses kompresi mungkin berdampak buruk pada operasi bersamaan. Oleh karena itu, Anda mungkin ingin membuat cadangan terkompresi berprioritas rendah dalam sesi yang penggunaan CPU-nya dibatasi oleh Resource Governor. Untuk informasi selengkapnya, lihat Menggunakan Resource Governor untuk Membatasi Penggunaan CPU dengan Kompresi Cadangan (Transact-SQL).

Dimulai dengan SQL Server 2022 (16.x), Anda dapat menggunakan Offloading & akselerasi terintegrasi untuk mengompres cadangan dan membongkar sumber daya CPU untuk cadangan.

Untuk mendapatkan gambaran yang baik tentang performa I/O cadangan Anda, Anda dapat mengisolasi I/O cadangan ke atau dari perangkat dengan mengevaluasi semacam penghitung kinerja berikut:

Untuk informasi tentang penghitung Windows, lihat Bantuan Windows. Untuk informasi tentang cara bekerja dengan penghitung SQL Server, lihat Menggunakan Objek SQL Server.

Menghitung rasio kompresi cadangan terkompresi

Untuk menghitung rasio kompresi cadangan, gunakan nilai untuk cadangan di kolom backup_size dan compressed_backup_size tabel riwayat set cadangan, sebagai berikut:

backup_size:compressed_backup_size

Misalnya, rasio kompresi 3:1 menunjukkan bahwa Anda menghemat sekitar 66% pada ruang disk. Untuk mengkueri kolom ini, Anda bisa menggunakan pernyataan Transact-SQL berikut:

SELECT backup_size/compressed_backup_size FROM msdb..backupset;

Rasio kompresi cadangan terkompresi tergantung pada data yang telah dikompresi. Berbagai faktor dapat berdampak pada rasio kompresi yang diperoleh. Faktor utama meliputi:

  • Jenis data.

    Data karakter mengompresi lebih dari jenis data lainnya.

  • Konsistensi data di antara baris pada halaman.

    Biasanya, jika halaman berisi beberapa baris di mana bidang berisi nilai yang sama, pemadatan signifikan mungkin terjadi untuk nilai tersebut. Sebaliknya, untuk database yang berisi data acak atau yang hanya berisi satu baris besar per halaman, cadangan terkompresi akan hampir sebesar cadangan yang tidak dikompresi.

  • Apakah data dienkripsi

    Data terenkripsi mengompresi data yang secara signifikan kurang dari data yang tidak terenkripsi yang setara. Misalnya, jika data dienkripsi di tingkat kolom dengan Always Encrypted, atau dengan enkripsi tingkat aplikasi lainnya, memadatkan cadangan mungkin tidak mengurangi ukuran secara signifikan.

    Untuk informasi selengkapnya terkait pemadatan database yang dienkripsi dengan Transparent Data Encryption (TDE), lihat Kompresi cadangan dengan TDE.

  • Apakah database dikompresi.

    Jika database dikompresi, mengompresi cadangan mungkin tidak mengurangi ukurannya, jika sama sekali.

Kompresi cadangan dengan TDE

Dimulai dengan SQL Server 2016 (13.x), pengaturan MAXTRANSFERSIZE yang lebih besar dari 65536 (64 KB) memungkinkan algoritma kompresi yang dioptimalkan untuk database terenkripsi Transparent Data Encryption (TDE) yang terlebih dahulu mendekripsi halaman, mengompresinya, dan kemudian mengenkripsinya lagi. Jika MAXTRANSFERSIZE tidak ditentukan, atau jika MAXTRANSFERSIZE = 65536 (64 KB) digunakan, kompresi cadangan dengan database terenkripsi TDE langsung mengompresi halaman terenkripsi, dan mungkin tidak menghasilkan rasio kompresi yang baik. Untuk informasi selengkapnya, lihat Kompresi Cadangan untuk Database yang didukung TDE.

Dimulai dengan SQL Server 2019 (15.x) CU5, pengaturan MAXTRANSFERSIZE tidak lagi diperlukan untuk mengaktifkan algoritma kompresi yang dioptimalkan ini dengan TDE. Jika perintah cadangan ditentukan WITH COMPRESSION atau konfigurasi server default kompresi cadangan diatur ke 1, MAXTRANSFERSIZE akan secara otomatis ditingkatkan menjadi 128K untuk mengaktifkan algoritma yang dioptimalkan. Jika MAXTRANSFERSIZE ditentukan pada perintah cadangan dengan nilai > 64K, nilai yang disediakan akan dihormati. Dengan kata lain, SQL Server tidak akan pernah secara otomatis mengurangi nilai, itu hanya akan meningkatkannya. Jika Anda perlu mencadangkan database terenkripsi TDE dengan MAXTRANSFERSIZE = 65536, Anda harus menentukan WITH NO_COMPRESSION atau memastikan bahwa konfigurasi server default kompresi cadangan diatur ke 0.

Untuk informasi selengkapnya, lihat BACKUP (Transact-SQL).

Alokasi ruang untuk file cadangan

Untuk cadangan terkompresi, ukuran file cadangan akhir tergantung pada seberapa terkompresi data, dan ini tidak diketahui sebelum operasi pencadangan selesai. Oleh karena itu, secara default, saat mencadangkan database menggunakan kompresi, Mesin Database menggunakan algoritma pra-alokasi untuk file cadangan. Algoritma ini telah mengalokasikan persentase yang telah ditentukan sebelumnya dari ukuran database untuk file cadangan. Jika lebih banyak ruang diperlukan selama operasi pencadangan, Mesin Database akan menumbuhkan file. Jika ukuran akhir kurang dari ruang yang dialokasikan, di akhir operasi pencadangan, Mesin Database menyusutkan file ke ukuran akhir cadangan yang sebenarnya.

Untuk memungkinkan file cadangan hanya tumbuh sesuai kebutuhan untuk mencapai ukuran akhirnya, gunakan bendera pelacakan 3042. Bendera pelacakan 3042 menyebabkan operasi pencadangan melewati algoritma pra-alokasi kompresi cadangan default. Bendera pelacakan ini berguna jika Anda perlu menghemat ruang dengan mengalokasikan hanya ukuran aktual yang diperlukan untuk cadangan terkompresi. Namun, menggunakan bendera pelacakan ini dapat menyebabkan sedikit penalti performa (kemungkinan peningkatan durasi operasi pencadangan).

Tugas terkait

Langkah berikutnya

Gambaran Umum Pencadangan (SQL Server)
Bendera Pelacakan (Transact-SQL)