Sorgu performansını geliştirmek ve kaynak tüketimini azaltmak için dizin bakımını iyileştirme

Şunlar için geçerlidir:SQL ServerAzure SQL VeritabanıAzure SQL Yönetilen ÖrneğiAnaliz Platformu Sistemi (PDW)Microsoft Fabric'te SQL veritabanı

Bu makale, dizin bakımının ne zaman ve nasıl gerçekleştirileceğine karar vermenize yardımcı olur. Dizin parçalanması ve sayfa yoğunluğu gibi kavramları ve bunların sorgu performansı ve kaynak tüketimi üzerindeki etkilerini kapsar. İki dizin bakım yöntemini açıklar: dizini yeniden düzenleme ve dizini yeniden derleme. Makalede ayrıca, bakım için gereken kaynak tüketimine karşı olası performans iyileştirmelerini dengeleyen bir dizin bakım stratejisi de önerilir.

Note

Bu makale, Azure Synapse Analytics'teki ayrılmış bir SQL havuzu için geçerli değildir. Azure Synapse Analytics'te ayrılmış bir SQL havuzu için dizin bakımı hakkında bilgi için bkz. Azure Synapse Analytics'te ayrılmış SQL havuzu tablolarının dizinini oluşturma.

Kavramlar: dizin parçalanması ve sayfa yoğunluğu

dizin parçalanması nedir ve performansı nasıl etkiler?

• B ağacı (satır deposu) dizinlerinde, dizinlerde dizinin anahtar değerlerine göre mantıksal sıralamanın dizin sayfalarının fiziksel sıralamasıyla eşleşmediği sayfalar olduğunda parçalanma oluşur.

  Note

  Belgelerde genellikle dizinlere başvuruda B ağacı terimi kullanılır. Rowstore dizinlerinde Veritabanı Altyapısı bir B+ ağacı uygular. Bu, bellek açısından iyileştirilmiş tablolardaki columnstore dizinleri veya diğer dizinler için geçerli değildir. Daha fazla bilgi için SQL Server ve Azure SQL dizin mimarisi ve tasarım kılavuzuna bakın.

• Veritabanı Altyapısı, temel alınan verilere ekleme, güncelleştirme veya silme işlemleri yapıldığında dizinleri otomatik olarak değiştirir. Örneğin, tablodaki satırların eklenmesi, satır deposu dizinlerindeki mevcut sayfaların bölünmesine neden olabilir ve bu da yeni satırların eklenmesine yer açabilir. Zaman içinde bu değişiklikler dizindeki verilerin veritabanında (parçalanmış) dağılmasına neden olabilir.

• Tam veya aralık dizin taramaları kullanan birçok sayfayı okuyan sorgular için, verileri okumak için ek G/Ç gerektiğinde yoğun parçalanmış dizinler sorgu performansını düşürebilir. Sorgu, birkaç büyük G/Ç isteği yerine aynı miktarda veriyi okumak için çok sayıda küçük G/Ç isteği gerektirir.

• Depolama alt sistemi rastgele G/Ç performansından daha iyi sıralı G/Ç performansı sağladığında, parçalanmış dizinleri okumak için daha fazla rastgele G/Ç gerektiğinden dizin parçalanması performansı düşürebilir.

Sayfa yoğunluğu (sayfa doluluğu olarak da bilinir) nedir ve performansı nasıl etkiler:

• Veritabanındaki her sayfası değişken sayıda satır içerebilir. Satırlar sayfadaki tüm alanı kaplarsa, sayfa yoğunluğu 100%olur. Sayfa boşsa, sayfa yoğunluğu 0%olur. 100% yoğunluğu olan bir sayfa yeni bir satıra sığacak şekilde iki sayfaya bölünürse, iki yeni sayfanın yoğunluğu yaklaşık 50%olur.
• Sayfa yoğunluğu düşük olduğunda, aynı miktarda veriyi depolamak için daha fazla sayfa gerekir. Bu, bu verileri okumak ve yazmak için daha fazla G/Ç ve bu verileri önbelleğe almak için daha fazla bellek gerektiği anlamına gelir. Bellek sınırlı olduğunda, sorgu için gereken daha az sayfa önbelleğe alınır ve bu da daha fazla disk G/Ç'sine neden olur. Sonuç olarak, düşük sayfa yoğunluğu performansı olumsuz etkiler.
• Veritabanı Altyapısı dizin oluşturma, yeniden oluşturma veya yeniden düzenleme sırasında sayfaya satır eklediğinde, dizinin doldurma faktörü 100 (veya bu bağlamda eşdeğer olan 0) dışında bir değere ayarlanırsa sayfayı tam olarak doldurmaz. Bu, daha düşük sayfa yoğunluğuna neden olur ve benzer şekilde G/Ç ek yükü ekler ve performansı olumsuz etkiler.
• Düşük sayfa yoğunluğu, ara B ağacı düzeylerinin sayısını artırabilir. Bu, dizin taramalarında ve aramalarında yaprak düzeyi sayfaları bulmanın CPU ve G/Ç maliyetini orta düzeyde artırır.
• Sorgu İyileştiricisi bir sorgu planı derlediğinde, sorgunun gerektirdiği verileri okumak için gereken G/Ç maliyetini dikkate alır. Düşük sayfa yoğunluğuyla, okunacak daha fazla sayfa vardır, bu nedenle G/Ç maliyeti daha yüksektir. Bu, sorgu planı seçimini etkileyebilir. Örneğin, sayfa bölmeleri nedeniyle sayfa yoğunluğu zaman içinde azaldıkça, iyileştirici aynı sorgu için farklı bir performans ve kaynak tüketimi profiliyle farklı bir plan derleyebilir.

Tip

Birçok iş yükünde sayfa yoğunluğunun artırılması, parçalanmayı azaltmaya kıyasla daha olumlu bir performans etkisine neden olur.

Sayfa yoğunluğunun gereksiz yere düşürülmemesi için Microsoft, çok fazla sayıda sayfa bölme işlemi yaşayan dizinler dışında dolgu faktörünün 100 veya 0 dışındaki değerlere ayarlanmasını önermez. Örneğin, bu durum sıralı olmayan GUID değerleri içeren baştaki sütunla sık değiştirilen dizinlerde oluşabilir.

Dizin parçalanma ve sayfa yoğunluğu ölçme

Dizin bakımı yapılıp yapılmaymayacağına ve hangi bakım yönteminin kullanılacağına karar verirken hem parçalanma hem de sayfa yoğunluğu dikkate alınması gereken faktörler arasındadır.

Parçalanma, satır deposu ve columnstore dizinleri için farklı şekilde tanımlanır. Rowstore dizinleri için , sys.dm_db_index_physical_stats() belirli bir dizinde veya birden çok dizinde parçalanma ve sayfa yoğunluğu belirlemenize olanak tanır. Bölümlenmiş dizinler için sys.dm_db_index_physical_stats() her bölüm için bu bilgileri sağlar.

