Azure SQL Yönetilen Örneği veritabanları için dosya alanını yönetme

Şunlar için geçerlidir:Azure SQL Yönetilen Örnek

Bu makalede, Azure SQL Yönetilen Örneği'ndeki veritabanlarındaki dosyaların nasıl izleneceği ve yönetil olmadığı açıklanır. Veritabanı dosya boyutunu izlemeyi, işlem günlüğünü küçültmeyi, işlem günlüğü dosyasını büyütmeyi ve işlem günlüğü dosyasının büyümesini denetlemeyi kapsar.

Bu makale Azure SQL Yönetilen Örneği için geçerlidir. SQL Server'da işlem günlüğü dosyalarının boyutunu yönetme hakkında bilgi için bkz. İşlem günlüğü dosyasının boyutunu yönetme.

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ı Veritabanı verilerini 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ı Veritabanı verilerinin depolanması için kullanılabilir hale getirilen biçimlendirilmiş dosya alanı miktarı. Ayrılan alan miktarı otomatik olarak artar ancak silme işlemlerinden sonra azalmaz. Bu davranış, alanın yeniden biçimlendirilmesi gerekmediğinden gelecekteki eklemelerin daha hızlı olmasını sağlar.
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 Veritabanı verilerini 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.

Veritabanı miktarı tablosundaki fark veritabanı alanı kavramlarının boyutunu gösteren diyagram.

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. Sorgu sonucu birimleri MB cinsindedir.

-- 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;

Kayıt alanı kullanımını takip etme

sys.dm_db_log_space_usage kullanarak günlük alan kullanımı izleyin. Bu DMV, şu anda kullanılan günlük alanı miktarı hakkında bilgi döndürür ve işlem günlüğünün ne zaman kesilmesi gerektiğini gösterir.

Geçerli günlük dosyası boyutu, en büyük boyutu ve dosyanın otomatik büyütme seçeneği hakkında bilgi için, sys.database_files bu günlük dosyasının , max_sizeve growth sütunlarını kullanınsize.

Azure Resource Manager tabanlı ölçümLER API'lerinde görüntülenen depolama alanı ölçümleri yalnızca kullanılan veri sayfalarının boyutunu ölçer. Örnekler için bkz. PowerShell Get-AZMetric.

Günlük dosyası boyutunu küçült

Kullanılmayan alanı kaldırarak fiziksel günlük dosyasının fiziksel boyutunu küçültmek için günlük dosyasını küçültün. Küçültme yalnızca işlem günlüğü dosyası kullanılmayan alan içerdiğinde fark yaratır. Büyük olasılıkla açık işlemler nedeniyle günlük dosyası doluysa işlem günlüğünün kesilmesini neyin engellediğini araştırın.

Dikkat

Küçültme işlemleri normal bir bakım işlemi olarak kabul edilmemelidir. Düzenli ve yinelenen iş işlemleri nedeniyle büyüyen veri ve günlük dosyaları için küçültme işlemleri gerekmez. Küçültme komutları çalışan veritabanlarının performansını etkiler ve mümkünse düşük kullanım dönemlerinde çalıştırılmalıdır. Normal uygulama iş yükü dosyaların yeniden aynı ayrılmış boyuta büyümesine neden oluyorsa veri dosyalarını küçültmek önerilmez.

Veritabanı dosyalarını küçültmenin olası olumsuz performans etkisine dikkat edin. Daha fazla bilgi için bkz. Küçültme sonrasında dizin bakımı. Nadir durumlarda, otomatik veritabanı yedeklemeleri küçültme işlemlerini etkileyebilir. Gerekirse küçültme işlemini yeniden deneyin.

İşlem günlüğünü küçültmeden önce günlük kesilmesini geciktirebilecek faktörleri aklınızda bulundurun. Günlük küçülttükten sonra depolama alanı yeniden gerekiyorsa işlem günlüğü yeniden büyür ve bunu yaparak günlük büyüme işlemleri sırasında performans ek yüküne neden olur. Daha fazla bilgi için öneriler bölümüne bakın.

Günlük dosyasını yalnızca veritabanı çevrimiçiyken küçültebilirsiniz ve en az bir sanal günlük dosyası (VLF) ücretsizdir. Bazı durumlarda, günlüğü küçültmek ancak bir sonraki günlük kesildikten sonra mümkün olabilir.

