Bagaimana cara mengkonfigurasi disk ini pada SQL Server untuk konfigurasi BI?

Dengan asumsi memori konstan (32gb) dan CPU (4), 2 x array disk, saya memiliki disk berikut

2 x 150 (10k)
6 x 150 (15 rb)

Itu semua adalah disk lokal.

Persyaratan saya

DB saya 350gb dan disetel ke pertumbuhan standar 10%
OS & SQL Server saya adalah Server 2k8R2 (C: drive OS + halaman + aplikasi = 55Gb)
Persyaratan log sekitar 70 GB dan diatur ke pertumbuhan standar 10% dan secara rutin dipotong
TempDb saya sekitar 12gb saat ini dan diatur ke pertumbuhan standar 10%

Masalah saya adalah bahwa saya mencoba untuk memahami di mana sebaiknya meletakkan TempDB dan OS dan Log. Pengalaman saya terbatas dalam konfigurasi optimal keduanya

Ini bukan sistem transaksi online. Ini memiliki data berat menulis (data baru + indeks membangun kembali / reorg) kemudian membaca data berat (saya memperkirakan sekitar 50/50) pemrosesan selama sekitar 13 jam, dan kemudian hanya diam.

Pemahaman saya adalah bahwa TEMPDB banyak digunakan selama pemrosesan normal dibandingkan dengan log.

Ide saya adalah sebagai berikut

2 x 150g (15k) Raid 1 = 150g untuk OS + TempDB
2 x 150g (10k) Serangan 1 = 150g untuk LOG (perhatikan disk lebih lambat di sini)
4 x 150g (15k) Serangan 5 = 150g untuk data

Apakah ini terdengar seperti ide yang bagus? Saya kemudian bisa menukar Log + TempDB jika diperlukan.

Apakah saya melanggar aturan utama seperti tidak pernah meletakkan TempDB pada disk OS karena masalah paging , atau mungkin tidak pernah memasukkan log pada disk yang lebih lambat daripada data ?

Edit:

Kami juga memiliki SSAS pada sistem dan pengguna akhir hanya mengakses Cube. 50% baca di atas didasarkan pada waktu yang dibutuhkan untuk memproses database SSAS.

sql-server-2008-r2 business-intelligence disk-structures

— Praha Sangha
sumber

Jawaban:

2 * 10k RAID1 untuk OS, 6 * 15k RAID10 untuk yang lainnya. Jujur, dengan banyak disk 1 array ini adalah yang paling aman dan biasanya taruhan tercepat.

Jika Anda punya waktu untuk menguji dan memiliki dunia nyata, beban kerja yang berulang dan terukur, maka lakukan uji coba dengan tempdb di drive OS (peringatan: batasi pertumbuhan file tempdb untuk memastikan Anda tidak memercik OS) . Di sisi lain, Anda mungkin melihat peningkatan moderat untuk memuat data dan pemeliharaan dengan log di sana sebagai gantinya layak uji coba atau dua jika waktu memungkinkan.

— Mark Storey-Smith
sumber

Apakah ada yang bisa didapat dengan array tambahan? Haruskah TempDB tidak berada dalam set array / spindle terpisah? Saya memperkirakan 50/50 karena didasarkan pada 50% pemrosesan DW & 50% pemrosesan SSAS (6ish jam dibaca).

— Preet Sangha

Saya tidak melihat menyebutkan kubus layanan analisis dalam pertanyaan awal Anda. Apakah basis data relasional dan kubus dipertanyakan oleh pengguna akhir atau hanya kubus?

— Mark Storey-Smith

+1 Saya menyukai rekomendasi Anda. Perlu dicatat bahwa jika ia menaruh tempdb pada drive OS maka pasti akan membatasi ukuran maksimal untuk file database. Kita semua bisa sepakat bahwa kita tidak ingin file database jahat mengisi drive tertentu.

— Thomas Stringer

@PreetSangha Belief bukanlah dasar yang bagus untuk merencanakan penyebaran server atau penyimpanan. Anda perlu menginvestasikan waktu untuk meneliti dan memahami mengapa itu sesuai dalam beberapa skenario dan bukan yang lain. Memisahkan kubus Anda dari basis data relasional mungkin memiliki kaki di sini tetapi siapa yang tahu tanpa mengujinya. Tidak ada yang sulit dan cepat, satu ukuran cocok untuk semua, pendekatan JFDI untuk ini saya khawatir.

— Mark Storey-Smith

Jika Anda dapat menguji dan mengukur berbagai skenario dengan beban kerja Anda, itu mungkin terbukti tepat. Ketika / jika Anda tidak bisa, satu kolam besar penyimpanan secepat mungkin akan menyerap benjolan dan benjolan lebih baik daripada tembakan di split gelap. Jangan ragu untuk mengobrol jika Anda ingin memunculkan ide. Ada beberapa pelanggan tetap dengan pengalaman SSAS lebih dari saya yang mungkin memiliki saran untuk menentukan bagaimana / jika Anda harus memisahkan kubus dari database.

— Mark Storey-Smith

Saya setuju dengan Markus bahwa pendekatan yang ideal adalah menempatkan dua drive yang lebih lambat di RAID 1 hanya untuk O / S, dan sisanya dari drive di RAID 10 untuk yang lainnya. Itu akan ideal.

Namun, berdasarkan ukuran yang Anda berikan, ini cukup maksimal untuk Anda mulai, dengan sedikit margin untuk kesalahan, dan tidak ada ruang untuk pertumbuhan. Dan omong-omong, jika seseorang memberi tahu Anda drive 150 GB, mereka mungkin sebenarnya lebih kecil dari itu (146 GB?), Tidak diformat, yang kemungkinan berarti tidak semuanya akan langsung cocok.

Sayangnya, beban kerjanya melibatkan penulisan yang berat, dan untuk itu, RAID 5 ... bukan teman Anda.

Jika Anda dapat mengatasi sedikit anggaran ekstra, ada beberapa pendekatan:

Dua drive 15k lagi dengan ukuran yang sama. Bergantung pada arti "2 x disk array",> 8 total drive mungkin berarti pengontrol RAID baru diperlukan. (Dan / atau sasis yang lebih besar, mungkin.)
Dua ~ 120 GB SSD (PCI-express atau SATA) dalam perangkat lunak RAID 1 untuk data / log TempDB dan file log basis data. Ini mungkin sebenarnya solusi tercepat, titik, dan bisa memakan biaya kurang dari 2 drive 15k kelas perusahaan (apalagi pengontrol RAID yang sebanding). Ini mengasumsikan ada slot / port yang tersedia pada motherboard, yang mungkin ada.

Jika manajemen tidak bergerak sesuai anggaran (situasi ini berbau seperti perangkat keras lama sedang dirancang ulang untuk proyek baru ... yang berarti anggarannya nol), Anda harus menggunakan RAID 5 untuk alasan ruang, karena tidak ada cara untuk menghindarinya tanpa lebih banyak disk tersedia. Pada titik itu, langkah terbaik mungkin menempatkan 2 disk lebih lambat di RAID 1 hanya untuk O / S, dan sisanya di RAID 5 untuk memaksimalkan ruang. Jika Anda terpaksa menggunakan RAID 5 untuk bagian mana pun dari ini, manajemen harus keluar (secara tertulis) untuk memahami apa artinya itu dalam hal kinerja.

— Jon Seigel
sumber

Terima kasih. Ini adalah server klien sehingga mereka akan membuat keputusan akhir tetapi kami menerima bahwa strip redundan besar cepat adalah yang terbaik yang harus kami tuju. Server kami sendiri menggunakan garis SSD besar.

— Preet Sangha