sys.dm_db_index_physical_stats tarafından döndürülen sonuç kümesi aşağıdaki sütunları içerir:

Column	Description
avg_fragmentation_in_percent	Mantıksal parçalanma (dizindeki düzensiz sayfalar).
avg_page_space_used_in_percent	Ortalama sayfa yoğunluğu.

Columnstore dizinlerindeki sıkıştırılmış satır grupları için parçalanma, silinen satırların toplam satırlara oranı olarak tanımlanır ve yüzde olarak ifade edilir. sys.dm_db_column_store_row_group_physical_stats belirli bir dizindeki satır grubu başına toplam ve silinen satır sayısını, tablodaki tüm dizinleri veya veritabanındaki tüm dizinleri belirlemenize olanak tanır.

sys.dm_db_column_store_row_group_physical_stats tarafından döndürülen sonuç kümesi aşağıdaki sütunları içerir:

Column	Description
total_rows	Satır grubunda fiziksel olarak depolanan satır sayısı. Sıkıştırılmış satır grupları için bu, silinmiş olarak işaretlenmiş satırları içerir.
deleted_rows	Sıkıştırılmış bir satır grubunda fiziksel olarak depolanan ve silinmek üzere işaretlenmiş satır sayısı. Delta deposundaki satır grupları için 0.

Columnstore dizinindeki sıkıştırılmış satır grubu parçalanması şu formül kullanılarak hesaplanabilir:

100.0 * (ISNULL(total_stored_deleted_rows, 0)) / NULLIF(total_rows, 0)

Kümesiz bir columnstore dizini için fiziksel olarak depolanan silinen satırların toplam sayısını belirlemek amacıyla, iç nesne türü deleted_rows ve aynı nesne, dizin ve bölüm için sys.dm_db_column_store_row_group_physical_stats tablosundaki rows sütunundaki değere, tablosundaki COLUMN_STORE_DELETE_BUFFER sütunundaki değerleri ekleyin. Örnek için bkz. Columnstore dizininin parçalanma durumunu denetleme.

Tip

Hem satır deposu hem de columnstore dizinleri için, çok sayıda satır silindikten veya güncelleştirildikten sonra dizin veya yığın parçalanma ve sayfa yoğunluğu bilgilerini gözden geçirin. Yığınlar için, sık güncellemeler varsa, iletme kayıtlarının çoğalmasını önlemek için bellekteki parçalanmayı düzenli aralıklarla kontrol edin. Yığınlar hakkında daha fazla bilgi için bkz. Yığınlar (Kümelenmiş Dizinleri Olmayan Tablolar).

Parçalanmayı ve sayfa yoğunluğunun belirlenmesine yönelik örnek sorgular için bkz. Örnekler.

Dizin bakım yöntemleri: yeniden düzenleme ve yeniden oluşturma

Aşağıdaki yöntemlerden birini kullanarak dizin parçalanmasını azaltabilir ve sayfa yoğunluğunun artırılmasını sağlayabilirsiniz:

• Dizini yeniden düzenleme
• Dizini yeniden oluşturma

Bölümlenmiş dizinleri için, tüm bölümlerde veya bir dizinin tek bir bölümünde aşağıdaki yöntemlerden birini kullanabilirsiniz.

Dizini yeniden düzenleme

Dizini yeniden düzenlemek, dizini yeniden oluşturmaktan daha az kaynak yoğunlukludur. Bu nedenle, dizin yeniden derlemeyi kullanmak için belirli bir neden olmadığı sürece tercih ettiğiniz dizin bakım yöntemi olmalıdır. Yeniden düzenleme her zaman çevrimiçi bir işlemdir. Bu, uzun süreli nesne düzeyinde kilitlerin tutulmayabileceği ve işlem sırasında ALTER INDEX ... REORGANIZE temel tablodaki sorgular veya güncelleştirmelerin devam olabileceği anlamına gelir.

• Satır deposu dizinleri için Veritabanı Motoru, tablolardaki ve görünümlerdeki kümelenmiş ve kümelenmemiş dizinlerin yalnızca yaprak düzeyini birleştirir. Yaprak düzeyi sayfaları, soldan sağa yaprak düğümlerinin mantıksal sırasına uyacak şekilde fiziksel olarak yeniden sıralar. Yeniden düzenleme, sayfa yoğunluğunun dizinin dolgu faktörü eşit olmasını sağlamak için dizin sayfalarını da sıkıştırabilir. Doldurma faktörü ayarını görüntülemek için sys.indexeskullanın. Söz dizimi örnekleri için bkz. Örnekler - Rowstoreyeniden düzenleme.
• columnstore dizinleri kullanılırken, delta deposu zaman içinde veri ekleme, güncelleme ve silme işlemlerinden sonra birden fazla küçük satır grubuyla sonuçlanabilir. Columnstore indeksini yeniden düzenlemek, delta depo satır gruplarını columnstore'da sıkıştırılmış satır gruplarına dönüştürür ve daha küçük sıkıştırılmış satır gruplarını daha büyük satır grupları şeklinde birleştirir. Yeniden düzenleme işlemi ayrıca columnstore'da silinmiş olarak işaretlenmiş satırları fiziksel olarak kaldırır. Bir columnstore dizinini yeniden düzenlemek, verileri sıkıştırmak için ek CPU kaynakları gerektirebilir. İşlem çalışırken performans yavaşlayabilir. Ancak veriler sıkıştırıldıktan sonra sorgu performansı artar. Söz dizimi örnekleri için bkz. Örnekler - Columnstoreyeniden düzenleme.

SQL Server 2019 (15.x), Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği'nden itibaren, grubu taşıyıcı bir iç eşik tarafından belirlenen bir süredir var olan daha küçük açık delta satır gruplarını otomatik olarak sıkıştıran veya çok sayıda satırın silindiği sıkıştırılmış satır gruplarını bir araya getiren bir arka plan birleştirme görevi ile desteklenir. Bu, columnstore dizin kalitesini zamanla artırır. Çoğu durumda bu, ALTER INDEX ... REORGANIZE komutları verme gereksinimini reddeder.

Tip

Yeniden düzenleme işlemini iptal ederseniz veya başka bir şekilde kesintiye uğrarsa, bu noktaya kadar yaptığı ilerleme veritabanında kalıcı olur. Büyük dizinleri yeniden düzenlemek için işlem tamamlanıncaya kadar birden çok kez başlatılabilir ve durdurulabilir.

Dizini yeniden oluşturma