Uzun süre çalışan bir işlem gibi faktörler VLF'leri uzun süre etkin tutabilir, günlük küçültmeyi kısıtlayabilir, hatta günlüğün küçülmesini engelleyebilir. Bilgi için bkz Günlük kesilmesini geciktirebilecek faktörler.

Günlük dosyasını küçültmek, mantıksal günlüğün bir bölümünü tutmayan bir veya daha fazla VLF'yi (yani, etkin olmayan VLF'ler) kaldırır. İşlem günlüğü dosyasını küçülttüğünüzde, günlüğü yaklaşık hedef boyuta küçültmek için etkin olmayan VLF'ler günlük dosyasının sonundan kaldırılır.

Küçültme işlemleri hakkında daha fazla bilgi için aşağıdaki belgeleri gözden geçirin:

Günlük dosyasını küçültme (veritabanı dosyalarını küçültmeden)

Günlük dosyalarının küçültme olaylarını izleyin

Kütük alanını izle

Küçültme sonrasında dizin bakımı

Veri dosyalarında küçültme işlemi tamamlandıktan sonra dizinler parçalanabilir. Parçalanma, büyük taramalar kullanan sorgular gibi belirli iş yükleri için bir dizinin performans iyileştirme verimliliğini azaltır. Küçültme işlemi tamamlandıktan sonra performans düşüşü oluşursa dizinleri yeniden oluşturmak için dizin bakımını göz önünde bulundurun. Dizin yeniden derlemelerinin veritabanında boş alan gerektirdiğini ve bu nedenle tedarik edilen alanın artmasına neden olabileceğini ve küçültmenin etkisini azaltabileceğini unutmayın.

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.

Dizin sayfası yoğunluğunu değerlendirin

Veri dosyalarının kesilmesi ayrılan alanda yeterli azalmaya neden olmazsa, kullanılmayan alanı bu dosyalardan geri kazanmak için veritabanı veri dosyalarını küçültmeye karar vekleyebilirsiniz. Ancak, isteğe bağlı ancak önerilen bir adım olarak, önce veritabanındaki dizinler için ortalama sayfa yoğunluğu belirlemeniz gerekir. Aynı miktarda veri için, sayfa yoğunluğu yüksekse daha az sayfa hareket ettiğinden küçültme işlemi daha hızlı tamamlanı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. Bu adım, küçültmenin ayrılan depolama alanında daha derin bir azalma elde etmenizi 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;

Sayfa yoğunluğu %60-70'in altında olan yüksek sayfa sayısına sahip dizinler varsa, veri dosyalarını küçültmeden önce bu dizinleri yeniden oluşturmayı veya yeniden düzenlemeyi göz önünde bulundurun.

Not

Daha büyük veritabanlarında sayfa yoğunluğunun belirlenmesi için yapılan sorgunun tamamlanması uzun sürebilir. Ayrıca, büyük dizinleri yeniden oluşturmak veya yeniden düzenlemek için de önemli zaman ve kaynak kullanımı gerekir. Bir yandan sayfa yoğunluğunun artırılmasına fazladan zaman harcamanın, küçültme süresini azaltmanın ve diğer yandan daha yüksek alan tasarrufu elde etmenin bir dezavantajı vardır.

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 ve 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 GÇ, Günlük GÇ) izleyin. Yalnızca bu boyutların her birinde kaynak kullanımı 100%'den büyük ölçüde düşük kalırsa paralel yeniden derlemeler başlatın. CPU, Veri GÇ veya Günlük GÇ kullanımı%100'deyse, daha fazla CPU çekirdeğine sahip olmak ve GÇ aktarım hızını artırmak için veritabanının ölçeğini artırabilir ve daha fazla paralel yeniden derlemenin işlemi daha hızlı tamamlayabilmesini sağlayabilirsiniz.

Örnek dizin yeniden oluşturma komutu

Aşağıda ALTER INDEX deyimini kullanarak bir dizini yeniden derlemek ve sayfa yoğunluğunu artırmak için örnek bir komut verilmiştir:

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 tür yeniden derleme, 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 cümlesini 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.

Birden çok veri dosyasını küçültme

