Home > Compression, SQL Server 2008 > SQL Server 2008 Backup Compression Performance

SQL Server 2008 Backup Compression Performance

U prethodnom postu pisala sam o kompresiji backupa, novoj funkcionalnosti SQL Servera. Tu su date osnove vezane za kompresiju backupa, kako uključiti kompresiju backupa na nivou instance, za svaki pojedinačni backup kao i neke karakteristike vezane za media set prilikom kompresije. U ovom postu pokazati ću usporedne rezultate performansi do kojih sam došla testiranjem backup i restore operacija kompresovanog/nekompresovanog backupa.

Testiranje backup operacije AdventureWorks2008R2 baze

Prvi test sam napravila korištenjem AdventureWorks2008R2 baze na klijentskoj mašini. Rezultat je sljedeći:

Nekompresovani backup je urađen za 5.442 sekunde, veličina backupa je 213MB a CPU je bio zauzet oko 16%.

Kompresovani backup je urađen za 2.849 sekundi, veličina backupa je 49MB a CPU je bio zauzet oko 29%.

Vidljivo je, da su performanse kompresovanog backup daleko bolje. Kompresovani backup je 4.34 puta manji od nekompresovanog backupa. Za očekivati je i da je vrijeme izvršenja kompresovanog backupa kraće (zbog mnogo manje količine IO operacija) što se i pokazalo testom. Ali opterećenost CPU-a je bila veća.

Testiranje restore operacije AdventureWorks2008R2 baze

Prije testa očekivala sam i da će restore operacije kompresovanog backupa biti bolje što se i pokazalo u testu. Rezultat je sljedeći:

Verifikacija backupa:

Baza

Vrsta backupa Vrijeme (sekundi)
AdventureWorks2008R2

Nekompresovani

1.703

AdventureWorks2008R2 Kompresovani

0.403

Restore baze (baza je već postojala na serveru):

Baza

Vrsta backupa Vrijeme (sekundi) CPU %
AdventureWorks2008R2

Nekompresovani

4.649

5.5

AdventureWorks2008R2

Kompresovani 2.663

9.5

Testiranje TestDB baze (26GB) na serveru

Sljedeći test je rađen na serveru s bazom veličine oko 26 GB. Rezultat je sljedeći.

Baza

Vrsta backupa Veličina backupa Vrijeme (mm:ss)

Omjer kompresije

TestDB

Nekompresovani

25.8 GB 03:36

1

TestDB

Kompresovani

5.97 GB 02:03

4.32

Opterećenost CPU-a prilikom kreiranja kompresovanog backupa veća je za 5-6%.

Verifikacija backupa za nekompresovani backup završena je za 1 minutu i 15 sekundi dok je za kompresovani backup završena za 41 sekundu.

Kompresija podataka i kompresija backupa

Kako SQL Server 2008 omogućava kompresije podataka na nivou reda (row) ili stranice (page), zanimalo me je kako kompresija backupa radi u kombinaciji sa kompresijom podataka (row or page compression).

Napravila sam test na mojoj klijentskoj mašini, i to tako da sam prilikom testiranja koristila bazu kod koje sam izvršila kompresiju svih tabela i indeksa. Rezultat je sljedeći:

Baza

Veličina baze

Veličina Backupa

Omjer kompresije

Backup Time (sekundi)

Vrsta backupa

Bez kompresije podataka

TestDb 168 MB 168 MB

1

4.453

Nekompresovani backup
TestDb 168 MB 48 MB

3.49

2.787

Kompresovani backup

Row Compression

TestDb 115 MB 115 MB

1

3.034

Nekompresovani backup
TestDb 115 MB 44 MB

2.61

2.237

Kompresovani backup

Page Compression

TestDb 72 MB 72 MB

1

2.195

Nekompresovani backup
TestDb 72 MB 41 MB

1.75

1.903

Kompresovani backup

Iz rezultata je vidljivo, da kompresija backupa komprimira i baze kod kojih su sve tabele i indeksi kompresovani row ili page kompresijom iako je omjer kompresije kompresovanog/nekompresovanog backupa manji nego kod baze kod koje nije uključena kompresija podataka. Vrijeme izvršenja kompresovanog backupa je kraće. Opterećenost CPU-a je veća prilikom kreiranja kompresovanog backupa.

TDE (Transparent Data Encryption) i kompresija backupa

Zanimalo me je i kakve su performanse kompresije backupa za baze kod kojih je uključen TDE. Rezultat je sljedeći:

Baza Veličina baze Veličina Backup

Omjer
kompresije

Backup Time
(sekundi)

Komentar
Test (TDE on) 222 MB 222 MB

1

4.199

Nekompresovani backup
Test (TDE on) 222MB 221 MB

1

4.218

Kompresovani backup

Kompresija backupa baza kod koje je uključen TDE rezultira visokim korištenje CPU-a, izvršenje kompresovanog backupa traje neznatno duže a gotovo da i nema razlike između veličine kompresovanog i nekompresovanog backupa.
Kompresija enkriptiranih podataka nije baš dobar izbor, tako da kompresiju backupa treba izbjegavati ukoliko imate bazu kod koje je uključen TDE.

Zaključak:
Vidljivo je da kreiranjem kompresovanog bakupa štedimo i prostor i vrijeme ali je CPU malo više opterećen prilikom izrade kompresovanog backupa. Ukoliko je CPU na serveru dosta opterećen a radite kompresovani backup tokom radnog vremena i ne želite da vam on ometa ostale operacije na serveru, korištenje CPU-a prilikom kompresije backupa moguće je ograničiti s Resource Governor-om.
Kompresija backupa je odlična izbor i za baze koje imaju uključenu kompresiju podataka (row ili page) dok bi se trebala izbjegavati za baze kod kojih je uključen TDE.
Oni koji koriste Log Shipping dobro mogu osjetiti poboljšanje performansi ukoliko uključe backup kompresiju, jer Log Shipping radi na principu kreiranja backupa, kopiranja backupa na network share lokaciju (obično na sekundarni server) i nakon toga restore backupa na sekundarnom serveru. Treba jedino obratiti pažnju na CPU, a ukoliko se primijeti  bottleneck ograničiti korištenje CPU-a za backup korištenjem Resource Governor -a.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: