Melihat Kinerja Cuplikan Basis Data

Snapshot database menyediakan tampilan baca-saja database SQL Server yang konsisten secara transaksional dengan status database sumber pada saat snapshot database dibuat. Ada sejumlah alasan untuk menggunakan snapshot database, misalnya pelaporan terhadap database cermin, dan DBCC CHECKDB juga menggunakan snapshot database internal dari SQL Server 2005 dan seterusnya.

Snapshot database juga menyediakan kemampuan untuk mengembalikan semua perubahan yang telah terjadi pada database sejak snapshot database dibuat, tetapi dengan efek samping yang buruk pada log transaksi database yang ditulis oleh Paul di sini.

Salah satu hal yang biasanya tidak dipertimbangkan atau ditampilkan di sekitar snapshot database adalah dampak kinerja yang dimiliki snapshot tersebut untuk beban kerja penulisan database. Tim SQLCAT menerbitkan whitepaper untuk SQL Server 2005, Pertimbangan Kinerja Cuplikan Basis Data di bawah Beban Kerja Intensif I/O, yang menyelidiki dampak kinerja cuplikan basis data, dan setelah bekerja dengan klien baru-baru ini di mana cuplikan basis data mengakibatkan masalah kinerja, saya ingin uji SQL Server 2012 dan tentukan apakah ada perubahan pada overhead snapshot database tujuh tahun dan tiga rilis SQL Server kemudian.

Konfigurasi Uji

Untuk melakukan pengujian efek snapshot database pada kinerja beban kerja tulis, saya menggunakan Dell R720 kami untuk melakukan penyisipan 1.000.000 baris ke tabel baru dalam versi database AdventureWorks2012 yang diperbesar. Database AdventureWorks2012 dibuat dengan 8 file data yang tersebar di dua SSD Fusion-io ioDrive Duo 640GB yang masing-masing disiapkan sebagai dua disk 320GB individual di Windows, menghadirkan total 4 disk. Untuk menyederhanakan penjelasan konfigurasi, tata letak penyimpanan yang digunakan untuk pengujian ini ditunjukkan pada tabel di bawah ini:

Tabel 1 – Tata Letak dan Penggunaan Disk Server

Penyimpanan untuk snapshot database adalah larik RAID-5 dari enam drive SAS 15k RPM yang terhubung melalui iSCSI, atau kartu PCI-E LSI Nytro BLP4-1600.

Beban kerja pengujian menggunakan pernyataan SELECT INTO berikut untuk menghasilkan tabel baris 1.000.000 yang dijatuhkan di antara setiap pengujian.

SELECT TOP 1000000 *
INTO tmp_SalesOrderHeader
FROM Sales.SalesOrderHeaderEnlarged;

Pengujian diatur waktunya untuk mengukur durasi tanpa snapshot database, dan kemudian durasi dengan snapshot database yang dibuat pada setiap perangkat penyimpanan untuk mengukur penurunan kinerja yang disebabkan oleh penulisan perubahan halaman ke file snapshot database yang jarang. Pengujian juga dijalankan menggunakan dua snapshot database pada perangkat penyimpanan yang sama untuk memastikan biaya tambahan dari snapshot database tambahan untuk operasi tulis duplikat yang berpotensi harus dilakukan.

Hasil

Setiap konfigurasi pengujian dieksekusi sepuluh kali dan durasi rata-rata, dikonversi dari milidetik ke detik agar lebih mudah dilihat, ditunjukkan pada Gambar 1, untuk snapshot database 0, 1, atau 2.

Gambar 1 – Durasi Cuplikan

Tes dasar tanpa snapshot database yang dieksekusi rata-rata dalam 1,8 detik, dan bahkan ketika penyimpanan untuk file snapshot database memiliki kinerja yang setara, keberadaan snapshot database tunggal membebani kinerja tulis database. Overhead snapshot database kedua lebih rendah daripada snapshot database pertama di setiap pengujian, meskipun disk 15K RPM memiliki waktu yang jauh lebih sulit untuk mengimbangi beban kerja tulis tambahan dari snapshot database kedua untuk database.

Performa pada kartu Nytro LSI awalnya mengejutkan saya karena ini juga merupakan SSD PCI-X. Namun, setelah mendiskusikan hasilnya dengan Glenn, dia menyebutkan bahwa kompresi pengontrol Sandforce dan kinerja penulisan yang lebih lambat untuk data acak dan kompresi rendah dari pengujian sebelumnya pada drive. Namun, itu masih dengan mudah mengungguli media pemintalan.

Sebelum menjalankan pengujian, saya tertarik untuk mengetahui tipe tunggu apa yang akan terjadi selama pengujian, jadi sebagai bagian dari konfigurasi pengujian, saya menghapus sys.dm_os_wait_stats dengan DBCC SQLPERF dan menangkap output dari DMV untuk setiap pengujian yang dijalankan ke dalam tabel. Penantian teratas untuk konfigurasi snapshot tunggal adalah PREEMPTIVE_OS_WRITEFILE dan WRITE_COMPLETION seperti yang ditunjukkan pada Gambar 2, untuk 1 atau 2 snapshot database.

Gambar 2 – Cuplikan Gambar Menunggu

Salah satu item yang menarik adalah penambahan FCB_REPLICA_WRITE menunggu saat snapshot kedua dibuat. Setelah meninjau hasil tunggu snapshot database tunggal, dan menjalankan kembali beberapa putaran pengujian, penantian ini tidak pernah terjadi untuk snapshot tunggal dan hanya terjadi jika ada lebih dari satu snapshot dan dikaitkan dengan penyalinan halaman ke file snapshot database. Waktu tunggu untuk PREEMPTIVE_OS_WRITEFILE tren menunggu erat dengan peningkatan durasi eksekusi untuk setiap konfigurasi.

Dengan mempertimbangkan hasil ini, saat meninjau sistem menggunakan metodologi Waits and Queues, melihat tipe wait ini dengan nilai yang lebih tinggi mungkin perlu diselidiki apakah snapshot database ada atau tidak untuk database mana pun di server.

Kesimpulan

Saat menggunakan snapshot database, bahkan di SQL Server 2012, ada overhead yang terkait dengan penulisan tambahan yang diperlukan untuk menyalin halaman data ke file sparse untuk snapshot. Jika menggunakan snapshot database adalah bagian dari konfigurasi umum Anda, saya akan sangat berhati-hati dalam merencanakan subsistem I/O untuk memenuhi persyaratan beban kerja untuk aktivitas I/O bersamaan ke file sparse snapshot database.

Dari hasil pengujian ini, saya bahkan mempertimbangkan untuk menempatkan snapshot database pada SSD di atas tempdb untuk kinerja tulis, dan juga untuk dampak kinerja yang lebih rendah dari pemeliharaan snapshot.

Seperti biasa, jarak tempuh Anda mungkin berbeda, dan Anda pasti ingin menguji kinerja konfigurasi apa pun sebelum menggunakannya untuk produksi.