Daha önce belirtildiği gibi, veri taşıma ile küçültme uzun süren bir işlemdir. Veritabanında birden çok veri dosyası varsa, birden çok veri dosyasını paralel olarak küçülterek işlemi hızlandırabilirsiniz. Bu işlemi birden çok veritabanı oturumu açarak ve her oturumda farklı file_id bir değerle kullanarak DBCC SHRINKFILE yaparsınız. Her yeni paralel küçültme komutunu başlatmadan önce, dizinleri yeniden derlemeye benzer bir şekilde, yeterli kaynağa (CPU, Veri GÇ, Günlük GÇ) sahip olduğunuzdan emin olun.

Aşağıdaki örnek komut, file_id 4 parametresi ile çalıştırılarak veri dosyasının ayrılan boyutunu içinde sayfaları taşıyarak 52.000 MB'a düşürmeye çalışır.

DBCC SHRINKFILE (4, 52000);

Dosya için ayrılan alanı mümkün olan en aza düşürmek istiyorsanız, hedef boyutu belirtmeden deyimini yürütün:

DBCC SHRINKFILE (4);

Bir iş yükü küçültmeyle aynı anda çalışıyorsa, küçültme işlemi tamamlanıp dosya gerçekten küçültülmeden önce, küçültme tarafından boşaltılan depolama alanını kullanmaya başlayabilir. Bu durumda, küçültme belirtilen hedefe ayrılan alanı azaltamaz.

Her dosyayı daha küçük adımlarda küçülterek bu sorunu azaltabilirsiniz. Bu, komutta DBCC SHRINKFILE dosya için ayrılan geçerli alandan biraz daha küçük olan hedefi ayarladığınız anlamına gelir. Örneğin, file_id 4 içeren dosya için ayrılan alan 200.000 MB ise ve 100.000 MB'a küçültmek istiyorsanız, önce hedefi 170.000 MB olarak ayarlayabilirsiniz:

DBCC SHRINKFILE (4, 170000);

Bu komut tamamlandıktan sonra dosyayı keserek ayrılan boyutunu 170.000 MB'a indirir. Daha sonra bu komutu yineleyebilir, önce hedefi 140.000 MB'a, ardından 110.000 MB'a ayarlayabilirsiniz ve dosya istenen boyuta küçülene kadar bu şekilde devam edebilirsiniz. Komut tamamlanırsa ancak dosya kesilmemişse, 30.000 MB yerine 15.000 MB gibi daha küçük adımlar kullanın.

Eşzamanlı olarak çalışan tüm küçültme oturumlarında küçültme ilerleme durumunu izlemek için aşağıdaki sorguyu kullanabilirsiniz:

SELECT command,
       percent_complete,
       status,
       wait_resource,
       session_id,
       wait_type,
       blocking_session_id,
       cpu_time,
       reads,
       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 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 küçültme işlemi devam etse bile sütundaki percent_complete değer uzun süre değişmeden kalabilir.

Tüm veri dosyaları için küçültme tamamlandıktan sonra ayrılan depolama boyutundaki azalmayı belirlemek için alan kullanımı sorgusunu kullanın. Kullanılan alan ile ayrılan alan arasında hala büyük bir fark varsa, dizinleri yeniden oluşturabilirsiniz. Yeniden derleme, ayrılan alanı geçici olarak artırabilir, ancak dizinleri yeniden derledikten sonra veri dosyalarının yeniden küçültülmesi ayrılan alanın daha derin bir şekilde azalmasına neden olmalıdır.

Günlük dosyasını büyütme

Azure SQL Yönetilen Örneği'nde, disk alanı izin verirse mevcut günlük dosyasını büyüterek günlük dosyasına alan ekleyebilirsiniz. Veritabanına günlük dosyası ekleme desteklenmez. Günlük alanı tükenmiyorsa ve günlük dosyasının bulunduğu birimde disk alanı da dolmadığı sürece bir işlem günlük dosyası yeterlidir.

Günlük dosyasını büyütmek için deyiminin MODIFY FILE yan tümcesini ALTER DATABASE kullanın ve ve MAXSIZE söz dizimini SIZE belirtin. Daha fazla bilgi için bkz . ALTER DATABASE (Transact-SQL) Dosya ve Dosya Grubu seçenekleri.

Daha fazla bilgi için bkz . Öneriler.

İşlem günlüğü dosyasının büyümesini denetleme

