Apakah RE-BUILDing HEAP menyebabkan downtime?

Ini adalah pertanyaan yang memalukan, dan saya tidak percaya saya melewatkan ini selama bertahun-tahun.

Saya memiliki vendor database pihak ketiga yang memiliki 401 tabel tumpukan. Saya baru-baru ini menggunakan skrip dan pengaturan Brent Ozar sp_BlitzFirstuntuk dijalankan setiap 15 menit untuk mengumpulkan statistik tunggu, dll.

Apa yang terungkap adalah setiap kali berlari dalam periode 24 jam ia mengatakan kepada saya untuk memperbaiki Forwarded Records . Apa yang mungkin akan mengejutkan beberapa pembaca bahwa saya menjalankan kueri di DMV dan mendapatkan kembali beberapa tabel dengan lebih dari 150.000 nilai rekaman yang diteruskan.

Saya mengerti untuk memperbaikinya adalah memiliki indeks berkerumun di seluruh tabel, atau sebagai solusi sementara untuk dijalankan ALTER TABLE [tablename] REBUILD.

Apa yang saya belum dapat temukan adalah apakah ini membuat tabel offline, dan apakah ada masalah lain yang harus saya ketahui sebelum menjalankan perintah ini.

Saya menggunakan Edisi Enterprise 2008 R2, dan saya bertanya-tanya apakah menjalankannya dengan cara ini akan menghapus kebutuhan untuk pemadaman?

ALTER TABLE [tablename] REBUILD WITH (ONLINE = ON);  

Adakah yang punya pengalaman dengan ini?

Berita baik: 150.000 rekaman yang diteruskan tidak seburuk itu, tergantung pada rentang waktu seperti apa yang sedang kita bicarakan. Catatan yang diteruskan dilacak selama server aktif (dengan beberapa gotchas di sekitar bug dalam pembuatan 2012/2014 tertentu .)

Bahkan ketika itu bekerja online, pengguna Anda dapat melihatnya tergantung pada throughput IO Anda, ukuran tabel, jumlah indeks yang tidak tercakup, dan beban kerja Anda.

Inilah cara saya mengatasinya:

• Daftar tabel dengan peringatan catatan diteruskan dari ukuran tabel terkecil ke terbesar (bukan jumlah catatan diteruskan)
• Buat ulang tabel-tabel itu secara berurutan, secara manual, beberapa sekaligus. Jangan mengotomatiskan ini - Anda ingin merasakan bagaimana sistem Anda merespons membangun kembali tabel kecil. Anda akan belajar dengan cukup cepat jika server Anda dapat mengikuti.
• Mengawasi penggunaan log transaksi Anda. Jika file log Anda 10GB, dan Anda mencoba membangun kembali tumpukan 50GB, Anda dapat mengalami masalah. Anda dapat mengurangi masalah ini dengan menumbuhkan log lebih dulu dari waktu selama pemeliharaan jendela dan dengan sering melakukan pencadangan log saat Anda melakukan ini - tetapi saya akan jujur, pada 150 ribu catatan yang diteruskan dalam rentang beberapa hari, saya tidak akan repot-repot melalui banyak pekerjaan ini.
• Ke depannya, bekerja sama dengan vendor untuk meletakkan kunci berkerumun di atas tabel tersebut. Ya, ada saat-saat ketika tumpukan sesuai, tetapi jika Anda mengalami masalah rekaman yang diteruskan, Anda mungkin tidak berada dalam salah satu situasi ramah-tumpukan itu.