Azure SQL Veritabanı'ndaki veritabanları için dosya alanını yönetme

Şunlar için geçerlidir:Azure SQL Veritabanı

• Azure SQL Veritabanı
• Azure SQL Yönetilen Örnek

Bu makalede, Azure SQL Veritabanı'ndaki veritabanları için farklı depolama alanı türleri açıklanmaktadır. Bazen tahsis edilen dosya alanını açıkça yönetmeniz gerekebilir. Bu makale, bunu yapmanın adımlarını içerir.

Genel bakış

Bazı iş yükü kalıpları, veri dosyalarına ayrılan alanın kullanılan alandan daha büyük olmasına neden olabilir. Bu durum, kullanılan alan veri büyümesi nedeniyle arttığında ortaya çıkar, ancak daha sonra veri silinir veya sıkıştırılır. Tahsis edilen ama kullanılmayan alan otomatik olarak geri alınmaz çünkü geri kazanma kaynak yoğun ve gelecekteki dosya büyümesini yavaşlatacaktır.

Aşağıdaki senaryolarda veri dosyalarını küçültmeniz ve kullanılmayan alanı geri kazanmanız gerekebilir:

• Havuzdaki bazı veritabanlarına ayrılan geniş bir alan, havuzun en büyük boyutuna yaklaşmasına neden olduğunda, elastik havuzdaki veritabanlarında verilerin büyümesini sağlamak için.
• Tek bir veritabanı veya elastik havuzun maksimum boyutunun azaltılmasını sağlamak için.
• Veritabanını veya elastik havuzu daha düşük maksimum boyut sınırına sahip bir katmana dönüştürmek.
• Hyperscale servis katmanını kullanırken depolama maliyetlerini azaltmak için.

Dikkat

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.

Dosya alanı kullanımını izleme

Azure Resource Manager (ARM) API'leri, PowerShell get-metrics'i dahil, veritabanları ve elastik havuzlar için kullanılan ve tahsis edilmiş alanı geri getirir.

Aşağıdaki sistem görünümleri ayrıca veritabanları ve elastik havuzlar için kullanılan ve tahsis edilmiş alan boyutunu da geri getirir:

• sys.resource_stats
• sys.elastic_pool_resource_stats
• sys.dm_elastic_pool_resource_stats

Veritabanı için depolama alanı türlerini anlama

Aşağıdaki depolama alanı miktarlarını anlamak, veritabanının dosya alanını yönetmek için önemlidir.

Veritabanı miktarı	Tanım	Yorumlar
Kullanılan veri alanı	Veri depolamak için kullanılan alan miktarı.	Genel olarak, kullanılan alan eklemelerde (silmelerde) artar (azalır). Bazı durumlarda, işlemdeki verilerin miktarına ve düzenine ve herhangi bir parçalanmaya bağlı olarak eklemelerde veya silmelerde kullanılan alan değişmez. Örneğin, her veri sayfasından bir satır silmek, kullanılan alanı azaltmaz.
Ayrılan veri alanı	Veri dosyalarının aldığı depolama alanı.	Tahsis edilen alan miktarı otomatik olarak artar, ancak sildikten sonra otomatik olarak azalmaz. Bu davranış, gelecekteki eklemelerin daha hızlı olmasını sağlar çünkü alan yeniden tahsis edilmesine gerek kalmaz.
Ayrılan ancak kullanılmayan veri alanı	Ayrılan veri alanı miktarıyla kullanılan veri alanı arasındaki fark.	Bu miktar, veritabanı veri dosyalarının küçültülmesiyle geri kazanılabilecek maksimum boş alan miktarını temsil eder.
En büyük veri boyutu	Veri depolamak için kullanılabilecek maksimum alan miktarı.	Ayrılan veri alanı miktarı, maksimum veri boyutunun ötesine geçemez.

Aşağıdaki diyagramda, veritabanı için farklı depolama alanı türleri arasındaki ilişki gösterilmektedir.

Dosya alanı bilgileri için tek bir veritabanını sorgulama

Ayrılan veritabanı dosya alanı miktarını ve ayrılan kullanılmayan alan miktarını döndürmek için sys.database_files aşağıdaki sorguyu kullanın.