Dizini yeniden derlemek, dizini iptal eder ve yeniden oluşturur. Dizin türüne ve Veritabanı Altyapısı sürümüne bağlı olarak, yeniden oluşturma işlemi çevrimdışı veya çevrimiçi yapılabilir. Çevrimdışı dizin yeniden derlemesi genellikle çevrimiçi yeniden derlemeden daha az zaman alır, ancak yeniden oluşturma işlemi boyunca nesne düzeyinde kilitler tutar ve sorguların tabloya veya görünüme erişmesini engeller.

Çevrimiçi dizin yeniden oluşturma işlemi, yeniden derlemeyi tamamlamak için bir kilidin kısa bir süre boyunca tutulması gerektiğinde işlemin sonuna kadar nesne düzeyinde kilitler gerektirmez. Veritabanı Altyapısı'nın sürümüne bağlı olarak, çevrimiçi dizin yeniden oluşturma işlemi devam ettirilebilir bir işlem olarak başlatılabilir. Duraklatılabilen bir dizin yeniden derlemesi, o ana kadar kaydedilen ilerlemeyi koruyarak duraklatılabilir. Devam ettirilebilir yeniden oluşturma işlemi duraklatıldıktan veya kesildikten sonra sürdürülebilir veya tamamlanmasının gereksiz hale geldiği durumlarda durdurulabilir.

Transact-SQL söz dizimi için, ALTER INDEX REBUILDbölümüne bakın. Çevrimiçi dizin yeniden derlemeleri hakkında daha fazla bilgi için bkz. Dizin İşlemlerini Çevrimiçi Gerçekleştirme.

Note

Bir dizin çevrimiçi olarak yeniden oluşturulurken, dizinlenmiş sütunlardaki verilerde yapılan her değişiklik dizinin ek bir kopyasını güncelleştirmelidir. Bu, çevrimiçi yeniden oluşturma sırasında veri değişikliği deyimlerinin küçük bir performans düşüşüyle sonuçlanabilir.

Çevrimiçi olarak devam ettirilebilen bir dizin işlemi duraklatılırsa, devam ettirilebilir işlem tamamlanana veya durdurulana kadar bu performans etkisi devam eder. Devam ettirilebilir bir dizin işlemini tamamlamak istemiyorsanız duraklatmak yerine iptal edin.

Tip

Kullanılabilir kaynaklara ve iş yükü desenlerine bağlı olarak, MAXDOP deyiminde varsayılan değerinden daha yüksek bir değer belirtmek, daha yüksek CPU kullanımı pahasına yeniden oluşturma süresini kısaltabilir.

• rowstore dizinleri için yeniden yapılandırma, dizinin tüm düzeylerindeki parçalanmayı kaldırır ve sayfaları belirtilen veya geçerli dolgu faktörüne göre sıkıştırır. ALL belirtildiğinde, tablodaki tüm dizinler tek bir işlemde silinir ve yeniden oluşturulur. 128 veya daha fazla uzantıya sahip dizinler yeniden oluşturulduğunda, Veritabanı Motoru sayfa ayırmalarını erteler ve ilişkili kilitlerin alınmasını yeniden oluşturma tamamlandıktan sonraya bırakır. Sözdizimi örnekleri için bkz. Örnekler - Rowstore yeniden oluşturma.

• Columnstore dizinleri için yeniden derleme parçalanmayı kaldırır, delta deposu satırlarını columnstore'a taşır ve silinmek üzere işaretlenmiş satırları fiziksel olarak siler. Söz dizimi örnekleri için bkz. Örnekler - Columnstore yeniden oluşturma.

  Tip

  SQL Server 2016'dan (13.x) başlayarak, REORGANIZE çevrimiçi bir işlem olarak yeniden derlemenin temellerini gerçekleştirdiğinden columnstore dizinini yeniden oluşturmak genellikle gerekli değildir.

Veri bozulmasından kurtarmak için dizin yeniden derlemeyi kullanma

SQL Server 2008'den (10.0.x) önce, bazen dizindeki veri bozulması nedeniyle tutarsızlıkları düzeltmek için bir satır deposu kümelenmemiş dizini yeniden derleyebiliyordunuz.

Yine de, kümelenmemiş bir dizini çevrimdışı olarak yeniden oluşturarak, kümelenmemiş dizindeki bu tür tutarsızlıkları onarabilirsiniz. Ancak, çevrimiçi yeniden derleme mekanizması yeniden derlemenin temeli olarak mevcut kümelenmemiş dizini kullandığından ve bu nedenle tutarsızlığı taşıdığından, dizini çevrimiçi olarak yeniden oluşturarak kümelenmemiş dizin tutarsızlıklarını onaramazsınız. Dizini çevrimdışı yeniden oluşturmak bazen kümelenmiş dizinin (veya yığının) taranmasına zorlanabilir ve bu nedenle, kümelenmemiş dizindeki tutarsız verileri kümelenmiş dizin veya yığındaki verilerle değiştirin.

Kümelenmiş dizinin veya yığının veri kaynağı olarak kullanıldığından emin olmak için, kümelenmemiş dizini yeniden oluşturmak yerine onu düşürüp yeniden oluşturun. Önceki sürümlerde olduğu gibi, etkilenen verileri bir yedekten geri yükleyerek tutarsızlıklardan kurtarabilirsiniz. Ancak, kümelenmemiş dizin tutarsızlıklarını çevrimdışı olarak yeniden oluşturarak veya yeniden yaratarak onarabilirsiniz. Daha fazla bilgi için bkz. DBCC CHECKDB (Transact-SQL).

Otomatik dizin ve istatistik yönetimi

Bir veya daha fazla veritabanının dizin parçalanma ve istatistik güncelleştirmelerini otomatik olarak yönetmek için Uyarlamalı Dizin Birleştirme gibi çözümleri kullanın. Bu yordam, diğer parametrelerin yanında bir dizini parçalanma düzeyine göre yeniden derlemeyi veya yeniden düzenlemeyi ve istatistikleri doğrusal bir eşikle güncelleştirmeyi otomatik olarak seçer.

Rowstore dizinlerini yeniden derlemeye ve yeniden düzenlemeye özgü dikkat edilmesi gerekenler

Aşağıdaki senaryolar, tablodaki tüm satır deposu kümelenmemiş dizinlerin otomatik olarak yeniden oluşturulmasına neden olur:

• CREATE CLUSTERED INDEX ... WITH (DROP_EXISTING = ON) kullanarak kümelenmiş dizini farklı bir anahtarla yeniden oluşturmak da dahil olmak üzere tabloda kümelenmiş dizin oluşturma
• Kümelenmiş bir dizinin kaldırılması, tablonun yığın olarak depolanmasına neden olur.

Aşağıdaki senaryolar, aynı tablodaki tüm satır deposu kümelenmemiş dizinleri otomatik olarak yeniden oluşturmaz:

• Kümelenmiş dizini yeniden oluşturma
• Bölümleme şeması uygulama veya kümelenmiş dizini farklı bir dosya grubuna taşıma gibi kümelenmiş dizin depolama alanını değiştirme

Important

Dizinin bulunduğu dosya grubu çevrimdışı veya salt okunursa dizin yeniden düzenlenemez veya yeniden oluşturulamaz. ALL anahtar sözcüğü belirtildiğinde ve bir veya daha fazla dizin çevrimdışı veya salt okunur bir dosya grubunda olduğunda, deyimi başarısız olur.

Dizin yeniden oluşturma işlemi gerçekleşirken, fiziksel medyanın dizinin iki kopyasını depolamak için yeterli alana sahip olması gerekir. Yeniden derleme tamamlandığında Veritabanı Altyapısı özgün dizini siler.

ALL, ALTER INDEX ... REORGANIZE anlatımıyla belirtildiğinde, tablodaki kümelenmiş, kümelenmemiş ve XML dizinleri yeniden düzenlenir.

Küçük rowstore dizinlerinin yeniden oluşturulması veya yeniden düzenlenmesi genellikle parçalanmayı azaltmaz. SQL Server 2014 (12.x) dahil olmak üzere, SQL Server Veritabanı Altyapısı karma kapsamları kullanarak alan ayırır. Bu nedenle, küçük dizinlerin sayfaları bazen karışık uzantılarda depolanır ve bu da bu tür dizinleri örtük olarak parçalı hale getirir. Karma uzantılar en fazla sekiz nesne tarafından paylaşılır, bu nedenle küçük bir dizindeki parçalanma tekrar düzenlendikten veya tekrar oluşturulduktan sonra azalmayabilir.

Columnstore dizinini yeniden oluşturmak için dikkat edilmesi gerekenler

Bir columnstore dizinini yeniden oluştururken Veritabanı Altyapısı, delta deposu da dahil olmak üzere özgün columnstore dizinindeki tüm verileri okur. Verileri yeni satır grupları halinde birleştirir ve tüm satır gruplarını columnstore'da sıkıştırır. Veritabanı Altyapısı, silinmiş olarak işaretlenmiş satırları fiziksel olarak silerek columnstore'u parçalardan arındırır.

Note

SQL Server 2019 (15.x) itibarıyla, "tuple mover" işlemi, belirli bir süre boyunca var olan daha küçük açık delta depolarını otomatik olarak sıkıştıran veya çok sayıda satırın silindiği sıkıştırılmış satır gruplarını birleştiren, iç bir eşik tarafından belirlenen bir arka plan birleştirme göreviyle desteklenmektedir. Bu, columnstore dizin kalitesini zaman içinde artırır. Columnstore terimleri ve kavramları hakkında daha fazla bilgi için bkz. Columnstore dizinleri: Genel bakış.

Tablonun tamamı yerine bir bölümü yeniden oluşturun

Dizinin büyük olması durumunda tablonun tamamının yeniden oluşturulması uzun sürer ve yeniden derleme sırasında dizinin tamamının bir kopyasını depolamak için yeterli disk alanı gerektirir.

Bölümlenmiş tablolar için, parçalanma yalnızca bazı bölümlerde( örneğin , veya UPDATE deyimlerinin çok sayıda satırı değiştirdiği DELETEMERGEbölümlerde) mevcutsa columnstore dizininin tamamını yeniden oluşturmanız gerekmez.

Verileri yükledikten veya değiştirdikten sonra bölümü yeniden oluşturmak, tüm verilerin columnstore'daki sıkıştırılmış satır gruplarında depolanmasını sağlar. Veri yükleme işlemi 102.400 satırdan küçük toplu işlemleri kullanarak bir bölüme veri eklediğinde, bölüm delta deposunda birden çok açık satır grubuyla sonuçlanabilir. Yeniden derleme, tüm delta deposu satırlarını columnstore'daki sıkıştırılmış satır gruplarına taşır.

Columnstore dizinini yeniden düzenlemeye özgü önemli noktalar

Bir columnstore dizinini yeniden düzenlerken, Veritabanı Motoru delta deposundaki her kapalı satır grubunu sıkıştırılmış satır grubu olarak columnstore'a dönüştürür. SQL Server 2016 (13.x) ve Azure SQL Veritabanı'nda başlayarak, REORGANIZE komutu çevrimiçi olarak aşağıdaki ek birleştirme iyileştirmelerini gerçekleştirir:

• 10% veya daha fazlası mantıksal olarak silindiğinde satır grubundan satırları fiziksel olarak kaldırır. Örneğin, 1 milyon satırlık sıkıştırılmış bir satır grubunda 100.000 satır silinmişse, Veritabanı Altyapısı silinen satırları kaldırır ve 900.000 satır içeren satır grubunu yeniden sıkıştırarak depolama alanı ayak izini azaltır.
• Satır grubu başına en fazla 1.048.576 satır olacak şekilde satırları artırmak için bir veya daha fazla sıkıştırılmış satır grubunu birleştirir. Örneğin, her biri 102.400 satırdan oluşan beş veri kümesini eklediğinizde, beş sıkıştırılmış satır grubu elde edersiniz. REORGANIZE komutunu çalıştırırsanız, bu satır grupları 512.000 satır içeren sıkıştırılmış bir satır grubunda birleştirilir. Bu, sözlük boyutu veya bellek sınırlamaları olmadığını varsayar.
• Veritabanı Altyapısı, 10% veya daha fazla satırın silinmiş olarak işaretlendiği satır gruplarını diğer satır gruplarıyla birleştirmeyi dener. Örneğin, 1. satır grubu sıkıştırılır ve 500.000 satıra sahipken, satır grubu 21 sıkıştırılmıştır ve 1.048.576 satırı vardır. Rowgroup 21'in silinmiş olarak işaretlenmiş 60% satırı vardır ve bu da 409.830 satır bırakır. Veritabanı Altyapısı, 909.830 satırı olan yeni bir satır grubunu sıkıştırmak için bu iki satır grubunu birleştirmeyi tercih eder.

Veri yüklemelerini gerçekleştirdikten sonra, delta deposunda birden çok küçük satır grubunuz olabilir. ALTER INDEX REORGANIZE kullanarak bu satır gruplarını columnstore'a zorlayabilir ve daha küçük sıkıştırılmış satır gruplarını daha büyük sıkıştırılmış satır grupları halinde birleştirebilirsiniz. Yeniden düzenleme işlemi, columnstore'da silinmiş olarak işaretlenen satırları da kaldırır.

Note

Management Studio kullanarak bir columnstore dizinini yeniden düzenlemek, sıkıştırılmış satır gruplarını bir araya getirir, ancak tüm satır gruplarının columnstore'a sıkıştırılmasını zorunlu hale getirmez. Kapalı satır grupları sıkıştırılır, ancak açık satır grupları columnstore'da sıkıştırılamaz. Tüm satır gruplarını zorla sıkıştırmak için, Transact-SQL örnek kullanan ve COMPRESS_ALL_ROW_GROUPS = ONiçeren bir örnek kullanın.

Dizin bakımı gerçekleştirmeden önce dikkat edilmesi gerekenler

Dizini yeniden düzenleyerek veya yeniden oluşturarak gerçekleştirilen dizin bakımı yoğun kaynak kullanır. CPU kullanımında, kullanılan bellekte ve depolama G/Ç'sinde önemli bir artışa neden olur. Ancak, veritabanı iş yüküne ve diğer faktörlere bağlı olarak sağladığı avantajlar, hayati önem taşıyandan eksiye kadar değişir.

Gereksiz kaynak kullanımından kaçınmak için dizin bakımını ayrım gözetmeden gerçekleştirmekten kaçının. Bunun yerine, dizin bakımının performans avantajları, önerilenstratejisi kullanılarak her iş yükü için ampirik olarak belirlenmeli ve bu avantajları elde etmek için gereken kaynak maliyetlerine ve iş yükü etkisine karşı tartılmalıdır.

Dizin yoğun şekilde parçalandığında veya sayfa yoğunluğu düşük olduğunda, bir dizini yeniden düzenlemenin veya yeniden derlemenin performans avantajlarını görme olasılığı daha yüksektir. Ancak, dikkate alınması gereken tek şey bunlar değildir. Sorgu desenleri (işlem işleme ve analiz ve raporlama), depolama alt sistemi davranışı, kullanılabilir bellek ve zaman içindeki veritabanı altyapısı geliştirmeleri gibi faktörlerin tümü rol oynar.

Important

Dizin bakımı kararları, her bir iş yükünün belirli bağlamında bakım kaynağı maliyeti de dahil olmak üzere birden çok faktör dikkate alınarak verilmelidir. Bunlar yalnızca sabit parçalanma veya sayfa yoğunluğu eşiklerini temel almamalıdır.

Dizin yeniden oluşturmanın olumlu bir yan etkisi

Müşteriler genellikle dizinleri yeniden derledikten sonra performans iyileştirmelerini gözlemler. Ancak, çoğu durumda bu iyileştirmeler parçalanmayı azaltma veya sayfa yoğunluğunun artmasıyla ilişkili değildir.

Dizin yeniden oluşturmanın önemli bir avantajı vardır: dizindeki tüm satırları tarayarak dizinin önemli sütunlarında istatistikleri güncelleştirir. Bu, istatistikleri güncel hale getiren ve bazen varsayılan örneklenmiş istatistik güncelleştirmesi ile karşılaştırıldığında kalitesini artıran UPDATE STATISTICS ... WITH FULLSCANyürütmenin eşdeğeridir. İstatistikler güncelleştirildiğinde, bunlara başvuran sorgu planları yeniden derlenir. Bir sorgunun önceki planı eski istatistikler, yetersiz istatistik örnekleme oranı veya başka nedenlerle en iyi duruma getirilmediyse, yeniden derlenen plan genellikle daha iyi performans gösterir.

Müşteriler genellikle bu iyileştirmeyi yanlış bir şekilde dizin yeniden oluşturulmasına bağlar ve bunun daha az parçalanma ve artan sayfa yoğunluğunun bir sonucu olduğunu düşünürler. Gerçekte aynı avantaj genellikle dizinleri yeniden oluşturmak yerine istatistikleri güncelleştirerek çok daha düşük bir kaynak maliyetiyle elde edilebilir.

Tip

İstatistikleri güncelleştirmenin kaynak maliyeti dizin yeniden derlemesine kıyasla küçük bir maliyettir ve işlem genellikle dakikalar içinde tamamlanır. Dizin yeniden oluşturma işlemleri saatler sürebilir.

Dizin bakım stratejisi

Microsoft, müşterilerin aşağıdaki dizin bakım stratejisini göz önünde bulundurmalarını ve benimsemelerini önerir:

• Dizin bakımının iş yükünüzü her zaman belirgin bir şekilde iyileştirdiğini varsaymayın.
• Dizinleri yeniden düzenlemenin veya yeniden derlemenin iş yükünüzdeki sorgu performansı üzerindeki etkisini ölçün. Sorgu Deposu, A/B test tekniğini kullanarak "bakımdan önce" ve "bakımdan sonra" performansı ölçmenin iyi bir yoludur.
• Dizinleri yeniden oluşturmanın performansı artırdığını gözlemlerseniz, istatistikleri güncelleştirmekle değiştirmeyi deneyin. Bu da benzer bir gelişmeye neden olabilir. Bu durumda, dizinleri sık sık veya hiç yeniden oluşturmanız gerekmeyebilir ve bunun yerine düzenli istatistik güncelleştirmeleri gerçekleştirebilirsiniz. Bazı istatistikler için WITH SAMPLE ... PERCENT veya WITH FULLSCAN yan tümcelerini kullanarak örnekleme oranını artırmanız gerekebilir (bu yaygın değildir).
• Dizin parçalanmasını ve sayfa yoğunluğunu zaman içinde izleyerek bu değerlerin yukarı veya aşağı eğilim göstermesi ile sorgu performansı arasında bir ilişki olup olmadığını görmeye çalışın. Daha yüksek parçalanma veya daha düşük sayfa yoğunluğu performansı kabul edilemez şekilde düşürürse dizinleri yeniden düzenleyin veya yeniden derleyin. Genellikle yalnızca performansı düşürülmüş sorgular tarafından kullanılan belirli dizinleri yeniden düzenlemek veya yeniden oluşturmak yeterlidir. Bu, veritabanındaki tüm dizinlerin bakımının daha yüksek bir kaynak maliyetini önler.
• Parçalanma/sayfa yoğunluğu ve performans arasında bağıntı oluşturmak, dizin bakımının sıklığını belirlemenizi de sağlar. bakımın sabit bir zamanlamaya göre gerçekleştirilmesi gerektiğini varsaymayın. Daha iyi bir strateji parçalanma ve sayfa yoğunluğu izlemek ve performans kabul edilemez bir şekilde azalmadan önce dizin bakımını gerektiği gibi çalıştırmaktır.
• Dizin bakımı gerektiğini ve kaynak maliyetinin kabul edilebilir olduğunu belirlediyseniz, mümkünse düşük kaynak kullanım sürelerinde bakım gerçekleştirin.
• Kaynak kullanım düzenleri zamanla değişebileceğinden periyodik olarak test edin.

Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği'nde dizin bakımı

