Menempatkan Oracle redo log pada DRAM SSD untuk database tulis yang berat?

Saya memiliki Sun M4000 yang terhubung ke array EMC CX4-120 dengan database tulis-berat. Menulis puncak pada sekitar 1200 IO / s dan 12MB / s.

Menurut EMC, saya menjenuhkan cache tulis pada array EMC.

Saya pikir solusi paling sederhana adalah memindahkan redo log ke SSD berbasis DRAM. Ini akan mengurangi beban pada array EMC hingga setengahnya dan aplikasi tidak akan melihat menunggu buffer log. Ya, DBWR dapat menjadi hambatan, tetapi aplikasi tidak akan menunggu untuk itu (seperti yang mereka lakukan pada komitmen ulang!)

Saat ini saya menelusuri sekitar 4 4GB redo log, jadi bahkan 20GB atau lebih dari SSD akan membuat perbedaan besar. Karena ini adalah penyimpanan jangka pendek dan terus-menerus ditimpa, SSD berbasis Flash mungkin bukan ide bagus.

M4000 tidak memiliki banyak drive ekstra, jadi kartu PCI-E akan sempurna, saya bisa pergi eksternal atau memindahkan volume boot ke EMC dan membebaskan drive lokal.

Sun menjual kartu PCIe Flash Accelerator F20, tetapi itu tampaknya menjadi cache untuk beberapa disk SATA, bukan solusi DRAM SSD. Detailnya tidak jelas, tidak mencantumkan M4000 sebagai yang didukung, dan saya lelah melawan pohon telepon Sun untuk mencari bantuan manusia. :(

Apakah orang lain setuju bahwa DRAM SSD adalah jalan yang harus ditempuh? Adakah rekomendasi perangkat keras?

UPDATE Selain info dalam komentar di bawah, saya mencoba berbagai pengaturan untuk "commit_write" dan itu tidak membuat perbedaan.

Pertama - saya kira Anda memiliki sangat sedikit disk dalam array. 1200IOPS dapat dengan mudah didukung menjadi 12 disk berputar (100 IOPS per disk sangat masuk akal). Jika cache tidak dapat mengatasinya, itu berarti laju tulis Anda yang berkelanjutan sebesar 1200 IOPS jauh lebih banyak daripada yang dapat didukung oleh disk Anda.

Lagi pula, SSD untuk redo log tidak mungkin membantu. Pertama, apakah sesi Anda sebagian besar menunggu pada pernyataan COMMIT? Periksa acara tunggu teratas di statspack / AWR untuk memverifikasi. Saya kira ~ 95% dari I / O Anda bukan untuk redo log sama sekali. Misalnya, satu baris dimasukkan ke tabel dengan 5 indeks dapat melakukan 1 I / O untuk membaca blok tabel (yang memiliki ruang untuk baris), membaca 5 blok indeks (untuk memperbaruinya), menulis 1 blok data, 1 membatalkan blok dan 5 blok indeks (atau lebih, jika blok non-daun diperbarui) dan 1 blok ulang. Jadi, periksa statspack dan lihat acara tunggu Anda, Anda kemungkinan menunggu banyak BACA dan MENULIS untuk data / indeks. Menunggu pembacaan memperlambat INSERT, dan aktivitas WRITE membuat READ lebih lambat - ini adalah disk yang sama (BTW - apakah Anda benar-benar membutuhkan semua indeks? Menjatuhkan mereka yang tidak harus memiliki akan mempercepat sisipan).

Hal lain yang perlu diperiksa adalah definisi RAID - apakah itu RAID1 (mirroring - setiap penulisan adalah dua tulisan) atau RAID 5 (setiap penulisan adalah 2 kali dibaca dan dua tulisan untuk perhitungan checksum). RAID 5 jauh lebih lambat dalam hal penulisan intensif.

BTW - jika disk tidak dapat mengatasi beban tulis, DBWR akan menjadi hambatan. SGA Anda akan penuh dengan blok kotor, dan Anda tidak akan memiliki ruang tersisa untuk membaca blok baru (seperti blok indeks yang perlu diproses / diperbarui) sampai DBWR dapat menulis beberapa blok kotor ke disk. Sekali lagi, periksa statspack / awr report / addm untuk mendiagnosis apa yang menjadi hambatan, biasanya berdasarkan pada 5 acara tunggu teratas.

dd tidak seberapa dibandingkan dengan blok i / o.

Untuk beberapa pandangan lain, periksa sekitar, anandtech.com melakukan tes exaustive (diberikan dengan server MS SQL) dengan SAS berputar vs SSD, dalam berbagai kombinasi, dan dunia Solaris memiliki ZFS dengan SSD membuat berbagai bagian (log, cache, dll. ).

Tapi ya, jika RAID 5 vs RAID 10 adalah sama (untuk menulis), Anda melakukan sesuatu yang salah. Dengan penulisan linear, heck RAID 5 bisa lebih cepat (yaitu dapat melakukan paritas dalam memori, kemudian menulis garis dan paritas sekaligus), tetapi dengan blok kecil acak (4-8k), Anda terbunuh dengan memperbarui garis (seperti dicatat oleh orang lain), serangan 10 harus lebih dari 2x lebih cepat, jika tidak, ada sesuatu yang salah.

Anda perlu menggali lebih dalam, sebelum Anda menghabiskan uang untuk perangkat keras.

Saya melihat posting tentang pemasangan partisi UFS menggunakan opsi "forcedirectio" dan mengatur parameter Oracle "filesystemio_options" menjadi "setall".

Saya mencobanya dan melihat peningkatan 4-5x dalam Oracle menulis! Ya!

Gejala utama adalah throughput rendah tetapi waktu respons yang baik pada disk. Ini tampaknya membantu beberapa orang tetapi tidak yang lain. Ini tentu saja berhasil bagi saya.

Saya dapat mempertimbangkan SSD untuk server baru, tetapi server ini berjalan dengan baik sekarang.

Robert

Jika kotak ini hanya berupa kotak x86 / 64 yang menjalankan linux, saya dengan senang hati merekomendasikan salah satu kartu drive FusionIO PCIe - kartu-kartu itu luar biasa cepat dan tidak 'mati' dengan tulisan yang berat seperti SSD. Sayangnya mereka tidak didukung dengan Sparc atau Solaris, Anda mungkin ingin menghubungi mereka untuk membahas hal ini.

Kartu PCIe F20e mirip dengan fungsi Fusion I / O. Ini pada dasarnya hanya PCIe Flash SSD yang terpasang. Dengan menulis beban kerja yang berat, Anda harus khawatir tentang menjaga cukup blok gratis (melalui pengumpulan sampah berbasis drive dari beberapa jenis) sehingga Anda tidak berakhir dengan siklus Erase / Program pada SSD yang menjadi hambatan, serta siklus tulis terbatas yang tersedia pada SSD berbasis Flash. Ini benar-benar cepat, tetapi mungkin bukan kit terbaik untuk pekerjaan ini.