MSSQL Server’da Index REORGANIZE ve REBUILD İşlemlerini Belirleme

Mssql server veritabanlarında tablolar üzerinde yapılan insert,delete,update işlemleri zamanla index yapımızın bozulmasına sebep olacaktır. Buda bize performans anlamında ciddi sıkıntılara sebebiyet verecektir. Microsoft SQL Server’da rebuild ve reorganize işlemleri, indekslerin bakımını yapmak için kullanılan iki farklı yaklaşımdır. Her iki işlem de indekslerin performansını iyileştirerek sorgu sürelerini kısaltmaya yardımcı olur, ancak her biri farklı şekilde çalışır ve farklı durumlarda tercih edilir. İşte her iki işlemin detaylı açıklamaları:

1. İndex Rebuild

Rebuild işlemi, bir indeksin sıfırdan yeniden oluşturulması anlamına gelir. Bu işlem, indeksin bütünlüğünü yeniden sağlar ve fiziksel olarak yeniden düzenler.

Rebuild oluşturma işlemini yarıda iptal ederseniz, geri alınması gerekir (ve çevrimdışı yapılıyorsa, bu biraz zaman alabilir). Kısacası bu yapıyı açıklayalım.

SQL Server, index rebuild işlemi sırasında veri bütünlüğünü korumak için akıllı bir mekanizma kullanır. Index rebuild işlemi sırasında SQL Server şu adımları izler: Sunucu önce bellekte yeni bir index yapısı oluşturur. Bu yeni yapı boş bir şablon olarak başlar. Rebuild işlemi orijinal tablodan verileri okur (eski index’ten değil) Veriler SCAN operatörü ile fiziksel sıraya göre okunur. Tüm değişiklikler transaction log’a yazılır. Sistem arıza durumunda kurtarma için bu kritik öneme sahiptir. Eski Index Korunur. Rebuild tamamlanana kadar eski index yapısı silinmez. Çift yapı olur. Sunucu geçici olarak hem eski hem de yeni index yapısını tutar. Atomic Switch işlem tamamlandığında atomik bir geçiş yapılır. Online on ifadesi ile kullanıcılar işlem sırasında eski index’i kullanmaya devam etmektedir. Yeni index hazır olduğunda meta data değişikliği yapılmaktadır. Büyük veritabanlarında log dosyası aşırı büyüme yapacağından dolayı sort in tempdb parameteresi on yapılabilir.

Yeni tabloya veriler insert/update/delete yapıldığında bu değişiklikler hem yeni index’e hem de eski index’e uyarlanır.

Online off ifadesi kullanılmazsa yeni işlemler engellenmesi gerekmektedir. Tüm rebuild işlemleri sırasında tablo üzerinde exclusive lock bulunur. Tüm sorgular işlem tamamlanana kadar beklemektedir. Online ifadesine göre log kullanımı daha az olmaktadır. Online ifadesinde çoğunlukla a row lock oluşurken offline modunda exclusive lock oluşmaktadır.

Online on ifadesinden sonra index iptal edilirse orjinal tablo ve eski index yapısında hiç bir zaman bozulma olmaz. İlgili işlemin tahsis etmiş olduğu cpu-bellek ve temp alanı bırakılmış olur. Log dosyası rebuild işleminden dolayı sadece büyümüş olur.

100.000 satırlık tablo için online rebuild başlatıldı. 50.000 satır işlendikten sonra iptal edildi.
SQL Server’ın yaptıkları 50.000 satırlık kısmi index yapısını siler. Bu işlem sıralı bir şekilde yapılmaktadır. Tek seferde büyük silme rollback işlemleri ani yük oluşturup sisteme zarar verebilir. Bu sırada tabloya yapılan tüm değişiklikleri log’dan kontrol eder. Eski index’in bu değişiklikleri doğru yansıttığından emin olur. İşlem ne kadar ilerlemişse, rollback o kadar uzun sürer. Genellikle rebuild işlemden %30-50 daha uzun sürebilir

Rebuild işlemi paralel çalışabilirken, rollback genellikle tek thread’le çalışır. Sistem normalde rebuild için optimize edilmiştir, rollback için değil. Bunun için rollback işlemleri uzun sürmektedir.

Ne Zaman Yapılır?

• İndeksin yüksek oranda bozulduğu durumlarda (örneğin, %30’dan fazla fragmentasyonu varsa).
• Genellikle, performans sorunları yaşandığında veya veritabanı büyüdüğünde tercih edilir.