Yukarıdaki önemli noktalara ve stratejiye ek olarak, Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği'nde dizin bakımının maliyetlerini ve avantajlarını göz önünde bulundurmak özellikle önemlidir. Müşteriler bunu yalnızca belirli bir ihtiyaç olduğunda ve aşağıdaki noktaları dikkate alarak gerçekleştirmelidir.

• Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği, sağlanan fiyatlandırma katmanına göre CPU, bellek ve G/Ç tüketimi sınırlarını ayarlamak için kaynak idaresi uygular. Bu sınırlar, dizin bakımı da dahil olmak üzere tüm kullanıcı iş yükleri için geçerlidir. Tüm iş yükleri tarafından toplu kaynak tüketimi kaynak sınırlarına yaklaşırsa, yeniden oluşturma veya yeniden düzenleme işlemi kaynak çekişmesi nedeniyle diğer iş yüklerinin performansını düşürebilir. Örneğin, eşzamanlı bir dizin yeniden oluşturma işlemi nedeniyle işlem günlüğü G/Ç değeri 100% olduğunda, toplu veri yüklemeleri yavaşlayabilir. Azure SQL Yönetilen Örneği'nde dizin bakımı, dizin bakım süresini uzatmak pahasına kısıtlanmış kaynak ayırmaya sahip ayrı bir kaynak yöneticisi iş yükü grubunda çalıştırılarak bu etki azaltılabilir.
• Maliyet tasarrufu amaçlı, müşteriler genellikle veritabanlarını, elastik havuzları ve yönetilen örnekleri minimum kaynak payıyla sağlamak amacıyla kullanırlar. Fiyatlandırma katmanı, uygulama iş yükleri için yeterli olacak şekilde seçilir. Uygulama performansını düşürmeden dizin bakımı nedeniyle kaynak kullanımında önemli bir artışa uyum sağlamak için müşterilerin uygulama performansını artırmadan daha fazla kaynak sağlaması ve maliyetleri artırması gerekebilir.
• Elastik havuzlarda kaynaklar havuzdaki tüm veritabanları arasında paylaşılır. Belirli bir veritabanı boşta olsa bile, bu veritabanında dizin bakımı yapmak aynı havuzdaki diğer veritabanlarında eşzamanlı olarak çalışan uygulama iş yüklerini etkileyebilir. Daha fazla bilgi için bkz. Yoğun elastik havuzlarda kaynak yönetimi.
• Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği'nde kullanılan çoğu depolama türü için sıralı G/Ç ile rastgele G/Ç arasında performans farkı yoktur. Bu, dizin parçalanma işleminin sorgu performansı üzerindeki etkisini azaltır.
• Okuma Ölçeği Genişletme veya Coğrafi çoğaltma kullanılırken, birincil çoğaltmada dizin bakımı yapılırken çoğaltmalardaki veri gecikme süresi genellikle artar. Coğrafi replik, dizin bakımı nedeniyle işlem günlüğü üretiminde bir artışı sürdürecek yeterli kaynaklarla sağlanmazsa, birincilin çok gerisinde kalarak sistemin onu yeniden tohumlamasına neden olabilir. Yeniden tohumlama tamamlanana kadar replikasyonun kullanılamaz hale gelmesine neden olur. Ayrıca, Premium ve İş Açısından Kritik hizmet katmanlarında, yüksek kullanılabilirlik için kullanılan çoğaltmalar dizin bakımı sırasında benzer şekilde birincil sunucunun çok gerisinde kalabilir. Dizin bakımı sırasında veya hemen sonrasında bir yük devretme gerekiyorsa, beklenenden daha uzun sürebilir.
• Bir dizin yeniden oluşturma işlemi birincil çoğaltmada çalıştırılırsa ve uzun süreli bir sorgu aynı anda okunabilir bir çoğaltmada yürütülürse, sorgu, çoğaltmadaki yeniden oynatma iş parçacığının engellenmesini önlemek amacıyla otomatik olarak sonlandırılabilir.

Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği'nde tek seferlik veya düzenli dizin bakımı gerekebileceği belirli ancak yaygın olmayan senaryolar vardır:

• Sayfa yoğunluğu artırmak ve veritabanında kullanılan alanı azaltmak ve böylece fiyatlandırma katmanının boyut sınırında kalmak için. Bu, daha yüksek bir boyut sınırına sahip daha yüksek bir fiyatlandırma katmanına geçmeyi gerektirmez.
• Dosyaları küçültmek gerekirse, sayfa yoğunluğunun artırılması için küçültmeden önce dizinleri yeniden oluşturmayı veya yeniden düzenlemeyi göz önünde bulundurun. Bu, daha az sayfa taşıması gerektiğinden küçültme işlemini hızlandırır. Daha fazla bilgi için şu adresi ziyaret edin:
  • Azure SQL Veritabanı veritabanları için dosya alanını yönetme
  • Azure SQL Yönetilen Örneği'ndeki veritabanları için dosya alanını yönetme

Tip

Azure SQL Veritabanınız ve Azure SQL Yönetilen Örneği iş yükleriniz için dizin bakımının gerekli olduğunu belirlerseniz, dizinleri yeniden düzenlemeli veya çevrimiçi dizin yeniden oluşturmayı kullanmalısınız. Bu, dizinler yeniden oluşturulurken sorgu iş yüklerinin tablolara erişmelerini sağlar.

Buna ek olarak, işlemin devam ettirilebilir hale getirilmesi, planlanan veya planlanmamış bir veritabanı yük devretmesi nedeniyle kesintiye uğrarsa yeniden başlatmayı önlemenizi sağlar. Dizinler büyük olduğunda, devam ettirilebilen dizin işlemlerinin kullanılması özellikle önemlidir.

Tip

Çevrimdışı dizin işlemleri genellikle çevrimiçi işlemlerden daha hızlı tamamlanır. Tablolara işlem sırasında sorgular tarafından erişilmediğinde, örneğin sıralı ETL işleminin bir parçası olarak verileri hazırlama tablolarına yükledikten sonra kullanılmalıdır.

Sınırlamalar ve kısıtlamalar

128'den fazla uzantıya sahip rowstore dizinleri iki ayrı aşamada yeniden oluşturulur: mantıksal ve fiziksel. Mantıksal aşamada, dizin tarafından kullanılan mevcut ayırma birimleri ayırma için işaretlenir, veri satırları kopyalanır ve sıralanır, ardından yeniden oluşturulmuş dizini depolamak amacıyla oluşturulan yeni ayırma birimlerine taşınır. Fiziksel aşamada, daha önce serbest bırakma için işaretlenmiş ayırma birimleri, arka planda gerçekleşen kısa işlemler sırasında fiziksel olarak kaldırılır ve bu, çok fazla kilit gerektirmez. Ayırma birimleri hakkında daha fazla bilgi için bkz. Sayfalar ve Kapsamlar Mimari Kılavuzu.

