DBCC KÜÇÜLTME VERITABANI (Transact-SQL)

Şunlar için geçerlidir:SQL ServerAzure SQL VeritabanıAzure SQL Yönetilen ÖrneğiMicrosoft Fabric'de Azure Synapse AnalyticsSQL veritabanı

Belirtilen veritabanındaki verilerin ve günlük dosyalarının boyutunu küçültür.

Küçültme operasyonlarını düzenli bir bakım operasyonu olarak görmeyin. Düzenli ve yinelenen iş işlemleri nedeniyle büyüyen veri ve günlük dosyaları için küçültme işlemleri gerekmez.

Transact-SQL söz dizimi kuralları

Sözdizimi

SQL Server söz dizimi:

DBCC SHRINKDATABASE
( database_name | database_id | 0
     [ , target_percent ]
     [ , { NOTRUNCATE | TRUNCATEONLY } ]
)
[ WITH
    {
         [ WAIT_AT_LOW_PRIORITY
            [ (
                  <wait_at_low_priority_option_list>
             ) ]
         ]
         [ , NO_INFOMSGS ]
    }
]

<wait_at_low_priority_option_list> ::=
    <wait_at_low_priority_option>
    | <wait_at_low_priority_option_list>
      , <wait_at_low_priority_option>

<wait_at_low_priority_option> ::=
  ABORT_AFTER_WAIT = { SELF | BLOCKERS }

Azure Synapse Analytics söz dizimi:

DBCC SHRINKDATABASE
( database_name
     [ , target_percent ]
)
[ WITH NO_INFOMSGS ]

Argümanlar

{ database_name | database_id | 0 }

Küçültülecek veritabanının adı veya kimliği. 0 değeri mevcut veritabanını belirtir.

target_percent

Küçültme işlemi tamamlandıktan sonra veritabanı dosyasında bırakılacak boş alan yüzdesi.

Eğer ileTRUNCATEONLYtarget_percent belirtirseniz, küçültme işlemi dosyanın sonunda boş alan açmayabilir.

NOT ÇALIŞMASI

Atanan sayfaları dosyanın sonundan, dosyanın önündeki atanmamış sayfalara taşır. Bu eylem, dosya içindeki verileri sıkıştırıyor. target_percent isteğe bağlıdır. Azure Synapse Analytics bu seçeneği desteklemez.

Dosyanın sonundaki boş alan işletim sistemine döndürülmüyor ve dosyanın fiziksel boyutu değişmez. Bu nedenle, NOTRUNCATEbelirttiğinizde veritabanı küçülmeyecek gibi görünür.

NOTRUNCATE yalnızca veri dosyaları için geçerlidir. NOTRUNCATE günlük dosyasını etkilemez.

SADECE KESİNTİ

Dosyanın sonundaki tüm boş alanı işletim sistemine bırakır. Dosyanın içindeki sayfaları taşımaz. Veri dosyası yalnızca son atanan uzantıya küçültür. Azure Synapse Analytics bu seçeneği desteklemez.

Eğer ileTRUNCATEONLYtarget_percent belirtirseniz, küçültme işlemi dosyanın sonunda boş alan açmayabilir.

BİLGİ_MSJSIZ

Önem düzeyi 0 ile 10 arasında olan tüm bilgilendirme iletilerini gizler.

Küçültme işlemleriyle WAIT_AT_LOW_PRIORITY

Şunlara uygulanır: SQL Server 2022 (16.x) ve sonraki sürümler, Azure SQL Veritabanı, Azure SQL Yönetilen Örneği, SQL database in Microsoft Fabric

Düşük öncelikli bekleme özelliği, küçültme işlemi sırasında kilit çatışmasını azaltır. Daha fazla bilgi için bkz. DBCC SHRINKDATABASE ile ilgili eşzamanlılık sorunlarını anlama.

Bu özellik, bazı farklılıklarla birlikte, online dizin işlemleriile WAIT_AT_LOW_PRIORITY'ye benzer.

• Seçeneği NONEbelirtemezsinizABORT_AFTER_WAIT.
• Seçeneği MAX_DURATION ayarlayamazsınız. Bir küçültme işlemi için düşük öncelikli kilit süresi her zaman bir dakikadır.

DÜŞÜK_ONCELIKTE_BEKLE

