SQL Server - Memaksa DB dalam memori?

Kami memiliki server Windows 2008 x64 yang gemuk (CPU 4 x 4 core, RAM 32GB) yang menjalankan SQL Server 2005 64-bit. Kami memiliki basis data kecil (6GB) tetapi sangat penting yang agak lambat diakses hingga halaman di-cache dalam memori (penggunaannya sangat acak I / O sehingga kemungkinannya sangat rendah, halaman yang diberikan dalam memori dan pengguna akhir mengeluh tentang kelambatan awal). Disk cukup cepat (15K SAS lokal) tapi saya kira aplikasi ini agak canggung ditulis (ini adalah solusi COTS) jadi saya bertanya-tanya apakah ada cara untuk "memaksa" database dalam memori dalam SQL Server 2005 (2008 tidak didukung oleh vendor, jadi kita seharusnya tidak melakukan upgrade ke sana) untuk membantu menghindari blues mengisi-cache awal?

Metode saya saat ini adalah saya menjalankan SELECT * dari setiap tabel dalam skrip untuk mendapatkan halaman data dalam memori tetapi beberapa objek (indeks, pencarian teks lengkap, dll.) Tidak di-cache oleh metode ini (dan memodifikasi skrip untuk menginterogasi indeks dan tulis klausa WHERE yang sesuai untuk cache adalah boil-the-ocean complex).

Tidak, tidak ada cara untuk memaksa database ke cache, sayangnya. Metode brute force Anda mungkin yang paling mudah. Anda mungkin bisa lebih dekat dengan menggunakan skrip defrag indeks dengan pengaturan ambang sangat rendah, seperti mengatakan membangun kembali indeks jika 1% terfragmentasi, seperti ini:

http://sqlserverpedia.com/wiki/Index_Maintenance

Ini akan memakan waktu lebih lama dan melibatkan lebih banyak menulis ke disk, tetapi itu akan memiliki efek samping defragging indeks Anda dan memperbarui statistik, yang merupakan ide bagus.

Ok - saya tidak dapat mengomentari jawaban Brent (namun, karena saya tidak memiliki cukup repetisi) - tetapi jika Anda akan memilih rute defrag, jangan lantas membangun kembali indeks - karena itu akan membangun indeks baru, mungkin menumbuhkan basis data jika tidak ada cukup ruang kosong, dan menjamin bahwa cadangan log Anda berikutnya setidaknya ukuran indeks Anda dan log Anda mungkin memiliki satu ton catatan log juga (tergantung pada model pemulihan). Jika Anda akan melakukan rute defrag, lakukan ALTER INDEX ... REORGANIZE, yang tidak memerlukan ruang kosong (well, satu halaman 8k) tetapi akan membaca level daun ke dalam memori dan hanya beroperasi pada yang terfragmentasi. halaman. Tingkat non-daun harus masuk dengan cepat setelah beberapa pertanyaan dan (tergantung pada fan-out) harus jauh lebih sedikit data daripada tingkat daun.

Mengapa objek basis data memerah dari cache di tempat pertama? Apakah Anda me-restart layanan SQL atau melepas database / online? Atau mereka didorong oleh caching dari database lain?

Salam,

SCM.

Jika basis datanya sekecil itu, pertimbangkan untuk meletakkannya di SSD?

Saya punya beberapa skenario memperbarui statistik dengan FULLSCAN pada tabel kunci telah memaksa data ke dalam cache dan membuat DML saya berikutnya di sekitar tabel itu jauh lebih cepat. Dan ini bukan hasil dari statistik yang ketinggalan zaman karena tidak menghasilkan perubahan dalam rencana eksekusi.

Mengapa Anda tidak menginstal instance SQL Server kedua hanya dengan database itu, dan mengatur memori minimum untuk instance tersebut menjadi 6GB?

Ini akan menjamin bahwa basis data Anda yang lain tidak pernah mengambil memori dari basis data "kecil tapi sangat penting" Anda.

Ini juga berarti bahwa Anda dapat mengambil contoh lain offline dan DB kecil Anda akan tetap ada dalam memori.

Saya akan menggunakan profiler untuk memeriksa sql Anda. Bandingkan bacaan 'logis' dengan bacaan 'fisik'. SQL server pintar dan akan menggunakan RAM yang dibutuhkan untuk hasil yang paling efisien.

Periksa juga apakah autostats Anda terbaru.

Tanpa tahu lebih banyak tentang jenis kueri dan ukuran tabel db kedengarannya agak aneh.