MSSQL Server’da Compress Backup

SQL Server’da Backup Compression (Yedek Sıkıştırma), veritabanı yedeklerinin boyutunu küçültmek ve yedekleme süresini kısaltmak için kullanılan en kritik özelliklerden biridir. İlk olarak SQL Server 2008 Enterprise sürümüyle gelmiş, 2008 R2 sürümünden itibaren ise Standard sürümde de kullanılabilir hale gelmiştir.

SQL Server, yedekleme sırasında verileri diske yazmadan önce bir sıkıştırma algoritmasından geçirir. Bu işlem CPU üzerinde ek bir yük oluştursa da, diske yazılan veri miktarı (I/O) ciddi oranda azaldığı için toplam yedekleme süresi genellikle kısalır.

Avantajları:

  • Yedek dosyaları genellikle %70 ile %90 oranında daha az yer kaplar.
  • Diske yazılan veri azaldığı için I/O darboğazı aşılır ve işlem daha hızlı tamamlanır.
  • Daha az disk alanı kullanımı, özellikle bulut depolama veya uzak sunucu yedeklemelerinde maliyeti düşürür.

Dezavantajları:

  • Sıkıştırma işlemi işlemciye ek yük bindirir. Eğer sunucunuzda CPU kullanımı zaten %80-90 seviyelerindeyse, yedekleme sırasında performans sorunları yaşanabilir.
  • Sıkıştırılmış bir yedek, bu özelliği desteklemeyen daha eski veya alt sürüm bir SQL Server’a geri yüklenemez.

Veritabanına sağ tıklayıp Tasks > Back Up kısmına tıklanır. Gelen ekranda sol kısımda bulunan Options sekmesine girilir. Compression başlığı altındaki açılır menüden Compress backup seçeneğini seçilir.

Burada 3 seçenek karşımıza çıkmaktadır. İnstance seviyesinde hangi ayar yapılmışsa o ayarın kullanması isteyebiliriz. Bunun için Use the default server setting kısmının işaretlenmesini sağlayabiliriz. Default olarak gelen değerde budur. Kurulu olan instance Properties kısmına girilir. Gelen ekranda Database Settings kısmından Compress Backup checkbox’ı işaretlenir. Bu seçenek yukarıda belirtilen Use the default server setting kısmındaki değerdir.

Backup arayüzün de default olarak bırakmış olsaydık full backup’ı sıkıştırarak almamış olacaktı. Backup arayüzün de compress backup ibaresini seçiyoruz. Bu ifade ne kadar boyutu düşürse de CPU’ya ekstra bir yük getirmektedir. Eğer herhangi bir ifade seçmesini istemiyorsak Do not compress backup seçmemiz gerekiyordu.

İnstance properties kısmında Database Settings kısmından yapmayıp sp_configure makalesinden bu işlemin nasıl yapıldığını görebilirsiniz. Bu iki yöntemle yapılması her backup alırken manuel seçmemize gerek kalmayacaktır.

Bir yedeği sıkıştırılmış olarak almak için komutun sonuna COMPRESSION anahtar kelimesini eklemeniz yeterlidir.

BACKUP DATABASE [SatisDB]
TO DISK = 'D:\Backups\SatisDB_Compressed.bak'
WITH COMPRESSION, STATS = 10;

Not: Sql server verileri sıkıştırırken hangi teknolojileri kullandığı genellikle açıklanmaz. Temel prensip LZ tabanlı veri farkı sıkıştırmasıdır.(pattern matching+run-length) Sql serverın veri sıkıştırırken kullandığı benzer teknolojiler LZ77 ve Deflate benzeri yapıyı kullanmaktadır.

Önceden compression olmayan bir backup’ın üzerine compression şeklinde backup almak istersek hata ile karşılaşırız. Aşağıda ilgili resmi görebilirsiniz.

Aşağıdaki komut ile alınmış olan backup’ların gerçek boyutunu ve sıkıştırılmış halini görebiliriz.

select name, backup_size,compressed_backup_size,*from msdb..backupset

Aşağıdaki komut ile backup başlangıç-bitiş tarihini veritabanı gerçek boyutunu ve sıkıştırıldıktan sonraki boyutu görebiliriz. Byte cinsinden boyutunu vermektedir.

SELECT backup_start_date,backup_finish_date, backup_size,compressed_backup_size
FROM MSDB..backupset WHERE database_name='AdventureWorks2014' order by backup_finish_date desc

Sıkıştırılmış yedekleme (Compressed Backup) işlemi sırasında SQL Server şu aşamalardan geçer:

1. Okuma Aşaması (Source)

SQL Server, veritabanı dosyalarından (.mdf ve .ndf) veriyi okumaya başlar. Veritabanınız 10 GB ise, SQL Server her halükarda 10 GB’lık veriyi okumak zorundadır. Sıkıştırma işlemi okuma aşamasında değil, veriler bellekten diske yazılmadan hemen önce gerçekleşir.

  • Okunan miktar: 10 GB.
  • Yük bindirdiği yer: Disk Okuma (Read I/O).

