Konu Başlıkları: MS SQL Server 2000, Transaction Logs, Transactions, Database Integrity, Recovery, Truncate, Shrink, DBCC SQLPERF, DBCC SHRINKFILE, BACKUP LOG
Öncelikle SQL sunucumuzdaki data ve log dosyalarının boyutlarını öğrenebilmek için aşağıdaki komutu kullanıyoruz:
DBCC SQLPERF ( LOGSPACE )
MS SQLServer 2000 de Log dosyasını boyutunu azaltmak (shrink) için 3 metod mevcuttur:
- DBCC SHRINKDATABASE yani veritabanının boyutunu komple azaltırken log dosyasınında otomatik ayarlanması.
- DBCC SHRINKFILE ile log dosyası boyutunun ayarlanması.
- autoshrink operasyonu ile.
Biz burada DBCC SHRINKFILE metodu üzerinde duracağız.
DBCC SHRINKFILE
( { file_name | file_id }
{ [ , target_size ]
| [ , { EMPTYFILE | NOTRUNCATE | TRUNCATEONLY } ]
}
)
SQL sunucular acaba bu log dosyalarını niçin tutuyor diye düşünüyorsanız bunun başlıca sebepleri şunlardır:
- Eğer ROLLBACK işlemi uygulanırsa veya SQL Sunucu veri alışverişi sırasında bir hata oluştuğuna kanaat getirirse bilgiler log dosyasından tamamlanmamış transaction bölümlerine geri alınabilir.
- Eğer SQL Sunucu bir iç hata sonucu düzgün çalışmaz hale gelir ise tampon belleklerdeki bilgilerin (buffer caches) veritabanlarının fiziksel veri dosyalarına yazma işlemlerinde aksamalar ve veri dosyalarında düzensiz işlemler (transactions) oluşabilir. Bu gibi durumlarda SQL sunucunun kopyası çalıştığında tüm veritabanları için bir recovery yani kayıpları telafi etme süreci başlatılır. Fiziksel dosyalara yazılamayan veriler log dosyasından alınarak işlenir (roll forward), tamamlanmamış ve eksik verilerin log dosyalarından geri alınması işlemi uygulanarak (roll back) veritabanı bütünlüğü (database integrity) sağlanır.
- RAID desteği olmayan sunucuların veritabanlarında disk hatası sonucu eğer kayıplar oluşur ise veritabanınızı yedeklerden geri çağırdıktan sonra hata oluşumundan sonraki tüm veri işlemlerini log dosyasından veritabanına uygulayabilirsiniz.
SQL Sunucu log dosyaları fiziksel olarak sunucu diskinde barındırılır ve birden falza parça halinde olabilirler. Eğer log kayıtları ara ara silinmez ise mantıksal log dosyası fiziksel disk boyutu bitene kadar büyür. Yeni mantıksal log dosyası kayıtları için eskilerinin silinmesi gerekliliği ortaya çıkar. Bunun sonucunda mantıksal log dosyaları üzerinde Truncate/Shrink işlemi uygulanması gerekebilir.
Veritabanı recovery planına göre aktif log parçası belirlenir ve bu log parçası Truncate işlemine tabi tutulamaz. Bu log parçasındaki bilgiler kısa süreli yani aktif veri işlemleri için bir önem arz etmezler. Ancak veritabanı sunucunda bir iç hata meydana gelir ve veri kayıpları yaşanırsa en son yedekten geri yüklenen veritabanı üstünde, yedek alındığı günden bugüne kadarki tüm işlemler aktif log dosyasından veritabanı üzerine uygulanabilir.
Aşağıda transaction log dosyasının kayıt prosedürünün nasıl işlediği görülmektedir.
Şimdi elimizde 500MB bir Transaction Log dosyası olduğunu düşünelim. Bu dosya 5×100MB lık Sanal Log parçalarından oluşsun ve Mantıksal Log kayıtları aşağıdaki şekilde 3. ve 4. parçalarda bulunsun.
Eğer biz DBCC SHRINKFILE komutunu Hedeflenen Miktarı (target_size) 270MB şeklinde uygulamaya çalışırsak:
USE pubs
DBCC SHRINKFILE ('pubs_Log', 270)
SQL Sunucunun yapacağı işlemler şu şekilde olacaktır. Öncelikle 5 numaralı sanal log derhal silinecektir. Daha sonrasında 4 numaralı sanal logun silinmesi gereklidir ancak burada veriler bulunmaktadır. Bu durumda SQL Sunucu verilerden arta kalan alanı geçici anlamsız kayıtlarla doldurur. Böylece mantıksal log alanının sonu otomatik olarak 1 numaralı sanal log alanına kayar ve log dosyamızı aşağıdaki şekle dönüşür.
İşlemin sonunda BACKUP LOG işlemini uygularsanız aşağıdaki şekle dönüşen log dosyamıza tekrar DBCC SHRINKFILE işlemini uygularsanız kalan bölümlerinde temizlenmesini sağlayabilirsiniz.
Eğer DBCC SHRINKFILE işlemi ile log dosyasını istediğiniz boyuta indiremiyorsanız aşağıdaki işlemlerden birini deneyebilirsiniz:
- Transaction Log dosyasının yedeğini almak istemiyorsanız:
BACKUP LOG pubs WITH TRUNCATE_ONLY
- Transaction Log dosyasının yedeğini pubslogbackup cihazına almak istiyorsanız:
BACKUP LOG pubs TO pubslogbackup
bu işlemlerden birini uyguladıktan sonra tekrar DBCC SHRINKFILE komutunu kullanırsanız log dosyası ayarlanacaktır.
BACKUP LOG komutunun parametreleri aşağıdaki şekildedir:
Backing up a transaction log:
BACKUP LOG { database_name | @database_name_var }
{
TO < backup_device > [ ,…n ]
[ WITH
[ BLOCKSIZE = { blocksize | @blocksize_variable } ]
[ [ , ] DESCRIPTION = { ‘text‘ | @text_variable } ]
[ [ ,] EXPIREDATE = { date | @date_var }
| RETAINDAYS = { days | @days_var } ]
[ [ , ] PASSWORD = { password | @password_variable } ]
[ [ , ] FORMAT | NOFORMAT ]
[ [ , ] { INIT | NOINIT } ]
[ [ , ] MEDIADESCRIPTION = { ‘text‘ | @text_variable } ]
[ [ , ] MEDIANAME = { media_name | @media_name_variable } ]
[ [ , ] MEDIAPASSWORD = { mediapassword | @mediapassword_variable } ]
[ [ , ] NAME = { backup_set_name | @backup_set_name_var } ]
[ [ , ] NO_TRUNCATE ]
[ [ , ] { NORECOVERY | STANDBY = undo_file_name } ]
[ [ , ] { NOREWIND | REWIND } ]
[ [ , ] { NOSKIP | SKIP } ]
[ [ , ] { NOUNLOAD | UNLOAD } ]
[ [ , ] RESTART ]
[ [ , ] STATS [ = percentage ] ]
]
}
< backup_device > ::=
{
{ logical_backup_device_name | @logical_backup_device_name_var }
|
{ DISK | TAPE } =
{ ‘physical_backup_device_name‘ | @physical_backup_device_name_var }
}
< file_or_filegroup > ::=
{
FILE = { logical_file_name | @logical_file_name_var }
|
FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
}
Truncating the transaction log:
BACKUP LOG { database_name | @database_name_var }
{
[ WITH
{ NO_LOG | TRUNCATE_ONLY } ]
}
Son Yorumlar