Bagikan melalui

Kompresi Cadangan (SQL Server)

Topik ini menjelaskan kompresi cadangan SQL Server, termasuk keterbatasan, trade-off performa terkait kompresi cadangan, konfigurasi kompresi cadangan, dan rasio kompresi.

Nota

Untuk informasi mengenai edisi SQL Server 2014 yang mendukung kompresi cadangan, lihat Fitur yang Didukung oleh Edisi SQL Server 2014. Setiap edisi SQL Server 2008 dan yang lebih baru dapat memulihkan cadangan terkompresi.

Keuntungan

  • Karena cadangan terkompresi lebih kecil dari cadangan yang tidak dikompresi 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 dalam topik ini.

Pembatasan

Pembatasan berikut berlaku untuk pencadangan terkompresi:

  • Cadangan terkompresi dan tidak terkompresi tidak bisa ada bersama-sama dalam kelompok media.

  • Versi SQL Server sebelumnya tidak dapat membaca cadangan terkompresi.

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

Dampak Kinerja dari 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 olehResource Governor. Untuk informasi selengkapnya, lihat Menggunakan Resource Governor untuk Membatasi Penggunaan CPU dengan Kompresi Cadangan (Transact-SQL).

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:

  • Penghitung kinerja I/O Windows, seperti penghitung disk fisik

  • Penghitung Byte Throughput Perangkat/detik dari objek SQLServer:Backup Device

  • Penghitung Throughput/detik Pencadangan/Pemulihan dari objek SQLServer:Databases

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 Pencadangan 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 lebih terkompresi dibandingkan 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 jauh lebih sedikit terkompresi dibandingkan dengan data tidak terenkripsi yang setara. Jika enkripsi data transparan digunakan untuk mengenkripsi seluruh database, mengompresi cadangan mungkin tidak mengurangi ukurannya, jika sama sekali.

  • Apakah database dikompresi.

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

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 untuk mengalokasikan terlebih dahulu 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. Trace flag 3042 menyebabkan proses pencadangan melewati algoritma pra-alokasi kompresi cadangan yang biasanya digunakan. 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

Lihat Juga

Ikhtisar Pencadangan (SQL Server)
Trace Flag (Transact-SQL)

  • Last updated on