Memori Ruang Kerja Internal


13

Per buku bacaan saya tentang SQL Server 2008 Internal dan Pemecahan Masalah (dipinjam dari perpustakaan lokal di Illinois) oleh Christian Bolton, Brent Ozar dll. Saya mencoba mencari pemahaman dan konfirmasi tentang server SQL dan banyak mencari di web Saya akan sangat menghargai jika seseorang dapat mengkonfirmasi atau memperbaiki pemahaman saya.

Setiap permintaan atau operasi yang membutuhkan hibah memori permintaan akan membutuhkan memori ruang kerja. Dalam kueri umum menggunakan Sort, Hash Match Join, Parallelism (Tidak yakin tentang ini), Insert Massal (tidak yakin), Index Rebuild dll. Akan membutuhkan memori workspace query ..

Memori ruang kerja adalah bagian dari kumpulan buffer SQL Server (dialokasikan sebagai bagian dari kumpulan buffer) dan memori ruang kerja maksimum adalah 75% dari memori yang dialokasikan untuk kumpulan buffer. Secara default kueri tunggal tidak bisa mendapatkan lebih dari 25% memori ruang kerja (dalam SQL 2008 / SQL 2012 - dikontrol oleh grup beban kerja default Resource Governor di luar kotak).

Mencari konfirmasi atas pengertian saya

1) Mempertimbangkan sistem dengan RAM 48 GB dan memori server maks yang dikonfigurasikan ke 40 GB apakah ini berarti memori ruang kerja maks dibatasi hingga 30 GB dan satu permintaan tidak bisa mendapatkan memori ruang kerja (memori permintaan) lebih dari 10 GB. Jadi, jika Anda memiliki kueri buruk yang bekerja dengan satu miliar baris yang melakukan hash join bergabung dan membutuhkan lebih dari 10 GB memori (memori ruang kerja) apakah akan peduli untuk pergi melalui antrian pemberian memori ini atau langsung menumpahkan ke disk?

2) Jika kueri yang melakukan operasi pengurutan besar-besaran telah menetapkan memori ruang kerja 5 MB dan selama pelaksanaan kueri jika pengoptimal kueri menyadari bahwa karena statistik yang buruk atau indeks yang hilang, kueri ini benar-benar membutuhkan 30 MB memori ruang kerja. akan segera tumpah ke tempdb. Bahkan jika sistem memiliki banyak ruang kerja memori yang tersedia selama eksekusi setelah permintaan melebihi memori ruang kerja yang diberikan selama eksekusi itu harus tumpah ke disk. Apakah pemahaman saya benar?

Jawaban:


13

apakah akan peduli untuk melewati antrian pemberian memori ini atau segera menumpahkannya ke disk?

Tidak berfungsi seperti itu. Setelah rencana dipilih yang memerlukan hibah memori, kueri harus mendapatkan hibah sehingga melewati antrian. Tumpahan, jika ada, terjadi jauh di kemudian hari dalam siklus eksekusi. Permintaan tidak dapat memutuskan untuk melanjutkan tanpa hibah dan 'tumpahan' sebagai gantinya. Itu harus mendapatkan hibah dan, dasar itu, memulai eksekusi. Jika hibah ternyata tidak mencukupi (karena perkiraan yang buruk atau karena mendapatkan hibah yang jauh lebih rendah dari yang diminta) maka permintaan akan dipaksa untuk tumpah.

jika pengoptimal kueri menyadari itu karena statistik yang buruk atau indeks yang hilang

Sebenarnya bukan pengoptimal, melainkan eksekusi permintaan. Pengoptimal Kueri hanya memiliki suara dalam menentukan rencana, tetapi setelah rencana dipilih dan diluncurkan ke dalam pelaksanaan, pengoptimal tidak lagi terlihat. juga, 'indeks yang hilang' tidak berperan di sini. Indeks yang hilang dapat memaksa rencana yang buruk, tetapi tidak dapat memengaruhi bagaimana rencana 'buruk' itu dijalankan karena rencana itu dibangun dengan mempertimbangkan indeks apa yang sebenarnya ada sehingga ia tahu persis apa yang bisa dan tidak bisa dilakukan. Tumpahan terjadi hampir selalu karena perkiraan yang buruk, yaitu. statistik buruk atau algoritma estimasi kardinalitas buruk dalam pengoptimal dan dalam pelaksanaannya (akan menjadi sangat kompleks jika Anda menggali detailnya jadi saya akan berhenti di sini).

Bahkan jika sistem memiliki banyak ruang kerja memori yang tersedia selama eksekusi setelah permintaan melebihi memori ruang kerja yang diberikan selama eksekusi itu harus tumpah ke disk

Sayangnya ya. Namun pengoptimal harus datang dengan rencana yang memanfaatkan RAM yang tersedia.

Saya sarankan membaca Memahami hibah SQL server memori adalah info terbaik tentang subjek dengan margin lebar .


4
Remus Rusanu (MSFT) Saya juga melihat ke posting blog Anda selama pencarian web terkait dengan operator yang membutuhkan hibah memori permintaan. Terima kasih, Anda adalah permata sejati yang mendukung forum ini.
SQL Learner


Remus, bahwa sesi KTT PASS dari Adam Machanic sangat teliti dan mengklarifikasi pertanyaan yang terkait dengan memori ruang kerja.
SQL Learner
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.