-- Connect to a user database
SELECT file_id,
       type_desc,
       CAST (FILEPROPERTY(name, 'SpaceUsed') AS DECIMAL (19, 4)) * 8 / 1024. AS space_used_mb,
       CAST (size / 128.0 - CAST (FILEPROPERTY(name, 'SpaceUsed') AS INT) / 128.0 AS DECIMAL (19, 4)) AS space_unused_mb,
       CAST (size AS DECIMAL (19, 4)) * 8 / 1024. AS space_allocated_mb,
       CAST (max_size AS DECIMAL (19, 4)) * 8 / 1024. AS max_size_mb
FROM sys.database_files;

Elastik havuz için depolama alanı türlerini anlama

Aşağıdaki depolama alanı büyüklüklerini anlamak, elastik bir havuzun dosya alanını yönetmek için önemlidir.

Elastik havuz miktarı	Tanım	Yorumlar
Kullanılan veri alanı	Elastik havuzdaki tüm veritabanları tarafından kullanılan veri alanının toplamı.
Ayrılan veri alanı	Elastik havuzdaki tüm veri tabanlarındaki veri dosyalarının aldığı depolama alanının toplamı.
Ayrılan ancak kullanılmayan veri alanı	Ayrılan veri alanı miktarıyla elastik havuzdaki tüm veritabanları tarafından kullanılan veri alanı arasındaki fark.	Bu miktar, elastik havuz için veritabanı veri dosyalarının küçültülmesiyle geri kazanılabilecek maksimum ayrılan alan miktarını temsil eder.
En büyük veri boyutu	Elastik havuzun tüm veritabanları için kullandığı maksimum veri alanı miktarı.	Elastik havuz için ayrılan alan, elastik havuzun maksimum boyutunu aşmamalıdır. Bu koşul gerçekleşirse, tahsis edilen ancak kullanılmayan veri dosyaları küçültülerek geri alınabilir.

"Elastik havuz depolama sınırına ulaştı" hata mesajı, veritabanı nesnelerinin elastik havuzun maksimum depolama boyutu sınırını karşılamak için yeterli alan kullandığını gösterir. Depolama sınırını artırmayı veya Kullanılmayan ayrılmış alanı geri kazanma bölümünde açıklandığı şekilde veri alanında yer açmayı düşünün.

Depolama alanı hakkında bilgi için elastik havuzu sorgulayın

Esneklik havuzu için depolama alanı büyüklüklerini belirlemek için aşağıdaki soruları kullanın.

Kullanılan elastik havuz veri alanı

Kullanılan elastik havuz veri alanını döndürmek için aşağıdaki örnek sorguyu kullanın. Elastik havuz adı parametresini havuzunuzun adıyla uyumlu olacak şekilde değiştirin.

-- Connect to master
SELECT TOP (1) avg_storage_percent / 100.0 * elastic_pool_storage_limit_mb AS elastic_pool_space_used_mb,
               avg_allocated_storage_percent / 100.0 * elastic_pool_storage_limit_mb AS elastic_pool_space_allocated_mb,
               elastic_pool_storage_limit_mb AS elastic_pool_maximum_size_mb
FROM sys.elastic_pool_resource_stats
WHERE elastic_pool_name = 'ep1'
ORDER BY end_time DESC;

Kullanılmayan ayrılan alanı geri kazanma

Önemli

Küçültme işlemleri kaynak tüketir ve çalışırken veritabanı performansını etkileyebilir. Mümkünse, küçültme işlemini kullanımın düşük olduğu dönemlerde çalıştırın.

Veri dosyalarını küçültme

Veri dosyalarının küçültülmesi veritabanı performansını etkileyebildiği için, Azure SQL Veritabanı veri dosyalarını otomatik olarak küçültmez. Gerekirse, veri dosyalarını istediğiniz zamanda küçültebilirsiniz. Shrink işlemini düzenli olarak zamanlanmış bir işlem hâline getirmeyin. Bunun yerine, kullanılan alan tüketiminde büyük bir azalma sonrası kullanmayı düşünün.

İpucu

Normal uygulama iş yükü dosyaların tekrar aynı tahsis boyutuna ulaşmasına neden oluyorsa, hesaplama kaynaklarını ve veri dosyalarını küçültmek için zaman harcamayın.

Dosyaları küçültmek için veya T-SQL komutlarından DBCC SHRINKDATABASEDBCC SHRINKFILE birini kullanın:

• DBCC SHRINKDATABASE tek bir komutla veritabanındaki tüm veri ve log dosyalarını küçültür. komutu bir kerede bir veri dosyasını küçültür ve bu da daha büyük veritabanları için uzun sürebilir. Ayrıca günlük dosyasını küçültür; bu genellikle gereksizdir çünkü Azure SQL Veritabanı günlük dosyalarını gerektiği gibi otomatik olarak küçültür.
• DBCC SHRINKFILE komutu daha gelişmiş senaryoları destekler:
  • Veritabanındaki tüm dosyaları küçültmek yerine gerektiğinde tek tek dosyaları hedefleyebilir.
  • Her DBCC SHRINKFILE komut, diğer DBCC SHRINKFILE komutlarla paralel olarak çalışarak toplam küçülme süresini azaltabilir; bunun pahasına daha yüksek kaynak kullanımı ve kullanıcı sorguları ile eşzamanlı DBCC SHRINKFILE komutların geçici olarak engellenmesi riski daha yüksek olur.
  • Dosyanın kuyruğu veri içermiyorsa, argümanı TRUNCATEONLY belirterek tahsis edilen dosya boyutunu daha hızlı azaltabilirsiniz. TRUNCATEONLY dosya içinde veri taşıması gerektirmez, ancak tahsis edilen boyutu da o kadar azaltmaz.
• Bu küçültme komutları hakkında daha fazla bilgi için bkz . DBCC SHRINKDATABASE ve DBCC SHRINKFILE.

Aşağıdaki örnekleri, master veritabanına değil, hedef kullanıcı veritabanına bağlıyken çalıştırın.

Belirli bir veritabanındaki tüm veri ve günlük dosyalarını küçültmek için DBCC SHRINKDATABASE kullanın.

DBCC SHRINKDATABASE (N'database_name');

Bir veritabanında bir veya daha fazla veri dosyası olabilir ve veri büyüdükçe otomatik olarak oluşturulabilir. Veritabanınızın dosya düzenini, her dosyanın kullanılan ve tahsis edilen boyutunu belirlemek için, aşağıdaki örnek betikle katalog sys.database_files görünümünü sorgulayın:

-- Review file properties, including the file_id and name values to use in shrink commands
SELECT file_id,
       name,
       CAST (FILEPROPERTY(name, 'SpaceUsed') AS BIGINT) * 8 / 1024. AS space_used_mb,
       CAST (size AS BIGINT) * 8 / 1024. AS space_allocated_mb,
       CAST (max_size AS BIGINT) * 8 / 1024. AS max_file_size_mb
FROM sys.database_files
WHERE type_desc IN ('ROWS', 'LOG');

Tek bir dosyayı küçültmek için örneğin şu DBCC SHRINKFILE komutu kullanın:

-- Shrink database data file named 'data_0` by removing all unused at the end of the file, if any.
DBCC SHRINKFILE ('data_0', TRUNCATEONLY);

İşlem günlüğü dosyasını küçültme

Veri dosyalarından farklı Azure SQL Veritabanı, alan dolu hatalarına yol açacak aşırı alan kullanımından kaçınmak için işlem günlüğü dosyasını otomatik olarak küçültür. Çoğu durumda işlem günlüğü dosyasını küçültmeniz gerekmez.

Premium ve İş Kritik hizmet katmanlarında, işlem günlüğü büyürse, maksimum yerel depolama limitine doğru yerel depolama tüketimine önemli ölçüde katkıda bulunabilir. Yerel depolama tüketimi sınıra yakınsa, aşağıdaki örnekte gösterildiği gibi komutla DBCC SHRINKFILE işlem günlüğünü küçültmeyi seçebilirsiniz. Bu, düzenli otomatik küçültme işlemini beklemeden komut tamamlandığı anda yerel depolamayı serbest bırakır.

Aşağıdaki örneği, master veritabanına değil, hedef kullanıcı veritabanına bağlıyken çalıştırın.

-- Shrink the database log file (always file_id 2), by removing all unused space at the end of the file, if any.
DBCC SHRINKFILE (2, TRUNCATEONLY);

Otomatik küçültme

Veri dosyalarını el ile küçültmeye alternatif olarak, veritabanı için otomatik küçültme etkinleştirilebilir. Ancak, otomatik küçültme, dosya alanını geri kazanmada DBCC SHRINKDATABASE ve DBCC SHRINKFILE kadar etkili olmayabilir.

Varsayılan olarak, çoğu veritabanı için önerilen otomatik küçültme devre dışı bırakılır. Otomatik küçültmeyi etkinleştirmek gerekirse, alan yönetimi hedeflerine ulaşıldıktan sonra bu özelliğin sürekli etkin bırakılması yerine devre dışı bırakılması önerilir. Daha fazla bilgi için bkz AUTO_SHRINK ile ilgili önemli noktalar.

Örneğin, bir elastik havuz, kullanılan alanda sürekli olarak önemli ölçüde büyüme ve azalma yaşayan birçok veritabanı içeriyorsa ve bu durum havuzun maksimum boyut sınırına yaklaşmasına neden oluyorsa, otomatik küçültme yararlı olabilir. Bu senaryo yaygın değildir.

Otomatik küçültme veritabanı seçeneği Hiper ölçekli veritabanlarında hiçbir etkisi yoktur.

Otomatik küçültmeyi etkinleştirmek için veritabanınıza (master veritabanına değil) bağlıyken aşağıdaki komutu yürütün.

-- Enable auto-shrink for the current database.
ALTER DATABASE CURRENT
    SET AUTO_SHRINK ON;

Bu komut hakkında daha fazla bilgi için bkz . DATABASE SET seçenekleri.

Küçültme işlemi sonrasında dizin bakımı

Bir küçültme işlemi tamamlandıktan sonra, indeksler parçalanabilir. Modern platformlarda çoğu iş yükünde, indeks parçalanması performansı etkilemeyecektir. Büyük indeks taramaları kullanan iş yüklerinde, parçalanma okuma G/Ç verimliliğini azaltabilir. Küçültme işlemi tamamlandıktan sonra performans düşüşü gerçekleşirse, indeksleri yeniden oluşturmak veya yeniden düzenlemek için endeks bakımını düşünün. İndeks yeniden oluşturma işlemleri veritabanında boş alan gerektirir; bu nedenle ayrılan alanın artmasına yol açarak küçültme işleminin etkisini tersine çevirebilir.

Dizin bakımı hakkında daha fazla bilgi için bkz . Sorgu performansını geliştirmek ve kaynak tüketimini azaltmak için dizin bakımını iyileştirme.

Büyük veritabanlarını küçültme

Bir veritabanında tahsis edilen alan yüzlerce gigabayt veya daha yüksek olduğunda, küçülme uzun sürebilir. Çok terabaytlık veritabanları için küçültme işlemleri saatler, günler veya haftalar sürebilir. Bu bölüm, bu süreci uygulama iş yükleri üzerinde daha verimli ve daha az etkili kılan süreç optimizasyonları ve en iyi uygulamaları açıklar.

İpucu

ShrinkDriver , büyük veritabanları için küçültme sürecini otomatikleştiren ve basitleştiren bir PowerShell betikidir; böylece 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.

Alan kullanımını temel olarak belirleme

Küçültmeye başlamadan önce, aşağıdaki alan kullanım sorgusunu yürüterek her veritabanı dosyasında kullanılan ve ayrılan geçerli alanı yakalayın:

SELECT file_id,
       CAST (FILEPROPERTY(name, 'SpaceUsed') AS BIGINT) * 8 / 1024. AS space_used_mb,
       CAST (size AS BIGINT) * 8 / 1024. AS space_allocated_mb,
       CAST (max_size AS BIGINT) * 8 / 1024. AS max_size_mb
FROM sys.database_files
WHERE type_desc = 'ROWS';

Küçültme işlemi tamamlandıktan sonra bu sorguyu yeniden yürütebilir ve sonucu ilk taban çizgisiyle karşılaştırabilirsiniz.

Hızlı ama sınırlı kazanç için veri dosyalarını kısaltın

Tahsis edilen alanda kısa sürede bir miktar azalma sağlamak istiyorsanız, DBCC SHRINKFILE komutunu TRUNCATEONLY parametresiyle çalıştırmayı düşünün. Dosyanın sonunda tahsis edilen ama kullanılmayan bir alan varsa, işlem o alanı hızlıca ve veri hareketi olmadan ortadan kaldırır.

Ancak, amacınız tahsis edilen alandaki azalmayı en üst düzeye çıkarmaksa TRUNCATEONLY kullanmayın. Bu hedefe ulaşmak için, bu bölümün ilerleyen bölümlerinde açıklandığı şekilde tam küçültme sürecini çalıştırmanız gerekir. Bu işlem dosyaların sonunu kırptığı için, TRUNCATEONLY ile ayrı bir küçültme işlemi yapmanın hiçbir yararı yoktur.

Aşağıdaki örnek komut, dosya kimliği 4'ü kısaltmaktadır:

DBCC SHRINKFILE (4, TRUNCATEONLY);

Bu komutu her veri dosyası için çalıştırdıktan sonra, tahsis edilen alanın azalmasını görmek için alan kullanım sorgusunu tekrar çalıştırın, varsa. Ayrıca veritabanı için tahsis edilen alanı Azure portalında da görebilirsiniz.

Dizin sayfası yoğunluğunu değerlendirin

Isteğe bağlı ama önerilen bir adım olarak, veritabanındaki indekslerin ortalama sayfa yoğunluğunu belirleyin. Aynı miktarda veri için, sayfa yoğunluğu yüksekse küçültme işlemleri daha hızlı tamamlanır, çünkü işlem her dosya içinde daha az sayfa taşır. Bazı dizinlerde sayfa yoğunluğu düşükse, veri dosyalarını küçültmeden önce sayfa yoğunluğunun artırılması için bu dizinlerde bakım yapmayı göz önünde bulundurun. Daha yüksek sayfa yoğunluğu, daraltma işleminin tahsis edilen depolama alanını daha fazla azaltmasını sağlar.

Veritabanındaki tüm dizinler için sayfa yoğunluğu belirlemek için aşağıdaki sorguyu kullanın. Sayfa yoğunluğu sütunda avg_page_space_used_in_percent bildirilir.

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_page_space_used_in_percent,
       ips.avg_fragmentation_in_percent,
       ips.page_count,
       ips.alloc_unit_type_desc,
       ips.ghost_record_count
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;

Eğer sütunda bildirildiği page_count gibi sayfa yoğunluğu 60-70%'den düşük olan yüksek sayfa sayısına sahip indeksler varsa, veri dosyalarını küçültmeden önce bu indeksleri yeniden inşa etmeyi veya yeniden düzenlemeyi düşünün.

Daha büyük veritabanları için sayfa yoğunluğunun belirlenmesine yönelik sorgunun tamamlanması uzun sürebilir. Büyük dizinleri yeniden oluşturmak veya yeniden düzenlemek için de önemli zaman ve kaynak kullanımı gerekir. Ancak, küçültme öncesinde dizin bakımı küçültme süresini azaltabilir ve daha yüksek alan tasarrufu sağlayabilir.

Düşük sayfa yoğunluğuna sahip birden çok dizin varsa, işlemi hızlandırmak için bunları birden çok veritabanı oturumunda paralel olarak yeniden derleyebilirsiniz. Ancak, bunu yaparak veritabanı kaynak sınırlarına yaklaşmadığınızdan emin olun. Çalışıyor olabilecek uygulama iş yükleri için yeterli kaynak alanı bırakın. Azure portalında veya sys.dm_db_resource_stats görünümünü kullanarak kaynak tüketimini (CPU, Veri IO, Log IO) izleyin. Ek dizin işlemlerini yalnızca bu boyutların her birinde kaynak kullanımı %100’ün belirgin ölçüde altında kalıyorsa başlatın.

Örnek indeks yeniden oluşturma komutu

Aşağıdaki örnek komut, bir indeks yeniden oluşturmak ve sayfa yoğunluğunu artırmak için ALTER INDEX ifadesini kullanır:

ALTER INDEX [index_name] ON [schema_name].[table_name]
REBUILD WITH (
    FILLFACTOR = 100, MAXDOP = 8, ONLINE = ON (
        WAIT_AT_LOW_PRIORITY (MAX_DURATION = 5 MINUTES, ABORT_AFTER_WAIT = NONE)),
    RESUMABLE = ON
);

Bu komut, çevrimiçi ve devam ettirilebilen bir dizin yeniden derlemesi başlatır. Bu işlem, yeniden oluşturma işlemi devam ederken eşzamanlı iş yüklerinin tabloyu kullanmaya devam etmesini sağlar ve herhangi bir nedenle kesintiye uğrarsa yeniden derlemeyi sürdürmenize olanak tanır. Ancak, bu tür yeniden derleme, tabloya erişimi engelleyen çevrimdışı yeniden derlemeden daha yavaştır. Yeniden oluşturma sırasında tabloya başka hiçbir iş yükünün erişmesi gerekmiyorsa, ONLINE ve RESUMABLE seçeneklerini OFF olarak ayarlayın ve WAIT_AT_LOW_PRIORITY ifadesini kaldırın.

Dizin bakımı hakkında daha fazla bilgi edinmek için bkz . Sorgu performansını geliştirmek ve kaynak tüketimini azaltmak için dizin bakımını iyileştirme.