Bir küçültme komutu modda WAIT_AT_LOW_PRIORITY çalıştırıldığında, Index Allocation Map (IAM) sayfalarında şema kararlılığı (Sch-S) kilitleri gerektiren sorgular küçültme işlemi tarafından engellenmez. Ancak, küçültme işlemi bir IAM sayfasında bir Sch-S kilitle engellenebilir. Shrink, yalnızca ihtiyaç duyduğu bir IAM sayfasında şema değiştiren kilidi (Sch-M) kilidi elde edebildiğinde çalışmaya devam eder.

Eğer moddaki WAIT_AT_LOW_PRIORITY bir küçültme işlemi, uzun süreli bir sorgu kilidi Sch-S tuttuğu için bu kilidi elde edemiyorsa, küçültme işlemi 49516 hatasıyla zaman doluyor, örneğin: Msg 49516, Level 16, State 1, Line 134 Shrink timeout waiting to acquire schema modify lock in WLP mode to process IAM pageID 1:2865 on database ID 5.

{ ABORT_AFTER_WAIT = [ BENLIK | BLOKERLAR ] }

• SELF

  SELF varsayılan seçenektir. Şu anda yürütülen küçültme veritabanı işleminden başka bir işlem yapmadan çıkın.

• BLOCKERS

  İşlemin devam edebilmesi için dosya küçültme işlemini engelleyen tüm kullanıcı işlemlerini sonlandırma. Bu BLOCKERS seçenek, giriş işleminin veya KILL DATABASE CONNECTION iznine ALTER ANY CONNECTION sahip olmasını gerektirir.

Sonuç kümesi

Aşağıdaki tabloda sonuç kümesindeki sütunlar açıklanmaktadır.

Sütun adı	Açıklama
DbId	Veritabanı Altyapısı'nın küçültmeye çalıştığı dosyanın veritabanı kimlik numarası.
FileId	Veritabanı Altyapısı'nın küçültmeye çalıştığı dosyanın dosya tanımlama numarası.
CurrentSize	Dosyanın şu anda kapsamakta olduğu 8 KB sayfa sayısı.
MinimumSize	Dosyanın kaplaması muhtemel, en az 8 KB'lık sayfa sayısı. Bu değer, bir dosyanın en küçük boyutuna veya başlangıçta oluşturulan boyutuna karşılık gelir.
UsedPages	Şu anda dosya tarafından kullanılmakta olan 8 KB'lık sayfa sayısı.
EstimatedPages	Veritabanı Motorunun dosyanın küçültülebileceğini tahmin ettiği 8 KB'lık sayfa sayısı.

Not

Database Engine, küçültülmemiş dosyalar için satır göstermiyor.

Açıklamalar

Belirli bir veritabanına ilişkin tüm verileri ve günlük dosyalarını küçültmek için DBCC SHRINKDATABASE komutunu yürütür. Belirli bir veritabanı için bir kerede bir veri veya günlük dosyasını küçültmek için DBCC SHRINKFILE komutunu yürütebilirsiniz.

Veritabanındaki geçerli boş (ayrılmamış) alanı görüntülemek için sp_spaceused çalıştırın.

DBCC SHRINKDATABASE işlemler işlemin herhangi bir noktasında durdurulabilir ve tamamlanan tüm işler tutulur.

Veritabanı, veritabanının yapılandırılan minimum boyutundan küçük olamaz. Veritabanı ilk oluşturulduğunda minimum boyutu belirtirsiniz. Alternatif olarak, dosya boyutu değiştirme işlemi kullanılarak minimum boyut açıkça ayarlanan son boyut da olabilir. DBCC SHRINKFILE veya ALTER DATABASE gibi işlemler, dosya boyutu değiştirme işlemlerine örnek olarak verilebilir.

Veritabanının başlangıçta 10 MB boyutunda oluşturulduğunu düşünün. Daha sonra 100 MB'a kadar büyür. Veritabanındaki tüm veriler silinmiş olsa bile veritabanının en küçük boyutu 10 MB'a düşürülebilir.

NOTRUNCATE Seçeneği veya TRUNCATEONLY seçeneği çalıştırdığınızda DBCC SHRINKDATABASEbelirtebilirsiniz. Eğer herhangi bir seçeneği belirtmezseniz, sonuç DBCC SHRINKDATABASE bir işlemi çalıştırıp NOTRUNCATEDBCC SHRINKDATABASE ardından ile bir TRUNCATEONLYişlem çalıştırmanız gibi olur.