İşlem günlüğü dosyasının büyümesini yönetmek için ALTER DATABASE (Transact-SQL) File ve Filegroup options deyimini kullanın. Aşağıdaki seçeneklere dikkat edin:

  • SIZE Geçerli dosya boyutunu KB, MB, GB ve TB birimlerinde değiştirmek için seçeneğini kullanın.
  • Büyüme artışını FILEGROWTH değiştirmek için seçeneğini kullanın. 0 değeri, otomatik büyümenin kapalı olarak ayarlandığını ve ek alan izin verilmediğini gösterir.
  • MAXSIZE Kb, MB, GB ve TB birimlerinde bir günlük dosyasının en büyük boyutunu denetlemek veya büyümeyi olarak UNLIMITEDayarlamak için seçeneğini kullanın.

Öneriler

İşlem günlüğü dosyalarıyla çalışırken aşağıdaki önerileri göz önünde bulundurun:

  • seçenek tarafından yapılandırıldığı gibi işlem günlüğünün otomatik büyüme (otomatik büyüme) artışını FILEGROWTH iş yükü işlemlerinizin gereksinimlerini karşılayacak kadar büyük olacak şekilde ayarlayın. Günlük dosyasındaki dosya büyüme artışını sık sık genişlemeyi önlemek için yeterince büyük hale getirin. İşlem günlüğünü düzgün bir şekilde boyutlandırmak için şu süre boyunca kaplanmış günlük miktarını izleyebilirsiniz:

    • Günlük yedeklemeleri bitene kadar gerçekleşemediğinden tam yedekleme yürütmek için gereken süre.
    • En büyük dizin bakım işlemleri için gereken süre.
    • Veritabanındaki en büyük toplu işlemi yürütmek için gereken süre.

  • Yüzde sürekli büyüyen bir miktar olduğundan büyüme oranı üzerinde daha iyi denetim sağlamak için yerine içindeki seçeneğini sizepercentagekullanarak FILEGROWTH veri ve günlük dosyaları için otomatik büyütmeyi ayarlayın.

    • Azure SQL Yönetilen Örneği'nde, anlık dosya başlatma 64 MB'a kadar işlem günlüğü büyüme olaylarına fayda sağlayabilir. Yeni veritabanları için varsayılan otomatik büyüme boyutu artışı 64 MB'tır. 64 MB'tan büyük işlem günlüğü dosyası otomatik büyütme olayları, anlık dosya başlatmadan yararlanamaz.
    • En iyi uygulama olarak, işlem günlükleri için seçenek değerini 1.024 MB'ın üzerine ayarlamayın FILEGROWTH .

  • Çok fazla küçük VLF oluşturabileceği ve performansı düşürebileceği için küçük bir otomatik büyüme artışı ayarlamaktan kaçının. Belirli bir örnekteki tüm veritabanlarının geçerli işlem günlüğü boyutu için en uygun VLF dağılımını ve gerekli boyuta ulaşmak için gerekli büyüme artışlarını belirlemek için, SQL Tiger Ekibi tarafından sağlanan VLF'leri analiz etmek ve düzeltmek için bu betike bakın.

  • İki soruna neden olabileceğinden büyük bir otomatik büyüme artışı ayarlamaktan kaçının:

    • Yeni alan ayrılırken veritabanı duraklatılabilir ve bu da sorgu zaman aşımlarına neden olabilir.
    • Çok az ve büyük VLF'ler oluşturabilir ve performansı da etkileyebilir. Belirli bir örnekteki tüm veritabanlarının geçerli işlem günlüğü boyutu için en uygun VLF dağılımını ve gerekli boyuta ulaşmak için gerekli büyüme artışlarını belirlemek için, SQL Tiger Ekibi tarafından sağlanan VLF'leri analiz etmek ve düzeltmek için bu betike bakın.

  • Otomatik büyütme etkinleştirildiğinde bile sorgunuzun gereksinimlerini karşılayacak kadar hızlı büyüyemiyorsa işlem günlüğünün dolu olduğunu belirten bir ileti alabilirsiniz. Büyüme artışını değiştirme hakkında daha fazla bilgi için bkz ALTER DATABASE (Transact-SQL) Dosya ve Dosya Grubu seçenekleri.

  • Günlük dosyalarını otomatik olarak küçülecek şekilde ayarlayabilirsiniz. Ancak bu uygulama önerilmez ve auto_shrink veritabanı özelliği varsayılan olarak YANLIŞ olarak ayarlanır. auto_shrink TRUE olarak ayarlarsanız, otomatik küçültme yalnızca alanının yüzde 25'inden fazlası kullanılmadığında dosyanın boyutunu küçültür.

İlgili içerik

  • Last updated on