Mengapa kueri menyebabkan tumpahan ke tempdb?

Latar Belakang

Saya sedang dalam proses migrasi database 160GB dari MSSQL 2008 (standar) pada server Win 2008 dengan 48 GB RAM ke server baru yang menjalankan MSSQL 2012 (edisi web 64-bit) pada Win 2012 dengan 64 GB RAM. Server lama hidup dan di bawah beban; server baru tidak dalam produksi. Server baru memiliki 8 file tempdb (masing-masing 4GB).

Masalah

Dalam pengujian pada server baru saya melihat langkah-langkah dalam berbagai pertanyaan menyebabkan peringatan yang menyebutkan "operator menggunakan tempdb untuk menumpahkan data selama eksekusi". Saya dapat menghindari masalah dengan menulis ulang beberapa pertanyaan, tetapi ini tidak benar-benar mengatasi masalah ini. Kueri yang sama di server lama tidak menyebabkan tumpahan. Saya telah membaca bahwa tumpahan terjadi ketika MSSQL tidak dapat menyelesaikan operasi dalam memori dan harus menumpahkan / halaman ke tempdb. Haruskah saya khawatir tentang tumpahan?

Contohnya

masukkan deskripsi gambar di sini

Saya telah menjalankan sp_updatestats pada database, jadi statistiknya harus terkini, tetapi Anda akan perhatikan ada beberapa perbedaan antara jumlah baris yang diperkirakan dan aktual.

Kekhawatiran memori

Saya telah menetapkan pengaturan memori maks untuk MSSQL dari 58 dari 64GB. Saat ini MSSQL telah mengkonsumsi sekitar 35gb memori ini, tetapi hanya memiliki set kerja 682mb. Server lama (meskipun dalam produksi, menangani beban) memiliki 44GB memori yang dikomit ke MSSQL yang 43.5gb berada di set kerjanya.

masukkan deskripsi gambar di sini

Saya tidak tahu apakah tumpahan mungkin terkait dengan pengaturan memori - ada yang punya ide? MSSQL saat ini memiliki banyak RAM, jadi mengapa itu menumpahkan ke tempdb untuk beberapa jenis dan hash cocok?

sql-server sql-server-2012

— Andy W
sumber

Lansiran dalam rencana eksekusi adalah baru pada 2012. Apakah Anda sudah memeriksa apakah tidak tumpah di server lama? Apakah Anda memantau ini?

— Martin Smith

@ MartinSmith ah, tidak menyadari bahwa peringatan itu baru. Saya tidak memantau tumpahan di server lama. Akan menyelidiki itu.

Titik singgung sedikit tapi saya duduk di depan 10 tabel bergabung yang secara default sebagian besar menggunakan gabungan bergabung dengan perkiraan baris yang sangat baik yang menyebabkan level tempdb 0 tumpahan dan runtime 25s. Memaksa hash bergabung (dan memesan) menghilangkan tumpahan dan beroperasi dalam 9s. Saya bertanya-tanya apakah itu gabungan vs hash atau tumpahan yang menyebabkan perbedaan dan apakah pengoptimal benar membobot efek tumpahan mendatang yang tampaknya diketahui (karena perkiraan baris sangat baik).

— crokusek

Server baru memiliki perangkat keras numa?

— stacylaray

Ada beberapa pertanyaan berbeda di sini:

T: Mengapa kueri tidak tumpah sebelumnya?

Ya, tapi SQL Server Management Studio tidak memunculkan ini sebagai kesalahan yang jelas sebelum SQL 2012. Ini adalah contoh bagus mengapa ketika Anda melakukan penyetelan kinerja, Anda harus masuk lebih dalam daripada rencana eksekusi grafis.

T: Mengapa kueri tumpah ke disk?

Karena SQL Server tidak memberi mereka cukup memori untuk menyelesaikan operasi mereka. Mungkin rencana eksekusi meremehkan jumlah memori yang diperlukan, atau mungkin kotak itu di bawah tekanan memori, atau mereka hanya pertanyaan besar. (Ingat, SQL Server menggunakan memori untuk tiga hal - caching halaman data mentah, caching rencana eksekusi, dan ruang kerja untuk kueri. Memori ruang kerja itu akhirnya menjadi cukup kecil.)

T: Bagaimana saya bisa mengurangi tumpahan?

Dengan menulis pernyataan T-SQL yang cukup besar, memiliki statistik terkini, menempatkan cukup memori di server, membangun indeks yang tepat, dan menafsirkan rencana eksekusi ketika hal-hal tidak berjalan seperti yang Anda harapkan. Lihat buku Grant Fritchey, SQL Server Query Performance Tuning untuk penjelasan terperinci dari semua itu.

— Brent Ozar
sumber