Kapan menggunakan sort_in_tempdb saat membangun kembali indeks?

Kami sedang berdebat apakah akan menggunakan opsi SORT_IN_TEMPDB untuk tabel DW kami. Pemahaman saya adalah bahwa ada lebih banyak menulis saat menggunakan opsi ini, meskipun mereka lebih berurutan. Kami memiliki SAN (yang terkadang sangat lambat), jadi dalam kasus kami kami ingin membatasi jumlah penulisan sebanyak mungkin. Saya percaya tempdb berada di LUN terpisah (set disk).

Kami memiliki banyak ruang disk dalam file data kami dan pada file tempdb kami. Dalam hal ini, apakah kita akan mendapat manfaat dari menggunakan SORT_IN_TEMPDB?

Satu hal yang mengejutkan saya adalah komentar tentang Jawaban ini

Saat membangun kembali indeks, Anda akan membutuhkan dua kali ruang indeks + 20% untuk penyortiran. Jadi secara umum untuk membangun kembali setiap indeks di db, Anda hanya perlu 120% dari indeks terbesar di DB. Jika Anda menggunakan SORT_IN_TEMPDB, Anda hanya menang 20%, Anda masih membutuhkan tambahan 100% dalam file data Anda. Lebih jauh lagi, menggunakan sort in tempdb meningkatkan beban IO Anda secara drastis, karena alih-alih menulis indeks satu kali ke filefile, Anda sekarang menulisnya satu kali ke tempdb dan kemudian menulisnya ke file data. Jadi itu tidak selalu ideal.

Kami jelas tidak ingin menambah muatan IO kami dengan SAN kami yang lambat / kemungkinan tidak terkonfigurasi.

Apa cara terbaik untuk menguji ini? Dengan hanya membangun kembali tabel dengan dan tanpa opsi dan mencatat waktu?

Sunting : Kami memiliki 8 file tempdb, masing-masing 15GB. Kami memiliki flag TF 1117/1118 yang diatur dan IFI diaktifkan. Kami saat ini melakukan campuran pembangunan kembali dengan opsi sort_in_tempdb dan tanpa itu.

Terima kasih!

SQL Server 2012 Enterprise

SORT_IN_TEMPDBberarti bahwa SQL server akan digunakan tempdbuntuk mengalokasikan ruang sementara sebagai lawan untuk mengalokasikan ruang dalam basis data pengguna yang indeksnya sedang dibangun kembali. Ini berarti Anda akan membutuhkan lebih sedikit ruang kosong di basis data pengguna Anda selama operasi pembangunan kembali indeks dan lebih banyak ruang kosong di tempdb.

Ini memberi Anda keuntungan yang lebih baik ketika tempdb berada di set disk yang berbeda (LUN) dari database pengguna.

Dari Opsi SORT_IN_TEMPDB - BOL :

Jika opsi SORT_IN_TEMPDB diatur ke ON dan tempdb berada di set disk terpisah dari grup tujuan, selama fase pertama, pembacaan halaman data terjadi pada disk yang berbeda dari penulisan ke area kerja pengurutan di tempdb. Ini berarti disk membaca kunci data umumnya melanjutkan lebih serial di disk, dan menulis ke disk tempdb juga umumnya serial, seperti halnya menulis untuk membangun indeks akhir. Bahkan jika pengguna lain menggunakan database dan mengakses alamat disk yang terpisah, keseluruhan pola baca dan tulis lebih efisien ketika SORT_IN_TEMPDB ditentukan daripada ketika tidak.

Pastikan Anda membaca persyaratan ruang disk saat SORT_IN_TEMPDB menyala .

SAN lambat / mungkin salah konfigurasi

Anda tahu titik sakitnya. Mengapa Anda tidak bekerja dengan admin SAN Anda untuk memperbaikinya? Kesalahan konfigurasi dan atau lambatnya SAN akan menyebabkan semua masalah seperti kelambatan .

Beberapa poin penting yang perlu diperhatikan:

• Gunakan MAXDOP = 1 ketika melakukan pembangunan kembali indeks online - selain itu akan menyebabkan peningkatan fragmentasi.
• Secara cerdas pasang kembali / bangun kembali indeks Anda berdasarkan tingkat fragmentasi serta fragmen halaman.
• Baca pengalaman SQLFool dengan Membuat Indeks 60 GB
• Pastikan Anda telah mengkonfigurasi tempdb dengan benar - TF 1117 (GROW ALL FILES IN FILEGROUP EQUALLY) dan 1118 (FULL EXTENTS ONLY) dan memiliki lebih banyak tempfb datafiles .

Apa cara terbaik untuk menguji ini?

Ya, Anda harus mengujinya dengan menganalisis daftar tunggu ketika Anda membangun kembali indeks dengan dan tanpa SORT_IN_TEMPDB. Mengukur waktu lari juga dan saat melakukan di PROD, pastikan Anda melakukannya selama jendela pemeliharaan atau kurang aktivitas server. Periksa juga data baca / tulis Anda dan log latensi .

Saya tidak yakin Anda memiliki inisialisasi file instan , tetapi itu akan bermanfaat ketika mengembalikan, selama autogrowth file data dan ketika membuat database baru (hanya menyebutkan untuk kelengkapan).