Berikut ini adalah paragraf dari Microsoft Documents :
Halaman baru yang dialokasikan di heap sebagai bagian dari operasi DML tidak akan menggunakan kompresi PAGE sampai heap dibangun kembali. Membangun kembali tumpukan dengan menghapus dan menerapkan kembali kompresi, atau dengan membuat dan menghapus indeks berkerumun.
Saya tidak tahu mengapa ini terjadi. Jika saya memiliki tumpukan dengan pengaturan kompresi yang ditentukan, mengapa itu tidak diterapkan ke halaman milik tabel?
Terima kasih
Jawaban:
Meskipun saya tidak tahu mekanisme internal spesifik yang bertanggung jawab atas perbedaan, saya dapat mengatakan bahwa Heaps dikelola (secara internal) sedikit berbeda dari Indeks Clustered (dan mungkin juga Indeks Nonclustered):
Menghapus baris dari Heap sedemikian sehingga satu atau lebih halaman data kosong (tidak ada baris yang dialokasikan) tidak serta merta membebaskan ruang itu. Anda mungkin perlu membuat, dan kemudian menjatuhkan, Indeks Clustered di atas meja, atau panggilan ALTER TABLE [TableName] REBUILD;(pada SQL Server 2014?). Silakan lihat halaman Microsoft Documents untuk DELETE untuk detail dan opsi lebih lanjut.
Memasukkan baris individual (bukan berbasis set INSERT) ke Heap tidak mengisi halaman data sepenuhnya seperti halnya dengan Clustered Indexes. Indeks Clustered akan sesuai dengan baris selama ada ruang untuk baris (data dan baris-overhead) ditambah overhead 2-byte dari array slot. Halaman data di Heaps, bagaimanapun, tidak menggunakan jumlah byte yang tersisa di halaman, tetapi sebaliknya menggunakan indikator yang sangat umum tentang seberapa penuh halaman, dan tidak ada banyak level yang dilaporkan. Levelnya adalah sesuatu di sepanjang garis: 0%, 20%, 50%, 80%, dan 100% penuh. Dan itu akan beralih ke 100% sementara masih ada ruang untuk baris lain (dan pada kenyataannya, seandainya jumlah baris yang sama telah dimasukkan dalam operasi berbasis set, maka itu akan mengisi halaman sebanyak mungkin). Tentu saja, sama seperti denganDELETE operasi, membangun kembali Heap akan mengemas baris sebanyak yang sesuai ke halaman data.
Sekarang pertimbangkan informasi berikut, diambil dari bagian "Saat Kompresi Halaman" dari halaman Microsoft Documents untuk Implementasi Kompresi Halaman :
... Saat data ditambahkan ke halaman data pertama, data dikompresi baris. ... Saat halaman penuh, baris berikutnya yang ditambahkan akan memulai operasi kompresi halaman. Seluruh halaman ditinjau; ...
Oleh karena itu, tampaknya sepenuhnya sejalan dengan perilaku Heap lain ini bahwa mereka akan memerlukan ALTER TABLE REBUILD, BUAT / DROP dari Indeks Clustered, atau perubahan dalam pengaturan Kompresi Data (yang semuanya membangun kembali tumpukan) sebelum halaman data ditulis secara optimal. Jika Tumpukan yang tidak sepenuhnya menyadari "seluruh halaman" (sampai Heap adalah dibangun kembali) dan tidak tahu kapan halaman tersebut pasti penuh, maka mereka tidak akan tahu kapan untuk memulai operasi halaman kompresi (ketika berhadapan dengan update dan tunggal sisipan -row).
Teknis lainnya yang akan membatasi beberapa Heaps dari penerapan Page Compression secara otomatis (bahkan jika mereka bisa) adalah bahwa menerapkan kompresi akan memerlukan semua Indeks Nonclustered untuk Heap itu (jika ada) untuk dibangun kembali. Seperti halaman tertaut untuk "Kompresi Data" juga menyatakan:
Mengubah pengaturan kompresi heap membutuhkan semua indeks nonclustered pada tabel untuk dibangun kembali sehingga mereka memiliki pointer ke lokasi baris baru di heap.
"Pointer" yang dimaksud adalah ID Baris (RID), yang merupakan kombinasi dari: FileID, PageID, dan slot / posisi pada halaman. RID ini disalin ke dalam Indeks Tidak Tertutup. Menjadi lokasi fisik yang tepat, mereka kadang-kadang pencarian lebih cepat daripada melintasi pohon-b dengan kunci Indeks Clustered. Namun, satu kelemahan dari lokasi fisik adalah ia dapat berubah, dan itulah masalahnya di sini. Namun, Indeks Clustered, tidak menderita dari masalah ini karena nilai-nilai kunci mereka disalin ke dalam Indeks Nonclustered sebagai pointer kembali ke Indeks Clustered. Dan nilai-nilai kunci tetap sama, bahkan ketika lokasi fisiknya berubah.
Lihat juga:
bagian "Mengelola Tumpukan" dari halaman Microsoft Documents untuk Tumpukan (Tabel tanpa Indeks Clustered) :
Untuk membangun kembali tumpukan untuk mendapatkan kembali ruang yang terbuang, buat indeks berkerumun di tumpukan, dan kemudian jatuhkan indeks berkerumun itu.
bagian "Pertimbangan untuk Ketika Anda Menggunakan Kompresi Baris dan Halaman" dari halaman Microsoft Documents untuk Kompresi Data :
Ketika tumpukan dikonfigurasi untuk kompresi tingkat halaman, halaman menerima kompresi tingkat halaman hanya dengan cara berikut:
- Data diimpor secara massal dengan optimisasi massal diaktifkan.
- Data dimasukkan menggunakan sintaks INSERT INTO ... WITH (TABLOCK) dan tabel tidak memiliki indeks nonclustered.
- Sebuah tabel dibangun kembali dengan menjalankan pernyataan ALTER TABLE ... REBUILD dengan opsi kompresi PAGE.
Dan pernyataan tersebut dikutip dalam pertanyaan.
Tidak semua mekanisme dalam SQL Server seperti yang kami yakini seharusnya.
Paul Randal telah memberikan rekomendasi kuat untuk mengelola masalah ini.
http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-2930-fixing-heap-fragmentation/