ALTER INDEX REORGANIZE deyimi, dizini içeren veri dosyasının kullanılabilir alana sahip olmasını gerektirir, çünkü işlem aynı dosya grubundaki başka bir dosyada değil, yalnızca aynı dosyadaki geçici çalışma sayfalarını ayırabilir. Dosya grubunda boş alan olsa da, kullanıcı yine de 1105: Could not allocate space for object '###' in database '###' because the '###' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup veri dosyasının alanı yetersizse yeniden düzenleme işlemi sırasında hatayla karşılaşabilir.

Dizin ALLOW_PAGE_LOCKS KAPALI olarak ayarlandığında yeniden düzenlenemez.

SQL Server 2017'ye (14.x) kadar kümelenmiş columnstore dizinini yeniden oluşturmak çevrimdışı bir işlemdir. Yeniden oluşturma işlemi gerçekleşirken Veritabanı Motoru'nun tablo veya bölüm üzerinde münhasır bir kilit edinmesi gerekir. Veriler çevrimdışıdır ve yeniden oluşturma sırasında NOLOCK, okuma onaylı anlık görüntü yalıtımı (RCSI) veya anlık görüntü yalıtımı kullanılsa bile erişilemez. SQL Server 2019 (15.x) ile başlayarak, kümelenmiş columnstore dizini ONLINE = ON seçeneği kullanılarak yeniden oluşturulabilir.

Warning

1.000'den fazla bölümü olan bir tabloda hizalanmamış dizinler oluşturmak ve yeniden oluşturmak mümkündür, ancak desteklenmez. Bu, bu işlemler sırasında performansın düşmesine veya aşırı bellek tüketimine neden olabilir. Microsoft, bölüm sayısı 1.000'i aştığında yalnızca hizalanmış dizinlerin kullanılmasını önerir.

İstatistik sınırlamaları

• bir dizin veya yeniden oluşturulduğunda, istatistikler tablodaki tüm satırlar taranarak oluşturulur veya güncelleştirilir. Bu, FULLSCAN veya CREATE STATISTICSUPDATE STATISTICS yan tümcesini kullanmaya eşdeğerdir. Ancak, SQL Server 2012(11.x) ile başlayarak, bölümlenmiş dizin oluşturulduğunda veya yeniden oluşturulduğunda, tablodaki tüm satırlar taranarak istatistikler oluşturulmaz veya güncelleştirilmez. Bunun yerine varsayılan örnekleme oranı kullanılır. Tablodaki tüm satırları tarayarak bölümlenmiş dizinlerle ilgili istatistikler oluşturmak veya güncelleştirmek için, yan tümcesiyle CREATE STATISTICS veya FULLSCAN kullanın.
• Benzer şekilde, dizin oluşturma veya yeniden oluşturma işlemi devam ettirilebilir olduğunda istatistikler oluşturulur veya varsayılan örnekleme oranıyla güncelleştirilir. İstatistikler oluşturulduysa veya en son PERSIST_SAMPLE_PERCENT yan tümcesi ONolarak ayarlandıysa, devam ettirilebilen dizin işlemleri istatistikleri oluşturmak veya güncelleştirmek için kalıcı örnekleme oranını kullanır.
• Dizin yeniden düzenlendiğinde istatistikler güncelleştirilmez.

Examples

Satır deposu dizininin parçalanmasını ve sayfa yoğunluğunu denetleyin

Aşağıdaki örnek, geçerli veritabanındaki tüm satır deposu dizinleri için ortalama parçalanmayı ve sayfa yoğunluğuyu belirler. İşlem yapılabilir sonuçları hızlı bir şekilde döndürmek için SAMPLED modunu kullanır. Daha doğru sonuçlar için DETAILED modunu kullanın. Bu, tüm dizin sayfalarını taramayı gerektirir ve uzun sürebilir.

SELECT OBJECT_SCHEMA_NAME(ips.object_id) AS schema_name,
       OBJECT_NAME(ips.object_id) AS object_name,
       i.name AS index_name,
       i.type_desc AS index_type,
       ips.avg_fragmentation_in_percent,
       ips.avg_page_space_used_in_percent,
       ips.page_count,
       ips.alloc_unit_type_desc
FROM sys.dm_db_index_physical_stats(DB_ID(), default, default, default, 'SAMPLED') AS ips
INNER JOIN sys.indexes AS i
ON ips.object_id = i.object_id
   AND
   ips.index_id = i.index_id
ORDER BY page_count DESC;

Önceki deyim aşağıdakine benzer bir sonuç kümesi döndürür:

schema_name  object_name           index_name                               index_type    avg_fragmentation_in_percent avg_page_space_used_in_percent page_count  alloc_unit_type_desc
------------ --------------------- ---------------------------------------- ------------- ---------------------------- ------------------------------ ----------- --------------------
dbo          FactProductInventory  PK_FactProductInventory                  CLUSTERED     0.390015600624025            99.7244625648629               3846        IN_ROW_DATA
dbo          DimProduct            PK_DimProduct_ProductKey                 CLUSTERED     0                            89.6839757845318               497         LOB_DATA
dbo          DimProduct            PK_DimProduct_ProductKey                 CLUSTERED     0                            80.7132814430442               251         IN_ROW_DATA
dbo          FactFinance           NULL                                     HEAP          0                            99.7982456140351               239         IN_ROW_DATA
dbo          ProspectiveBuyer      PK_ProspectiveBuyer_ProspectiveBuyerKey  CLUSTERED     0                            98.1086236718557               79          IN_ROW_DATA
dbo          DimCustomer           IX_DimCustomer_CustomerAlternateKey      NONCLUSTERED  0                            99.5197553743514               78          IN_ROW_DATA

Daha fazla bilgi için bkz. sys.dm_db_index_physical_stats.

Columnstore dizininin parçalanma durumunu denetleme

Aşağıdaki örnek, geçerli veritabanında sıkıştırılmış satır gruplarına sahip tüm columnstore dizinleri için ortalama parçalanmayı belirler.

WITH columnstore_row_group_partition
AS (SELECT object_id,
           index_id,
           partition_number,
           SUM(deleted_rows) AS partition_deleted_rows,
           SUM(total_rows) AS partition_total_rows
    FROM sys.dm_db_column_store_row_group_physical_stats
    WHERE state_desc = 'COMPRESSED'
    GROUP BY object_id, index_id, partition_number),
/* For nonclustered columnstore, include rows in the delete buffer */
 columnstore_internal_partition
AS (SELECT object_id,
           index_id,
           partition_number,
           SUM(rows) AS delete_buffer_rows
    FROM sys.internal_partitions
    WHERE internal_object_type_desc = 'COLUMN_STORE_DELETE_BUFFER'
    GROUP BY object_id, index_id, partition_number)