İndeksleri küçültmeden önce yeniden düzenle

İndekslerin küçülmeden önce yeniden düzenlenmesi, küçültme işlemini iki senaryoda önemli ölçüde hızlandırabilir.

1. Veritabanı aşağıdaki tüm kriterlere uyuysa:

   • Çok sayıda veri dosyası vardır (10'dan fazla).
   • Veritabanında çok sayıda tablo vardır (birkaç yüz veya daha fazla), toplamda büyük bir alan (yüzlerce gigabayt veya daha fazla) kullanılır.
   • Bazı tablolardan büyük miktarda veri silinir.

   Bu tür veritabanlar için, verileri sildiğiniz tablolarda indeksleri yeniden düzenlemek, küçültme sürecinde uzun süreli bir aşamayı kısaltır.

2. Eğer veritabanı şunları içeriyorsa:

   • Varchar(max),nvarchar(max), varbinary(max), xml gibi büyük nesne (LOB) veri tipleri veya tahsis biriminde depolanan benzer veri türleriLOB_DATA.
   • Büyük satırlar bir ayırma biriminde depolanır.
   • Columnstore dizinleri.

   Bu senaryoda küçültme işleminin daha hızlı çalışmasını ve daha fazla alan açılmasını sağlamak için, indeksleri yeniden düzenlerken LOB_COMPACTION ifadesini eklediğinizden emin olun. LOB sütunları veya büyük satırlar içeren tüm dizinler için küçültmeden önce LOB sıkıştırması önerilir.

   Küçültmeden önce columnstore dizinlerini yeniden düzenlemek veya yeniden oluşturmak benzer şekilde küçültme hızını ve etkinliğini artırabilir.

Aşağıdaki örnek, bir indeksi yeniden düzenlemek ve LOB sıkıştırması yapmak için bir komutu göstermektedir:

ALTER INDEX [index_name] ON [schema_name].[table_name]
REORGANIZE WITH(LOB_COMPACTION = ON);

Birden fazla veri dosyasını paralel olarak küçültmek

Veri taşıması gerektiren bir küçültme işlemi uzun süreli bir süreçtir. Veritabanında birden çok veri dosyası varsa, birden çok veri dosyasını paralel olarak küçülterek işlemi hızlandırabilirsiniz. Birden çok veritabanı oturumu açın ve her oturumda DBCC SHRINKFILE farklı bir file_id değeri kullanın. Daha önce dizinleri yeniden oluşturma işlemine benzer şekilde, her yeni paralel küçültme komutunu başlatmadan önce yeterli kaynak boşluğuna (CPU, Veri GÇ, Günlük GÇ) sahip olduğunuzdan emin olun.

Aşağıdaki örnek komut, dosya kimliği 4'ü küçülterek tahsis edilen boyutu 52.000 MB'e indirmeye çalışır:

DBCC SHRINKFILE (4, 52000);

Dosya için tahsis edilen alanı mümkün olan minimuma indirmek için, hedef boyut belirtilmeden ifadeyi çalıştırın:

DBCC SHRINKFILE (4);

Çok fazla paralel küçültme işlemi başlatırsanız, küçültme işlemleri arasında yüksek kaynak kullanımı ve kilitlenme anlaşmazlığı gözlemleyebilirsiniz. Çoğu senaryoda, paralel küçültme işlemlerinin optimal sayısı dört ila sekiz aralığındadır.

Kademeli olarak küçülme

Bir küçültme işlemi beklenmedik şekilde durursa (örneğin planlı veya plansız bakım nedeniyle), küçültme işlemi dosyayı kısaltmayı tamamlamadan önce bir iş yükü küçültme ile boşalan alanı kullanmaya başlayabilir ve bu da küçültme işleminin o ana kadar sağladığı ilerlemenin bir kısmının kaybolmasına neden olabilir. Küçültme işlemi genellikle uzun sürdüğü için bir kesinti yaşanma olasılığı daha yüksektir.

Bu sorunu önlemek için, her dosyayı daha küçük, kademeli adımlarla küçültün. Komutta DBCC SHRINKFILE , dosya için mevcut ayrılan alandan küçük olan hedefi, ancak temel alan kullanım sorgusunun döndürdüğü kullanılan alandan daha büyük olan hedefi belirleyin.

Örneğin, dosya kimliği 4 için ayrılan alan 200.000 MB ise ve bunu 100.000 MB'a küçültmek istiyorsanız, hedefi önce 180.000 MB olarak belirleyebilirsiniz:

DBCC SHRINKFILE (4, 180000);

Bu komut tahsis edilen boyutu 180.000 MB'a indirdikten sonra, tekrar küçültme işlemi başlatabilirsiniz; hedefi önce 160.000 MB'a, sonra 140.000 MB'e ayarlayabilir ve dosya istenen boyuta ulaşana kadar hedefi azaltmaya devam edebilirsiniz.

Dosyaları aralıklarla küçültmek daha uzun sürebilir, ancak beklenmedik bir kesinti nedeniyle tüm dosya boyunca tekrar küçültme riskini azaltır.

Başlangıç noktası olarak, 10-20 gigabayt aralığında bir artış kullanın. Senaryonuza göre artırımı ayarlayabilirsiniz. Daha büyük artışlar dosya küçültmeyi daha hızlı tamamlamanızı sağlayabilir, küçük artışlar ise küçültme kesintisi durumunda ilerleme kaybetme riskini azaltır.

Küçültme işlemlerinin izlenmesi

Tüm eşzamanlı çalışan küçültme oturumlarında küçültme ilerlemesini izlemek için aşağıdaki sorguyu kullanın:

SELECT command,
       percent_complete,
       status,
       wait_resource,
       session_id,
       wait_type,
       blocking_session_id,
       cpu_time,
       reads,
       writes,
       CAST (((DATEDIFF(s, start_time, GETDATE())) / 3600) AS VARCHAR) + ' hour(s), '
               + CAST ((DATEDIFF(s, start_time, GETDATE()) % 3600) / 60 AS VARCHAR) + 'min, '
               + CAST ((DATEDIFF(s, start_time, GETDATE()) % 60) AS VARCHAR) + ' sec'
           AS running_time
FROM sys.dm_exec_requests AS r
     LEFT OUTER JOIN sys.databases AS d
         ON r.database_id = d.database_id
WHERE r.command IN ('DbccSpaceReclaim', 'DbccFilesCompact', 'DbccLOBCompact', 'DBCC');

Not

Küçültme ilerlemesi doğrusal olmayabilir ve sütundaki percent_complete değer uzun süre değişmeden kalabilir, küçültme devam etse bile. Sorgunun iki yürütülmesi arasında aynı session_id için cpu_time, reads veya writes değerlerinde bir artış olması, shrink işleminin ilerleme kaydetmeye devam ettiği anlamına gelir.

Tüm veri dosyaları için küçültme işlemi başarıyla tamamlandığında, alan kullanım sorgusunu tekrar çalıştırın (veya Azure portalında kontrol edin) ve tahsis edilen depolama boyutunda azalma görülür. Kullanılmış alan ile tahsis edilmiş alan arasında hâlâ büyük bir fark varsa, indeksleri yeniden oluşturun veya yeniden düzenleyin . Bir indeks yeniden yapımı, tahsis edilen alanı geçici olarak artırabilir. Ancak, indeksler yeniden oluşturulduktan sonra veri dosyalarının tekrar küçültülmesi, tahsis edilen alanın daha derin bir azalmasına yol açar.

Küçültme işlemi sırasında geçici sorunlar

Bazen bir küçültme komutu, zaman aşımı ve kilitlenme gibi hatalar nedeniyle başarısız olabilir. Bu hatalar genellikle geçici olur ve aynı komutu tekrar ederseniz tekrar olmaz. Küçültme işlemi bir hatayla sonuçlanırsa, o ana kadar sağladığı ilerlemeyi korur. Dosyayı küçültmeye devam etmek için aynı küçültme komutunu yeniden çalıştırın.

ShrinkDriver PowerShell betiği, geçici bir hata oluştuğunda küçültme işlemini otomatik olarak yeniden dener. Bu betiği kullanarak büyük veritabanlarını küçültebilirsiniz.

Aşağıdaki örnek T-SQL komut dosyası, yeniden deneme döngüsü içinde tek bir dosya için küçültme işleminin nasıl çalıştırılacağını gösterir. Döngü, bir zaman aşımı hatası veya kilitlenme hatası oluştuğunda işlemi yapılandırılabilir sayıda kez otomatik olarak yeniden dener. Bu yeniden deneme yaklaşımı, küçülme sırasında meydana gelebilecek birçok diğer hataya da uygulanır.

DECLARE @RetryCount AS INT = 3; -- adjust to configure desired number of retries
DECLARE @Delay AS CHAR (12);

-- Retry loop
WHILE @RetryCount >= 0
BEGIN
    BEGIN TRY
        DBCC SHRINKFILE (1); -- adjust file_id and other shrink parameters

        -- Exit retry loop on successful execution
        SELECT @RetryCount = -1;

    END TRY
    BEGIN CATCH
        -- Retry for the declared number of times without raising
        -- an error if deadlocked or timed out waiting for a lock
        IF ERROR_NUMBER() IN (1205, 49516) AND @RetryCount > 0
        BEGIN
            SELECT @RetryCount -= 1;

            PRINT CONCAT('Retry at ', SYSUTCDATETIME());

            -- Wait for a random period of time between 1 and 10 seconds before retrying
            SELECT @Delay = '00:00:0' + CAST (CAST (1 + RAND() * 8.999 AS DECIMAL (5, 3)) AS VARCHAR (5));

            WAITFOR DELAY @Delay;

        END
        ELSE -- Raise error and exit loop
        BEGIN
            SELECT @RetryCount = -1;

            THROW;

        END
    END CATCH
END

Zaman aşımları ve çıkmazlara ek olarak, küçültme sırasında bazı bilinen sorunlar nedeniyle hatalar oluşabilir.

Aşağıdaki bölümlerde hataları ve azaltma adımlarını gözden geçirin.

Hata numarası 49503

%.*ls: Page %d:%d could not be moved because it is an off-row persistent version store page. Page holdup reason: %ls. Page holdup timestamp: %I64d.

Bu hata, uzun süreli aktif işlemlerin kalıcı sürüm deposunda (PVS) satır sürümleri oluşturduğunda ortaya çıkar. Shrink, satır sürümlerini içeren sayfaları taşıyamaz.

Bu hatayı azaltmak için, uzun süreli işlemler tamamlanana kadar bekleyin. Alternatif olarak, uzun süredir devam eden işlemleri belirleyip sonlandırın, ancak bu işlem uygulamanız işlem hatalarını zarifçe halletmezse etkileyebilir.

Daraltmayı etkileyebilecek PVS temizleme gecikmelerinin nasıl giderileceği hakkında daha fazla bilgi için bkz. Hızlandırılmış veritabanı kurtarmayı izleme ve sorun giderme.

Hata numarası 5223

%.*ls: Empty page %d:%d could not be deallocated.

Bu hata, örneğin ALTER INDEXdevam eden endeks bakım işlemleri sırasında meydana gelebilir. Bu işlemler tamamlandıktan sonra shrink komutunu yeniden deneyin.

Bu hata devam ederse, ilgili indeksi yeniden oluşturmak zorunda kalabilirsiniz. Yeniden derlenmesi gereken dizini bulmak için aşağıdaki sorguyu shrink komutunu çalıştırdığınız veritabanında yürütebilirsiniz:

SELECT OBJECT_SCHEMA_NAME(pg.object_id) AS schema_name,
       OBJECT_NAME(pg.object_id) AS object_name,
       i.name AS index_name,
       p.partition_number
FROM sys.dm_db_page_info(DB_ID(), <file_id>, <page_id>, default) AS pg
INNER JOIN sys.indexes AS i
ON pg.object_id = i.object_id
   AND
   pg.index_id = i.index_id
INNER JOIN sys.partitions AS p
ON pg.partition_id = p.partition_id;

Bu sorguyu çalıştırmadan önce, <file_id> ve <page_id> yer tutucularını hata iletisindeki gerçek değerlerle değiştirin. Örneğin, mesaj ise: Empty page 1:62669 could not be deallocated, o zaman <file_id>1 ve .<page_id>62669

Sorgu tarafından tanımlanan dizini yeniden derleyin ve shrink komutunu yeniden deneyin.

Hata numarası 5201

DBCC SHRINKDATABASE: File ID %d of database ID %d was skipped because the file does not have enough free space to reclaim.

Bu hata, veri dosyasının daha fazla küçültülemeyeceği anlamına geliyor. Sonraki veri dosyasına geçebilirsiniz.

İlgili içerik

• vCore satın alma modelini kullanan tekil veritabanları için kaynak sınırları
• DTU satın alma modelini kullanan tek veritabanları için kaynak sınırları - Azure SQL Veritabanı
• vCore satın alma modeli kullanarak elastik havuzlar için kaynak sınırları
• DTU satın alma modeli kullanıldığında elastik havuzlar için kaynak sınırları