Küçülen veritabanının tek kullanıcı modunda olması gerekmez. Veritabanı küçültülürken, sistem veritabanları da dahil olmak üzere, diğer kullanıcılar veritabanında çalışıyor olabilir.

Veritabanı yedeklenirken veritabanını küçültemezsiniz. Buna karşılık, veritabanındaki bir küçültme işlemi devam ederken veritabanını yedekleyemezsiniz.

Azure Synapse SQL havuzlarında, küçültme komutu çalıştırmaktan kaçının çünkü bu, özel SQL havuzunuzu (eski adıyla SQL DW) çevrimdışı hale getirebilen I/O yoğun bir işlemdir. Bu komut ayrıca veri deposu anlık görüntülerinizin maliyetini de etkiler.

Bilinen sorunlar

Apply to: SQL Server, Azure SQL Veritabanı, Azure SQL Yönetilen Örneği, Azure Synapse Analytics dedicated SQL pool

• SQL Server 2022 (16.x) ve önceki sürümlerde, sıkıştırılmış columnstore segmentlerinde LOB sütun tipleri (varbinary(max), varchar(max) ve nvarchar(max)) tarafından kullanılan sayfalar ve DBCC SHRINKFILEtarafından taşınamazDBCC SHRINKDATABASE. Daha fazla bilgi için bkz . Columnstore dizinlerindeki yenilikler.

DBCC SHRINKDATABASE nasıl çalışır?

DBCC SHRINKDATABASE, veri dosyalarını dosya başına daraltır, ancak tüm günlük dosyaları bir bitişik günlük havuzunda varmış gibi küçültür. Dosyalar her zaman sonundan küçültülr.

Varsayalım ki iki günlük dosyanız ve bir veri dosyanız var, adı mydb. Veri ve günlük dosyalarının her biri 10 MB, veri dosyası ise 6 MB veri içerir. Veritabanı Altyapısı her dosya için bir hedef boyutu hesaplar. Bu değer, küçültüldükten sonra dosyanın hedef boyutudur. target_percent ile belirttiğinizdeDBCC SHRINKDATABASE, Database Engine hedef boyutunu, küçültüldükten sonra dosyada boş target_percent alan olarak hesaplar.

Örneğin, daraltmak için 25 mydb belirtirseniz, Veritabanı Altyapısı veri dosyasının hedef boyutunu 8 MB (6 MB veri artı 2 MB boş alan) olarak hesaplar. Bu nedenle, Veritabanı Altyapısı veri dosyasının son 2 MB'ından verileri, veri dosyasının ilk 8 MB'lık içindeki herhangi bir boş alana taşır ve ardından dosyayı küçültür.

mydb veri dosyasının 7 MB veri içerdiğini varsayalım. 30 target_percent belirtilmesi, bu veri dosyasının boş yüzde 30'a küçültülmesini sağlar. Ancak, veri dosyasının geçerli toplam boyutunda yeterli boş alan oluşturulamadığından, 40 target_percent belirtilmesi veri dosyasını küçültmez.

Bu sorunu başka bir şekilde düşünebilirsiniz: yüzde 40 boş alan + yüzde 70 tam veri dosyası (10 MB'ın 7 MB'si) yüzde 100'den fazladır. 30'dan büyük target_percent veri dosyasını küçültmez. İstediğiniz boş alan yüzdesi ile veri dosyasının kapladığı mevcut yüzdelik oranının toplamı 100'ü aştığından küçülmeyecek.

Günlük dosyaları için Veritabanı Altyapısı, tüm günlüğün hedef boyutunu hesaplamak için target_percent kullanır. Bu nedenle target_percent, küçültme işleminden sonra günlükteki boş alan miktarıdır. Tüm günlüğün hedef boyutu daha sonra her bir günlük dosyasının hedef boyutuna dönüştürülür.

DBCC SHRINKDATABASE her fiziksel günlük dosyasını hedef boyutuna hemen küçültmeye çalışır. Mantıksal günlüğün hiçbir parçası hedef kayıt boyutunun ötesinde sanal loglarda kalmazsa, DBCC SHRINKDATABASE dosya başarıyla kesilir ve mesaj olmadan tamamlanır. Ancak, mantıksal günlüğün bir bölümü sanal günlüklerde hedef boyutun ötesinde kalırsa, Veritabanı Altyapısı mümkün olduğunca fazla alan boşaltıp bilgilendiren bir ileti gönderir. Mesaj, dosyanın sonunda sanal loglardan mantıksal logu taşımak için yapılan işlemleri tanımlar. Eylemler tamamlandıktan sonra, kalan alanı boşaltmak için kullanın DBCC SHRINKDATABASE .

Bir günlük dosyasını sadece sanal bir log dosyası sınırına küçültebilirsiniz. Bu yüzden bir günlük dosyasını sanal bir log dosyasından daha küçük bir boyuta küçültmek mümkün değil. Database Engine, log dosyaları oluştururken veya genişletirken sanal log dosyasının boyutunu dinamik olarak seçer.

DBCC SHRINKDATABASE ile ilgili eşzamanlılık sorunlarını anlama

Veritabanını küçültme ve dosyayı küçültme komutları, özellikle aktif bakım (örneğin indekslerin yeniden oluşturulması) veya yoğun OLTP ortamlarında eşzamanlılık sorunlarına yol açabilir.

Örneğin, bir kullanıcı sorgusu bir Indeks Tahsis Haritası (IAM) sayfasında bir şema kararlılığı (Sch-S) kilidi edinebilir ve tamamlanana kadar tutabilir. Düzenli kullanım sırasında alanı geri kazanmaya çalışırken, veritabanını küçültme ve dosya küçültme işlemleri, IAM sayfalarını taşınırken veya silerken şema değişikliği (Sch-M) kilidi gerektirir ve kullanıcı sorgularının ihtiyaç duyduğu kilitleri Sch-S engeller. Sonuç olarak, uzun süreli sorgular bir küçültme işlemini engelleyebilir. Bu davranış, IAM sayfasında kilitlenme gerektiren Sch-S herhangi yeni sorgunun, küçültme işleminin arkasında kuyruk durabileceği ve bu eşzamanlılık sorununu daha da kötüleştirebileceği anlamına gelir.

SQL Server 2022 (16.x) ile tanıtılan küçültme işlemleri için düşük öncelikli bekleme özelliği, moddaki WAIT_AT_LOW_PRIORITY IAM sayfalarında şema değiştirme kilidini alarak bu sorunu çözer. Daha fazla bilgi için bkz. WAIT_AT_LOW_PRIORITY küçültme işlemleriyle.

Kilitler ve kilitler hakkında daha fazla bilgi Sch-S için İşlem kilitleme ve satır sürümleme rehberine bakınız.Sch-M

En iyi yöntemler

Veritabanını küçültmeyi planlarken aşağıdaki bilgileri göz önünde bulundurun:

• Küçültme işlemi, en çok kullanılmayan alan oluşturan bir işlemden (örneğin, kesme tablosu veya bırakma tablosu işlemi) sonra etkili olur.

• Çoğu veritabanı, düzenli günlük işlemler için biraz boş alan gerektirir. Bir veritabanı dosyasını tekrar tekrar küçültürseniz ve veritabanı boyutunun tekrar arttığını fark ederseniz, bu büyüme normal işlemlerin boş alan gerektirdiğini gösterir. Bu durumlarda, veritabanı dosyasını tekrar tekrar küçültmek ters etki sağlar. Küçültme sonrası yeni alan tahsis etmek için gereken dosya büyümesi performansı engelleyebilir.

• Bir küçültme işlemi, veritabanındaki indekslerin parçalanma durumunu korumaz ve indeks parçalanmasını artırabilir; bu da büyük taramalar yapılan sorgularda okuma G/Ç akışını azaltabilir.

• Belirli bir gereksiniminiz yoksa AUTO_SHRINK veritabanı seçeneğini ON olarak ayarlamayın.

• Büyük bir veritabanının veri dosyalarını küçültmeniz gerekiyorsa, ShrinkDriver PowerShell betikini kullanmayı düşünün. Script, küçültme sürecini otomatikleştirir ve basitleştirir, bunu tek, gözlemlenebilir ve devam ettirilebilir bir operasyona dönüştürür. Script, birden fazla dosyayı paralel olarak küçültür, kesildiğinde tekrar dener ve çalışırken ayrıntılı durum raporları verir.

Sorun gidermek