2. İşleme Aşaması (Memory & CPU)

Disklerden okunan veri paketleri (Extent’ler) sunucunun RAM’ine (Buffer Pool) alınır. Burada SQL Server’ın sıkıştırma algoritması devreye girer:

  • Veri paketleri işlemciye (CPU) gönderilir.
  • CPU, bu verileri analiz eder ve tekrarlayan desenleri bularak sıkıştırır.
  • Yük bindirdiği yer: İşlemci (CPU). İşte bu yüzden sıkıştırma açıkken CPU kullanımında bir miktar artış görürsünüz.

3. Yazma Aşaması (Target)

Sıkıştırma işlemi RAM’de tamamlandıktan sonra, artık elimizde 10 GB değil (örneğin) 2 GB’lık bir veri bloğu kalır. SQL Server sadece bu 2 GB’ı yedekleme dosyasına (.bak) yazar.

  • Yük bindirdiği yer: Disk Yazma (Write I/O).
  • Yazılan miktar: ~2 GB (Sıkıştırma oranına göre değişir).

Yedek almaya başlamadan önce hedef diskte 10 GB yer olmasına gerek yoktur. SQL Server tahmini bir boyutla başlar ve sadece sıkıştırılmış veri kadar alan kaplar.

Sıkıştırma Mantığı Nasıldır(Desen Arama)

Sıkıştırma algoritmaları (ZIP, RAR veya SQL Server Compression), verinin içindeki tekrarları arar.

  • Bir tabloda “Ankara” kelimesinin 1.000 kere geçtiğini düşünelim. Sıkıştırma algoritması şunu der: “Ben ‘Ankara’ kelimesini 1 kere kaydedeyim, yanına da ‘bundan 1.000 tane var’ notu düşeyim.” * Böylece 10 GB’lık veri, tekrarlar ayıklandığı için 2 GB’a düşer.

SQL Server’da bu işin iki farklı seviyesi vardır. Senin anlattığın örnek, SQL Server’ın hem Yedekleme (Backup) hem de Tablo/Sayfa (Page) sıkıştırmasında kullandığı temel mantıktır.

SQL Server, verinin içinde sık geçen ifadeleri tespit eder ve bir “Sözlük” (Dictionary) oluşturur.

  • Ham Veri: Ankara, Ankara, İstanbul, Ankara, İzmir…
  • Sözlük: 1 = Ankara, 2 = İstanbul, 3 = İzmir
  • Sıkıştırılmış Veri: 1, 1, 2, 1, 3…

Diske Ankara (6 karakter) yazmak yerine sadece 1 (birkaç bit) yazar. Aradaki fark devasadır!

Tablo içinde sadece kelimeler değil, sayısal veriler veya tarihler de benzerdir. SQL Server, bir sayfa (Page – 8KB’lık veri blokları) içindeki ortak ön ekleri (prefix) bulur.

Örnek:

  • Veri 1: 2024-05-10
  • Veri 2: 2024-05-11
  • Veri 3: 2024-05-12

SQL Server der ki: “Bu sayfadaki herkes 2024-05- ile başlıyor. Ben bunu bir kere en başa yazayım, geri kalanlara sadece son haneleri (10, 11, 12) kaydedeyim.”

TDE (Transparent Data Encryption), veriyi diske yazarken “karıştırır”. Şifrelemenin amacı veriyi okunmaz hale getirmektir.

  • Şifreli Veri: Sen “Ankara” yazarsın, ama TDE bunu diskte Xy9!zLp2@… gibi tamamen rastgele görünen bir karaktere dönüştürür.
  • Aynı “Ankara” kelimesi ikinci kez şifrelendiğinde, güvenlik gereği farklı bir karmaşaya dönüşebilir. Sonuçta ortaya çıkan veri yığını içinde hiçbir tekrarlayan desen (pattern) kalmaz.

SQL Server yedek alırken veriye bakar:

  1. Sıkıştırma Motoru: “Hey, burada birbirine benzeyen veri var mı?” diye sorar.
  2. TDE’li Veri: “Hayır, her şey birbirinden farklı ve karmaşık.” cevabını verir.
  3. Sonuç: Sıkıştırma motoru birbirine benzeyen bir şey bulamadığı için veriyi küçültemez. 10 GB’lık “karman çorman” veriyi olduğu gibi, yani yine 10 GB olarak diske yazar.

Bu makalede mssql server üzerinde compress yapısını detaylı bir şekilde görmüş olduk. Başka makalede görüşmek dileğiyle..

Alçak gönüllü şekilde yürüyün. Furkan-63

Author: Yunus YÜCEL

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir