Satırları silerken neden kümelenmemiş dizinlerim daha fazla alan kullanıyor?

7,5 milyar satır ve 5 indeksli geniş bir masam var. Kabaca 10 milyon satırı sildiğimde, kümelenmemiş dizinlerin depolandıkları sayfa sayısını arttırdığı görülüyor.

dm_db_partition_statsSayfalardaki farkı (sonradan önce) bildirmek için karşı bir sorgu yazdım :

Dizin 1 , kümelenmiş dizin, Dizin 2 ise birincil anahtardır. Diğerleri kümelenmemiş ve benzersiz değildir.

Sayfalar kümelenmemiş dizinlerde neden artıyor?
En kötü ihtimalle sayıları aynı kalmak bekleniyor.
Performans sayaçlarının silme sırasında sayfa bölmelerinde bir artış rapor ettiğini görüyorum.

Silerken, hayalet kayıt başka bir sayfaya geçmek zorunda mı? Bunun "benzersizleştiriciler" ile ilgisi var mı?

RCSI'yi piyasaya sürüyoruz, ancak şu anda, RCSI kapalı.

Bir kullanılabilirlik grubundaki birincil düğümdür. Anlık görüntülerin bir şekilde sekonderlerde kullanıldığını biliyorum. İlgili olsaydı şaşırırdım. Daha fazla bilgi edinmek için buna bakmayı düşünüyorum (dbcc sayfa çıktısını arıyorum). İşte birisinin benzer bir şey gördüğünü umuyorum.

Beni çok eğlendiren olası bir senaryo:

• Satırlar başlangıçta veritabanının Okuma Taahhütlü Anlık Görüntüsü (RCSI), Anlık Görüntü İzolasyonu (SI) veya Kullanılabilirlik Grupları (AG) etkin olmadığı zaman yazılmıştır.
• RCSI veya SI etkinleştirildi veya veritabanı Uygunluk Grubuna eklendi
• Silme işlemleri sırasında, RCSI / SI / AG okumalarını desteklemek için silinmiş satırlara 14 baytlık bir zaman damgası eklendi.

Bu sunucu bir AG’de birincil olduğundan, ikinciller gibi etkilenir. Sürüm bilgisi birincilde eklenir - veri sayfaları hem primerlerde hem de sekonderlerde aynıdır. İkinciller, AG tarafından güncellenirken satırları okumaları için sürüm deposundan yararlanırlar, ancak ikinciller zaman damgasının kendi sürümlerini sayfaya yazmazlar. Sadece primer çalışmanın versiyonlarını miras alıyorlar.

Büyümeyi göstermek için, Yığın Taşması veritabanı dışa aktarımını aldım (RCSI özelliği etkin değil) ve Mesajlar tablosunda bir sürü dizin oluşturdum. İndeks boyutlarını sp_BlitzIndex @Mode = 2 ile kontrol ettim (bir elektronik tabloya kopyala / yapıştır, ve bilgi yoğunluğunu en yükseğe çıkarmak için biraz temizledik):

Daha sonra satırların yarısını sildim:

BEGIN TRAN;
DELETE dbo.Posts WHERE Id % 2 = 0;
GO

Eğlenceli, silme olurken, veri dosyası da zaman damgalarını barındıracak şekilde büyüyordu! SSMS Disk Kullanım Raporu büyüme olaylarını gösterir - işte göstermek için en iyisi:

(Silme işleminin veritabanını büyütmesini sağlayan bir demoyu sevmeliyim.) Silme işlemi devam ederken sp_BlitzIndex'i tekrar çalıştırdım. Kümelenmiş dizinin daha az satır içerdiğini, ancak boyutlarının zaten yaklaşık 1,5 GB büyüdüğünü unutmayın. AcceptedAnswerId'deki kümelenmemiş dizinler çarpıcı bir şekilde büyüdü - bunlar çoğunlukla boş olan küçük bir değerde dizinler, bu yüzden dizin boyutları neredeyse iki katına çıktı!

Bunu ispatlamak için silme işleminin bitmesini beklemem gerekmez, bu yüzden gösteriyi oradan durduracağım. Var olan nokta: RCSI, SI veya AG'lerin etkinleştirilmesinden önceki bir tabloda büyük silme işlemleri yaptığınızda, dizinler (kümelenmiş dahil) aslında sürüm deposunun zaman damgasının eklenmesini sağlamak için büyüyebilir.