satır sürüm tabanlı bir yalıtım düzeyi altında çalışan bir işlem, küçültme operasyonlarını engelleyebilir. Örneğin, satır sürüm tabanlı izolasyon seviyesi altında büyük bir silme işlemi devam ederken çalıştırırsınız DBCC SHRINKDATABASE . Bu durumda, küçültme işlemi dosyaları küçültmeden önce silme işleminin tamamlanmasını bekler. Küçültme işlemi beklediğinde, DBCC SHRINKFILE ve DBCC SHRINKDATABASE işlemleri bir bilgilendirme iletisi yazdırır (SHRINKDATABASE için 5202 ve SHRINKFILEiçin 5203). Bu mesaj, ilk saatte ve sonrasında her beş dakikada bir SQL Server hata günlüğüne yazılır. Örneğin, hata günlüğü aşağıdaki hata iletisini içeriyorsa:

DBCC SHRINKDATABASE for database ID 9 is waiting for the snapshot
transaction with timestamp 15 and other snapshot transactions linked to
timestamp 15 or with timestamps older than 109 to finish.

Bu hata, 109'dan eski zaman damgalı anlık işlemlerin küçültme işlemini engellediği anlamına gelir. Bu işlem, küçültme işleminin tamamlandığı son işlemdir. Ayrıca sys.dm_tran_active_snapshot_database_transactions dinamik yönetim görünümündeki or first_snapshot_sequence_num sütunlarının 15 değeri olduğunu da belirtirtransaction_sequence_num. Görünümdeki transaction_sequence_num veya first_snapshot_sequence_num sütunu, küçültme işlemi (109) tarafından tamamlanan son işlemden küçük bir sayı içerebilir. Bu durumda, küçültme işlemi bu işlemlerin tamamlanmasını bekler.

Sorunu çözmek için aşağıdakilerden birini yapabilirsiniz:

• Küçültme işlemini engelleyen işlemi sonlandırın.
• Küçültme işlemini sonlandırın. Tamamlanan tüm çalışmalar korunur.
• Hiçbir şey yapma ve engelleme işlemi tamamlanana kadar küçültme işleminin beklemesine izin verin.

İzinler

Sysadmin sabit sunucu rolüne veya db_owner sabit veritabanı rolüne üyelik gerektirir.

Örnekler

Bu makaledeki kod örneklerinde AdventureWorks2025 veya AdventureWorksDW2025 örnek veritabanı kullanılır; bunları Microsoft SQL Server Samples and Community Projects ana sayfasından indirebilirsiniz.

A. Veritabanını küçültme ve boş alan yüzdesi belirtme

Aşağıdaki örnek, UserDB kullanıcı veritabanındaki verilerin ve günlük dosyalarının boyutunu azaltarak veritabanında yüzde 10 boş alan sağlar.

DBCC SHRINKDATABASE (UserDB, 10);
GO

B. Veritabanını boşalt

Aşağıdaki örnek, AdventureWorks2025 örnek veritabanındaki veri ve günlük dosyalarını son atanan uzaya kadar küçültür.

DBCC SHRINKDATABASE (AdventureWorks2025, TRUNCATEONLY);

C. Azure Synapse Analytics veritabanını küçültme

DBCC SHRINKDATABASE (database_A);
DBCC SHRINKDATABASE (database_B, 10);

D. Bir veritabanını küçültmek WAIT_AT_LOW_PRIORITY

Aşağıdaki örnek, veritabanında 20% boş alan sağlamak için AdventureWorks2025 veritabanındaki veri ve günlük dosyalarının boyutunu küçültmeye çalışır. Bir dakika içinde kilit alınamazsa küçültme işlemi durdurulür.

DBCC SHRINKDATABASE ([AdventureWorks2025], 20) WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = SELF);

İlgili içerik

• Veritabanını küçültme
• Dosyayı küçültme
• DBCC KÜÇÜLTME DOSYASI (Transact-SQL)
• SQL Server'da otomatik büyütme ve otomatikshrink ayarlarıyla ilgili dikkat edilmesi gerekenler
• Veritabanı dosyaları ve dosya grupları
• sys.databases (Transact-SQL)
• sys.database_files (Transact-SQL)
• ALTER DATABASE (Transact-SQL)
• Azure SQL Veritabanı'ndaki veritabanları için dosya alanını yönetme