SELECT OBJECT_SCHEMA_NAME(i.object_id) AS schema_name,
       OBJECT_NAME(i.object_id) AS object_name,
       i.name AS index_name,
       i.type_desc AS index_type,
       crgp.partition_number,
       100.0 * (ISNULL(crgp.partition_deleted_rows + ISNULL(cip.delete_buffer_rows, 0), 0)) / NULLIF (crgp.partition_total_rows, 0) AS avg_fragmentation_in_percent
FROM sys.indexes AS i
     INNER JOIN columnstore_row_group_partition AS crgp
         ON i.object_id = crgp.object_id
        AND i.index_id = crgp.index_id
     LEFT OUTER JOIN columnstore_internal_partition AS cip
         ON i.object_id = cip.object_id
        AND i.index_id = cip.index_id
        AND crgp.partition_number = cip.partition_number
ORDER BY schema_name, object_name, index_name, partition_number, index_type;

Önceki ifadede, aşağıdaki çıktıya benzer bir sonuç kümesi döndürür:

schema_name  object_name            index_name                           index_type                avg_fragmentation_in_percent
------------ ---------------------- ------------------------------------ ------------------------- ----------------------------
Sales        InvoiceLines           NCCX_Sales_InvoiceLines              NONCLUSTERED COLUMNSTORE  0.000000000000000
Sales        OrderLines             NCCX_Sales_OrderLines                NONCLUSTERED COLUMNSTORE  0.000000000000000
Warehouse    StockItemTransactions  CCX_Warehouse_StockItemTransactions  CLUSTERED COLUMNSTORE     4.225346161484279

SQL Server Management Studio kullanarak dizinleri koruma

Dizini yeniden düzenlemek veya yeniden oluşturmak

1. Nesne Gezgini'de, dizinini yeniden düzenlemek istediğiniz tabloyu içeren veritabanını genişletin.
2. Tablolar klasörünü genişletin.
3. Dizini yeniden düzenlemek istediğiniz tabloyu genişletin.
4. Dizinler klasörünü genişletin.
5. Yeniden düzenlemek istediğiniz dizine sağ tıklayın ve Yeniden Düzenle'yi seçin.
6. Dizinleri Yeniden Düzenle iletişim kutusunda, Yeniden Düzenlenecek Dizinler kılavuzunda doğru indeksin olduğunu kontrol edin ve Tamamdüğmesine tıklayın.
7. Büyük nesne (LOB) verileri içeren tüm sayfaların da sıkıştırılacağını belirtmek için Büyük nesne sütun verilerini sıkıştır onay kutusunu seçin.
8. Tamam'ı seçin.

Tablodaki tüm dizinleri yeniden düzenleme

1. Nesne Gezginiiçinde, dizinleri yeniden düzenlemek istediğiniz tabloyu içeren veritabanını genişletin.
2. Tablolar klasörünü genişletin.
3. Dizinleri yeniden düzenlemek istediğiniz tabloyu genişletin.
4. Dizinler klasörüne sağ tıklayın ve TümYeniden Düzenle'yi seçin.
5. Dizinleri Yeniden Düzenle iletişim kutusunda, yeniden düzenlenecekDizinlerinde doğru dizinlerin olduğunu doğrulayın. yeniden düzenlenecek Dizinleri'nden bir dizini kaldırmak kılavuzu seçin ve delete tuşuna basın.
6. Büyük nesne (LOB) verileri içeren tüm sayfaların da sıkıştırılacağını belirtmek için Büyük nesne sütun verilerini sıkıştır onay kutusunu seçin.
7. Tamam'ı seçin.

Transact-SQL kullanarak dizinleri koruma

Note

Dizinleri yeniden oluşturmak veya yeniden düzenlemek için Transact-SQL kullanma hakkında daha fazla örnek için bkz. ALTER INDEX Örnekleri - Satır Deposu Dizinleri ve ALTER INDEX Örnekleri - Sütun Deposu Dizinleri.

Dizini yeniden düzenleme

Aşağıdaki örnek, IX_Employee_OrganizationalLevel_OrganizationalNode veritabanındaki HumanResources.Employee tablosundaki AdventureWorks2025 dizinini yeniden düzenler.

ALTER INDEX IX_Employee_OrganizationalLevel_OrganizationalNode
    ON HumanResources.Employee
    REORGANIZE;

Aşağıdaki örnek, IndFactResellerSalesXL_CCI veritabanındaki dbo.FactResellerSalesXL_CCI tablosundaki AdventureWorksDW2025 columnstore dizinini yeniden düzenler. Bu komut, tüm kapalı ve açık satır gruplarını sütun deposu formatına dönüştürür.

-- This command forces all closed and open row groups into columnstore.
ALTER INDEX IndFactResellerSalesXL_CCI
    ON FactResellerSalesXL_CCI
    REORGANIZE WITH (COMPRESS_ALL_ROW_GROUPS = ON);

Tablodaki tüm dizinleri yeniden düzenleme

Aşağıdaki örnek, HumanResources.Employee veritabanındaki AdventureWorks2025 tablosundaki tüm dizinleri yeniden düzenler.

ALTER INDEX ALL ON HumanResources.Employee
   REORGANIZE;

Dizini yeniden oluşturma

Aşağıdaki örnek, Employee veritabanındaki AdventureWorks2025 tablosundaki tek bir dizini yeniden oluşturur.

ALTER INDEX PK_Employee_BusinessEntityID ON HumanResources.Employee
REBUILD
;

Tablodaki tüm dizinleri yeniden oluşturma

Aşağıdaki örnek, AdventureWorks2025 anahtar sözcüğünü kullanarak ALL veritabanındaki tabloyla ilişkili tüm dizinleri yeniden oluşturur. Üç seçenek belirtilir.

ALTER INDEX ALL ON Production.Product
REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
              STATISTICS_NORECOMPUTE = ON)
;

Daha fazla bilgi için bkz. ALTER INDEX .

İlgili içerik

• SQL Server ve Azure SQL dizin mimarisini ve tasarım kılavuzunu
• Dizin işlemlerini çevrimiçi gerçekleştirme
• alter index (Transact-SQL)
• Uyarlamalı Dizin Parçalama
• İSTATİSTİK OLUŞTUR (Transact-SQL)
• İSTATİSTİKLERİ GÜNCELLE (Transact-SQL)
• Columnstore dizinleri - sorgu performansı
• Gerçek zamanlı operasyonel analiz için columnstore dizinlerini kullanmaya başlama
• Veri ambarı oluşturmada columnstore dizinleri
• Sütun deposu dizinleri ve satır grupları için birleştirme ilkesi