Log dan drive data memiliki pola akses data yang berbeda yang bertentangan satu sama lain (setidaknya secara teori) saat mereka berbagi drive.
Menulis Log
Akses log terdiri dari sejumlah besar penulisan sekuensial kecil. Secara sederhana, log DB adalah buffer cincin yang berisi daftar instruksi untuk menulis item data ke lokasi tertentu pada disk. Pola akses terdiri dari sejumlah besar penulisan sekuensial kecil yang harus dijamin selesai - sehingga ditulis ke disk.
Idealnya, log harus dalam volume yang tenang (mis. Tidak dibagikan dengan yang lain) RAID-1 atau RAID-10. Secara logis, Anda dapat melihat proses sebagai DBMS utama yang menulis entri log dan satu atau lebih utas pembaca log yang menggunakan log dan menulis perubahan ke disk data (dalam praktiknya, proses ini dioptimalkan sehingga penulisan data dituliskan segera keluar jika memungkinkan). Jika ada lalu lintas lain pada log disk, kepala dipindahkan oleh akses lain ini dan menulis log berurutan menjadi menulis log acak. Ini jauh lebih lambat, jadi disk log yang sibuk dapat membuat hotspot yang bertindak sebagai hambatan pada keseluruhan sistem.
Menulis data
(Diperbarui) Penulisan log harus dilakukan ke disk (disebut media stabil) agar transaksi valid dan memenuhi syarat untuk dikomit. Orang dapat secara logis melihat ini sebagai entri log yang sedang ditulis dan kemudian digunakan sebagai instruksi untuk menulis halaman data ke disk dengan proses asinkron. Dalam prakteknya halaman disk menulis sebenarnya disiapkan dan buffer pada saat entri log dibuat, tetapi mereka tidak perlu dituliskan segera untuk transaksi yang akan dilakukan. Buffer disk ditulis ke media stabil (disk) oleh proses Lazy Writer (Terima kasih kepada Paul Randal untuk menunjukkan ini) yang dibahas dalam artikel Technet ini sedikit lebih detail.
Ini adalah pola akses yang sangat acak, sehingga berbagi disk fisik yang sama dengan log dapat membuat hambatan buatan pada kinerja sistem. Entri log harus ditulis agar transaksi dapat dilakukan, sehingga memiliki pencarian acak memperlambat proses ini (I / O acak jauh lebih lambat daripada log berurutan I / O) akan mengubah log dari sekuensial menjadi perangkat akses acak. Ini menciptakan hambatan kinerja yang serius pada sistem yang sibuk dan harus dihindari. Hal yang sama berlaku ketika berbagi area sementara dengan volume log.
Peran caching
Pengontrol SAN cenderung memiliki cache RAM yang besar, yang dapat menyerap lalu lintas akses acak hingga batas tertentu. Namun, untuk integritas transaksional, diinginkan untuk menulis disk dari DBMS yang dijamin lengkap. Ketika pengontrol diatur untuk menggunakan cache tulis-kembali, blok-blok yang kotor di-cache dan panggilan I / O dilaporkan selesai ke host.
Ini dapat memuluskan banyak masalah pertengkaran karena cache dapat menyerap banyak I / O yang seharusnya keluar ke disk fisik. Itu juga dapat mengoptimalkan paritas membaca dan menulis untuk RAID-5, yang mengurangi efek pada kinerja yang memiliki volume RAID-5.
Ini adalah karakteristik yang mendorong aliran pemikiran 'Biarkan SAN menghadapinya', meskipun pandangan ini memiliki beberapa keterbatasan:
Cache Write-back masih memiliki mode kegagalan yang dapat kehilangan data, dan controller telah bersatu ke DBMS, mengatakan blok telah ditulis ke disk di mana sebenarnya mereka belum. Untuk alasan ini, Anda mungkin tidak ingin menggunakan cache tulis-balik untuk aplikasi transaksional, terutama sesuatu yang menyimpan data mission-critical atau keuangan di mana masalah integritas data dapat memiliki konsekuensi serius bagi bisnis.
SQL Server (khususnya) menggunakan I / O dalam mode di mana bendera (disebut FUA atau Akses Pembaruan Paksa) memaksa penulisan fisik ke disk sebelum panggilan kembali. Microsoft memiliki program sertifikasi dan banyak vendor SAN menghasilkan perangkat keras yang menghormati semantik ini (persyaratan dirangkum di sini ). Dalam hal ini tidak ada jumlah cache yang akan mengoptimalkan penulisan disk, yang berarti bahwa lalu lintas log akan gagal jika duduk pada volume bersama yang sibuk.
Jika aplikasi menghasilkan banyak lalu lintas disk yang set kerjanya dapat menyerbu cache, yang juga akan menyebabkan masalah pertentangan penulisan.
Jika SAN digunakan bersama dengan aplikasi lain (khususnya pada volume disk yang sama), lalu lintas dari aplikasi lain dapat menghasilkan kemacetan log.
Beberapa aplikasi (mis. Gudang data) menghasilkan lonjakan beban transien besar yang membuatnya sangat anti-sosial pada SAN.
Bahkan pada volume log terpisah SAN yang besar masih disarankan. Anda mungkin tidak perlu khawatir tentang tata letak pada aplikasi yang sedikit digunakan. Pada aplikasi yang sangat besar, Anda bahkan dapat memperoleh manfaat dari beberapa pengontrol SAN. Oracle menerbitkan serangkaian studi kasus tata letak gudang data di mana beberapa konfigurasi yang lebih besar melibatkan banyak pengontrol.
Tanggung jawab atas kinerja di mana tempatnya
Pada sesuatu dengan volume besar atau di mana kinerja dapat menjadi masalah, buat tim SAN bertanggung jawab atas kinerja aplikasi. Jika mereka akan mengabaikan rekomendasi Anda untuk konfigurasi, maka pastikan bahwa manajemen mengetahui hal ini dan bahwa tanggung jawab untuk kinerja sistem berada di tempat yang tepat. Secara khusus, buat pedoman yang dapat diterima untuk statistik kinerja utama DB seperti I / O menunggu atau menunggu halaman latch atau I / O SLA aplikasi yang dapat diterima.
Perhatikan bahwa memiliki tanggung jawab untuk pemisahan kinerja di beberapa tim menciptakan insentif untuk titik-jari dan meneruskan tanggung jawab kepada tim lain. Ini adalah anti-pola manajemen yang dikenal dan formula untuk masalah yang keluar selama berbulan-bulan atau bertahun-tahun tanpa pernah diselesaikan. Idealnya, harus ada satu arsitek dengan wewenang untuk menentukan perubahan aplikasi, database, dan konfigurasi SAN.
Juga, patok sistem di bawah beban. Jika Anda dapat mengaturnya, server bekas dan array pemasangan langsung dapat dibeli dengan cukup murah di Ebay. Jika Anda mengatur kotak seperti ini dengan satu atau dua array disk, Anda dapat menggunakan konfigurasi disk fisik dan mengukur efeknya pada kinerja.
Sebagai contoh, saya telah melakukan perbandingan antara aplikasi yang berjalan pada SAN besar (IBM Shark) dan kotak dua-soket dengan lampirkan U320 array langsung. Dalam hal ini, perangkat keras senilai £ 3.000 yang dibeli dari ebay mengungguli SAN high-end £ 1 juta dengan faktor dua - pada host dengan konfigurasi CPU dan memori yang kira-kira setara.
Dari kejadian khusus ini, dapat dikatakan bahwa memiliki sesuatu seperti ini adalah cara yang sangat baik untuk menjaga administrator SAN jujur.