Süreç:

• İlgili indeksin tamamen silinmesi ve ardından yeniden oluşturulması yapılır.
• Rebuild işlemi, veritabanı tabloyu kilitleyebilir. Online=on kullanılması bu kilitlemeyi minimize eder.
• İndeksin tüm verileri sıralanır ve disk alanı daha verimli bir şekilde yeniden tahsis edilir.

Avantajları:

• İndeksin bozulmuş yapısını tamamen ortadan kaldırır.
• Veri sayısı arttıkça indeks performansını artırabilir.
• Daha az fragmantasyon, daha hızlı veri erişimi sağlar.

Dezavantajları:

• Zaman alıcı olabilir, özellikle büyük veritabanlarında.
• Disk alanı kullanımı geçici olarak artabilir (çünkü eski ve yeni indeks bir süre paralel olarak var olabilir).
• Yüksek sistem kaynağı tüketebilir.

-- Tek bir indeksi rebuild etmek için

ALTER INDEX [index_name] ON [table_name] REBUILD;

ALTER INDEX Index_Name ON Table_Name REBUILD WITH (FILLFACTOR = 70)

İlgili tablo altındaki tüm indexleri rebuild etmek için aşağıdaki komut kullanılmaktadır.

ALTER INDEX ALL ON TabloAdı REBUILD;

Genel Olarak:

• Clustered index rebuild sırasında tablo tamamen kilitlenebilir ve veri yazma işlemleri engellenebilir. Online=on kullanılması bu kilitlemeyi minimize eder.
• Non-clustered index rebuild sırasında tablo üzerinde veri yazma işlemleri daha az etkilenir, ancak indeks üzerinde kilitler olabilir ve bu da yazma performansını geçici olarak etkileyebilir.
• Clustered Index olan tablolarda, rebuild işlemi sırasında tablo kilitlenebilir. Bu, tabloyu tamamen kilitleyerek, veri ekleme, silme veya güncelleme işlemlerine engel olabilir. Özellikle, clustered index rebuild sırasında tablo üzerinde Shared Lock veya Exclusive Lock türleri uygulanabilir. Kesin uygulanacak diye bir kural yok.
•  Non-clustered index rebuild işlemi sırasında genellikle sadece ilgili indeksin üzerinde işlem yapılır, tablonun tamamı kilitlenmez, ancak yine de belirli indeks blokları üzerinde kilitler olabilir.

Not: Shared Lock ve Exclusive Lock SQL Server’da veri erişimi sırasında kullanılan iki farklı kilit türüdür. Her ikisi de veritabanı yönetim sistemi (DBMS) tarafından, verilerin doğru ve tutarlı bir şekilde erişilmesini sağlamak amacıyla kullanılır. Bu kilitler, işlem izolasyonu ve veri bütünlüğü için kritik öneme sahiptir. Shared Lock, verinin okunmasına izin verir ancak değiştirilmesine izin vermez. Bu kilit türü, bir işlem veriyi okurken başkalarının da aynı veriyi okumasına izin verir, fakat veriye yazma işlemi yapılmasına engel olur. SELECT sorguları, genellikle Shared Lock kullanır. Örneğin, SELECT sorguları veriyi okurken başka işlemler de aynı satırları okuyabilir.

Not: Exclusive Lock, verinin hem okunmasını hem de değiştirilmesini engeller. Bir işlem bir veriye Exclusive Lock uyguladığında, diğer işlemler bu veriye ne okuma ne de yazma yapabilir. Yani, bu kilit, veriyi tamamen kontrol altına alır. UPDATE, DELETE gibi işlemler genellikle Exclusive Lock kullanır.

Not: İndexs rebuild işlemi sırasında LDF (Transaction Log) dosyasının büyümesi mümkündür. Ancak, reorganize işlemi genellikle daha az log kullanır.   Rebuild işlemi, tam yeniden yapılandırma yaptığı için büyük miktarda transaction log verisi oluşturur. Bu, log dosyasının büyümesine yol açabilir. Full recovery model kullanıyorsanız, rebuild işlemi sırasında log dosyasındaki kayıtlar birikir ve log dosyasının büyümesine neden olur. Bu durumda, log dosyasının büyümesini izlemek ve gerektiğinde log yedeği almak önemlidir. Log dosyası büyürse backup alınması ve ardından shrink işleminin yapılması önerilmektedir. Alwayson yapılarında senkron sorunlarına sebebiyet verebilmektedir.

Not: Reorganize işlemi genellikle daha küçük bir etki yapar. Çünkü bu işlem, indeks üzerinde küçük düzenlemeler yapar ve genellikle transaction log üzerindeki etki daha az olur.

Not: Rebuild işlemini yarıda kesersen indeks bozulabilir veya silinebilir. Reorganize işlemi daha güvenlidir, işlem tamamlanmasa bile indeks kısmen optimize edilir. İşlem yaparken OLTP sistemlerde (canlı veritabanlarında) dikkatli olmalıyız, çünkü bu işlemler sorgu performansını geçici olarak düşürebilir.

Eğer büyük bir veritabanı üzerinde çalışıyorsan, online index rebuild veya periyodik bakım penceresi kullanarak bu riskleri minimize edebilirsin.

Not: Index rebuild işlemlerinde performans kaybı daha fazla olduğu için sıkıntı yaşayan sistemlerde Index Rebuild öncesi AG’yi asenkron moduna alınır. Otomatik failover işlemi veritabanında herhangi bir sorun anında veya transaction log dolması gibi sebeplerden dolayı geçmez sunucuda bulunan donanımsal bir hatadan dolayı failover işlemi gerçekleşmektedir.

Not: Index rebuild işlemi sırasında transaction log dosyasının şişmesi SQL Server’da sık karşılaşılan bir durumdur. Bunun temel nedenleri: Full/Bulk-Logged Recovery Model modlarda index rebuild işlemleri tamamen loglanır. Simple recovery model daha az log üretir, ancak log otomatik olarak truncate edilir. Bu yapıya geçildiğinde log zincirimiz bozulmaktadır. Index rebuild işlemi aslında eski indexi silip yenisini oluşturur. Tüm veri sayfaları yeniden yazılır. Her değişiklik transaction log’a kaydedilir. Online Rebuild: Daha fazla log üretir (kullanıcı erişimine izin verirken ek bilgi tutar) Offline Rebuild: Nispeten daha az log üretir. Minimal loglama tercih edilmesi isteniyor aynı zamanda log zinciri devam edilmesi isteniyorsa Bulk loged recovery modele geçiş yapılır. Tabi bu işlem stand alone veritabanları için geçerlidir. AlwaysOn veritabanlarında veritabanı Full recovery modelde olmak zorundadır.

Partition tablolarda Rebuild işlemini aşağıdaki komut aracılığıyla gerçekleştiririz. İlgili tablo üzerinde partition bazlı rebuild işlemi yapılmaktadır. Yada ALL ifadesi ile tüm partitionlar üzerinde işlem yapılmaktadır.

ALTER INDEX [Index_Adı] ON [Schema].[Tablo_Adı] 
REBUILD PARTITION = [Partition_Numarası]
WITH (ONLINE = ON, MAXDOP = 4, FILLFACTOR = 90);

2.İndex Reorganize

Reorganize işlemi, indeksin verilerini yeniden düzenler, ancak bunu daha hafif bir şekilde yapar. Bu işlemde indeks sıfırdan oluşturulmaz, sadece mevcut indeks üzerinde küçük düzeltmeler yapılır.

Bu işlem her zaman çevrimiçidir ve iptal ederseniz olduğu yerde durabilir (geri almak için devasa bir işlemi yoktur).

Ne Zaman Yapılır?

• İndeksin daha düşük oranda bozulduğu (genellikle %5 ile %30 arasında fragmentasyon varsa) durumlarda tercih edilir.
• Veritabanı yoğunluğunun düşük olduğu zamanlarda, performansı hızlı bir şekilde artırmak için kullanılır.

• Reorganize işlemi, indeksin içindeki veri bloklarını defragment eder ve boş alanları temizler.
• Tablo kilitlemesi yapmaz, dolayısıyla işlem genellikle çalışan sistemlerde daha az etki yaratır.
• Sadece belli bloklar üzerinde işlem yapıldığı için, genellikle daha hızlıdır ve daha az kaynak kullanır.

Avantajları:

• Daha az disk alanı ve işlem gücü gerektirir.
• Çalışan sistemlerde, çevrimiçi yapılabilir.
• Küçük fragmentasyonlar için etkili çözüm sunar.

Dezavantajları:

• Büyük miktarda fragmentasyon olduğunda verimli olmayabilir.
• İndeksin yapısını tamamen yeniden düzenlemez, sadece mevcut düzeni iyileştirir.

Fragmentation %80 ise ve sadece reorganize yapılırsa genelde bu oran %60-70 bandına düşmektedir. Fragmentation oranı minimize olmaz.

-- Tek bir indeksi reorganize etmek için
ALTER INDEX [index_name] ON [table_name] REORGANIZE WITH ( LOB_COMPACTION = ON );

İlgili tablo altındaki tüm indexleri reorganize etmek için aşağıdaki komut kullanılmaktadır.

ALTER INDEX ALL ON TabloAdı REORGANIZE;

LOB_COMPACTION = ON ne işe yarar?

SQL Server’da ALTER INDEX … REORGANIZE komutu kullanıldığında, eğer tabloda LOB veri tipleri varsa (Large Object Binary), örneğin:
• VARCHAR(MAX)
• NVARCHAR(MAX)
• VARBINARY(MAX)
• TEXT, NTEXT, IMAGE (eski tipler)

Bu veri tipleri veri sayfalarının dışında (out-of-row) saklanır. Bu alanlar zamanla parçalanabilir (fragmented) ve boşluklar oluşabilir.

İşte bu noktada: WITH (LOB_COMPACTION = ON); komutu ile:
• LOB veri alanlarının içindeki gereksiz boşluklar temizlenir,
• Sayfa kullanımı daha verimli hale gelir,
• Fiziksel okuma performansı iyileşebilir.

Kısacası: LOB_COMPACTION = ON, reorganize işlemi sırasında LOB verilerinin de sıkıştırılarak temizlenmesini sağlar. Varsayılan değeri zaten ON’dur

Rebuil ve Reorganize işlemi SSMS arayüzünde yapılabilir. İlgili tablo altında bulunan index yapımıza gelip sağ tıklayıp Reorganize-Rebuild işlemi yapılabilmektedir.

Hangi işlemi yapacaksak ilgili bölüme tıkladıktan sonra Script bölümünden işlemin script’i alınır.

Gelen scriptte ilgili bölümler doldurulabilir. Yeni bir index oluşturuluyormuş gibi fill factor ve diğer ayarlamalar yapılabilir.

USE [AdventureWorks2014]
GO
ALTER INDEX [AK_Person_rowguid] ON [Person].[Person] REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

Tablo altında bulunan tüm indexlerin rebuild ve reorganize edilmesi isteniyorsa aşağıdaki ekran resmindeki bölümlere tıklanır.

Partition olan tablolarda Reorganize işlemi yapmak isteyebiliriz. Bunun için aşağıdaki komut kullanılmaktadır.

ALTER INDEX [Index_Adı] ON [Schema].[Tablo_Adı] 
REORGANIZE PARTITION = [Partition_Numarası]

                                    Rebuild ve Reorganize Karşılaştırması

Özellik	Rebuild	Reorganize
Fragmentasyon Seviyesi	Yüksek fragmentasyon (> %30)	Düşük – orta fragmentasyon (%5 – %30)
Durum Bilgisi	kesintiye uğrarsa sıfırdan yeniden başlamak gerekir	İşlemin kesintiye uğradığı yerden yeniden başlatılabilir
Performans İyileştirmesi	Tam iyileştirme sağlar	Küçük iyileştirmeler sağlar
Zaman ve Kaynak Kullanımı	Yüksek kaynak tüketir, uzun sürer	Düşük kaynak tüketir, daha hızlı, yalnızca yeniden düzenlenen bloklar için trn log üretir.
Veritabanı Erişilebilirliği	Tablo kilitlenebilir. Hem çevrimiçi hem de çevrimdışı olabilir (ayrıca SQL Server sürümüne de bağlıdır)	Çevrimiçi yapılabilir.
Disk Alanı Kullanımı	Geçici olarak artabilir. Yeni dizin oluşturmak için yeterli boş alana ihtiyaç var.	Az artış, verimli kullanılır. yerinde çalışır, bu nedenle ekstra alana gerek yoktur.
İndeks Yapısı	Tamamen yeniden oluşturulur. İstatistikler otomatik güncellenir.	Sadece yeniden düzenlenir. İstatistik güncellemesi manuel olarak yapılmaktadır.

Indexlerinizde Fragmentation düzeyini belirledikten sonra Fragmentation’ı ele almak için kullanabileceğiniz iki farklı seçeneğiniz olur. Index ya yeniden  düzenleyebilirsiniz ya da yeniden  oluşturabilirsiniz. Microsoft’un yönergeleri, Fragmentation< %10 ise hiçbir şey yapmamanızı, %10 ile %30 arasındaysa yeniden düzenlemenizi ve > %30 ise yeniden  oluşturmanızı önermektedir.

Kısacası;

• Rebuild işlemi, yüksek düzeyde fragmentasyon yaşanıyorsa ve veritabanı üzerinde ciddi performans düşüşü varsa tercih edilmelidir.
• Reorganize işlemi, daha düşük seviyelerdeki fragmentasyonu gidermek ve işlem süresini kısa tutmak için daha uygundur. Ayrıca, veritabanı çevrimiçi iken yapılabilir.

1-Aşağıdaki sorgu yardımıyla veritabanı altında bulunan tablolardaki tüm index’lerimizin bozulma oranlarını bulmuş olacağız. Aynı zamanda indexslerin türünüde görmüş olacağız. exec sp_MSforeachdb procedured yapısını kullanarak tüm instance altında veritabanları için yapılabilir.

use [AdventureWorks2016]
SELECT S.name as 'Schema',
T.name as 'Table',
indexstats.avg_fragmentation_in_percent,
ind.type_desc,
ind.name as Index_Nmae,
indexstats.page_count 
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) indexstats 
INNER JOIN sys.indexes ind ON ind.object_id = indexstats.object_id AND ind.index_id = indexstats.index_id 
INNER JOIN sysobjects so ON so.id=ind.object_id
INNER JOIN sysusers su on su.uid=so.uid 
INNER JOIN sys.tables T on T.object_id = indexstats.object_id
INNER JOIN sys.schemas S on T.schema_id = S.schema_id

WHERE indexstats.avg_fragmentation_in_percent > 5
  AND ind.name is not null --HEAP'lerde index olmuyor!...
ORDER BY indexstats.avg_fragmentation_in_percent DESC

Tüm veritabanların da kontrol işlemi yapmak için yukarıdaki kod bloğunda aşağıdaki gibi değişikliklerin yapılması gerekmektedir.

exec sp_MSforeachdb' 
SELECT ''?'' as databasename,S.name as ''Schema'',
T.name as ''Table'',.........'

2- Sadece non-clustered indekslerle sınırlamak isterseniz, IX.type_desc = 'NONCLUSTERED' filtresini ekleyebilirsiniz.

use [AdventureWorks2016]
SELECT S.name as 'Schema',
T.name as 'Table',
indexstats.avg_fragmentation_in_percent,
ind.type_desc,
ind.name as Index_Nmae,
indexstats.page_count 
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) indexstats 
INNER JOIN sys.indexes ind ON ind.object_id = indexstats.object_id AND ind.index_id = indexstats.index_id 
INNER JOIN sysobjects so ON so.id=ind.object_id
INNER JOIN sysusers su on su.uid=so.uid 
INNER JOIN sys.tables T on T.object_id = indexstats.object_id
INNER JOIN sys.schemas S on T.schema_id = S.schema_id

WHERE indexstats.avg_fragmentation_in_percent > 5
AND
ind.type_desc='NONCLUSTERED'
  AND ind.name is not null --HEAP'lerde index olmuyor!...
ORDER BY indexstats.avg_fragmentation_in_percent DESC

3.  Aşağıdaki komut yukarıda paylaşılmış olduğum tüm komutları kapsamaktadır. Bize ilgili indexslerin rebuild komutlarını vermektedir.

use [AdventureWorks2016]
SELECT S.name as 'Schema',
T.name as 'Table',
indexstats.avg_fragmentation_in_percent,
ind.type_desc,
ind.name as Index_Nmae,
indexstats.page_count,
'ALTER INDEX '+ind.name+ ' ON ['+ OBJECT_SCHEMA_NAME(ind.object_id)+'].'+ OBJECT_NAME(ind.object_id) 
+'REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, ONLINE = ON, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90)' as Rebuild_Komut
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) indexstats 
INNER JOIN sys.indexes ind ON ind.object_id = indexstats.object_id AND ind.index_id = indexstats.index_id 
INNER JOIN sysobjects so ON so.id=ind.object_id
INNER JOIN sysusers su on su.uid=so.uid 
INNER JOIN sys.tables T on T.object_id = indexstats.object_id
INNER JOIN sys.schemas S on T.schema_id = S.schema_id
WHERE indexstats.avg_fragmentation_in_percent > 5
AND ind.name is not null --HEAP'lerde index olmuyor!...
ORDER BY indexstats.avg_fragmentation_in_percent DESC

REBUILD PARTITION = ALL ifadesi, tüm bölümlerin yeniden oluşturulmasını sağlar. Yani, index’in veya tablonun tüm bölümleri yeniden yapılandırılır ve optimize edilir. Bu, genellikle büyük ve partitioned tablolarla çalışan veritabanlarında, her bölümdeki fragmantasyonu gidermek ve performansı artırmak için kullanılır.

Yukarıda görülen fragmentation kısmındaki değerler göre tablo altında bulunan index yapımıza müdahale edebiliriz.

Rebuild ve Reorganize çevrimiçi veya çevrimdışı olabilir (veritabanı sürümüne bağlı olarak) Dikkat edilmesi gereken hususlar:

• Reorganize her zaman çevrimiçi bir işlemdir, SQL Server’ın hangi sürümünü kullanıyor olursanız olun. Herhangi bir kilit gerektirmez, bu nedenle daha iyi eşzamanlılık sağlayabilir.  Reorganize yalnızca indexsin leaf seviyesini iyileştirir. Büyük tablolarda rebuild’dan daha uzun sürebilir. Ancak yukarıda da söylediğim gibi, bir süreliğine yeniden düzenleyebilmeniz ve ardından büyük bir geri alma işlemiyle karşılaşmadan durabilmeniz güzeldir.

Enterprise Edition kullanıyorsanız , Paralellik kullanarak  rebuild oluşturmayı benimsenmeli ve bakım pencereniz sırasında kişilerin veritabanına erişmesi gerekirse, buna izin veren dizinler için ONLINE seçeneğini kullanılması gerekmektedir.

Database Mirroring veya AlwaysOn Kullanılabilirlik Gruplarınız varsa , özellikle rebuild işlemlerinde dikkatli olunması gerekmektedir. Dizin bakımıyla birden fazla G/Ç üretmek kolaydır ve bu, secondary veya mirror database o kadar geride bırakmak anlamına gelebilir ki yetişemezler ve kopmaya sebebiyet vereceklerdir.

Genel olarak reorganize işlemi ne yapar. REORGANIZE komutu, SQL Server’da indeks bakımı yaparken şu işlemleri sırayla gerçekleştirir: Sayfaların fiziksel disk konumları aynı kalır. Sadece sayfaların iç düzeni değişir Örnek: Bir sayfada dağınık haldeki 100 kayıt, yeniden düzenlenerek sıkıştırılır. Her bir sayfanın içindeki boş alanları değerlendirir. Kayıtları sayfa içinde optimize şekilde yeniden düzenler. Örnek: %60 dolu sayfayı %95 doluluğa çıkarır. Aynı extent’teki yarı dolu sayfaları birleştirir. 2 adet %50 dolu sayfayı 1 adet %100 dolu sayfa yapar. Boşalan sayfayı boş sayfa havuzuna ekler. Tamamen boşalmış sayfaları bellekten kaldırır. Bu sayfaları SQL Server’ın boş sayfa havuzuna iade eder. sysindexes sistem tablosundaki bilgileri günceller. Sayfa bağlantılarını (page linkage) yeniden yapılandırır. Orijinal fill factor ayarını yeniden uygulamaz. %80 fill factor ile oluşturulmuş indekste boşlukları geri getirmez.

Örnek Tablo:

-- REORGANIZE öncesi durum
Page 1234: [Rec1][Rec2][Empty][Rec4][Empty][Empty][Rec7]...
Page 1235: [Empty][Rec9][Empty][Rec11][Empty]...

-- REORGANIZE sonrası durum
Page 1234: [Rec1][Rec2][Rec4][Rec7][Rec9][Rec11]...
Page 1235: (Boş - artık kullanılmıyor)

Bu makalede index reorganize ve rebuild işlemlerini detaylı bir şekilde görmüş olduk.

Başka bir makalede görüşmek dileğiyle..

Onlar, siz birbirinizi namaza çağırdığınızda onu alay ve oyun (konusu) edinirler. Bu, gerçekten onların akıl erdirmeyen bir topluluk olmalarındandır. Maide Suresi, 58. Ayet