SQL LDF Dosyları

LDF Uzantılı dosyalar (Log Data File) SQL Server daki log dosyalarıdır. Bu dosyaları silmeniz halinde db yi SQL Servera direkt attach etmekte zorlanırsınız. Silmek yerine shrink işlemi ile küçültebilirsiniz.

pardon ben bilmiyorumda bu shrink işlemi nasıl yapalır acaba

SQL Server 2005 ile Shrink İşlemi:

Hangi veritabanına sıkıştırma işlemi uygulayacaksak o
veritabanı üzerinde sağ tuş - Tasks - Shrink. Yapabileceğimiz Shrink işlemleri menüde listelenecektir. Buradan Files  - Dosya tür ve ismini seçin -

• Release unused space-. Bu seçeneği işaretleyerek, dosyanızdaki
  kullanılmayan alanların işletim sistemine iade edilme durumu
  gerçekleştirilir. 
• Reorganize files before releasing unused space' - Bu seçenekte Shrink file to
  seçeneği özellikle belirlenmesi gerekiyor. Varsayılan değer olarak, bu
  seçenek seçili değildir. Bu seçeneği seçerek, dosya içerisinde
  kullanılmayan herhangi bir boşluk işletim sistemine bırakılır ve tahsis
  edilmemiş sayfalara yerleştirilmeye çalışırılır. İsteğe bağlı
  olarak, sıkıştırma işleminden sonra, veritabanı dosyasına kalacak olan
  en büyük boş alan yüzdelik dilimi girebilirsiniz. Bu yüzdelik dilim
  aralığı 0 ile 99 arasında olabilir. Bu seçenek ancak 'Reorganize files before releasing unused space' seçeneği aktif olduğunda kullanılabilir.
• Empty file by migrating the data to other files in the same filegroup - Bu seçenek; bütün verileri, belirlediğimiz dosyadan, filegroup içindeki diğer dosyaya taşımaktadır.

SQL Server 2000 Enterprise Manager İle Sıkıştırma İşlemi:

Küçültmek istediğiniz veritabanının üzerinde sağ tuş - All Tasks - Shrink Database

• Maximum free space in files after shrinking -  veritabanını ne kadar yüzde ile küçültüleceğini belirtmektedir.
• Move pages to begining of file before shrinking - sayfaları
  yerdeğiştirerek, veritabanı dosyalarının içindeki veriyi yeniden
  düzenlemek için seçilir. Küçültme işlemini yavaşlatır, bunun yanında
  veritabanının performansını geliştirir.
• Shrink the database based on this schedule - Veritabanı küçültme işlemini, belirli zamanlarda otomatik olarak gerçekleştirir.
• Database files can be shrunk individually if more precise control is
  required - Buradaki, Files komut düğmesine bastığımızda açılan pencerede Database file seçeneğinden seçtiğiniz DB yi belirlediğiniz ayarlarla küçültebilirsiniz. 

NOT: Herzaman bir işleme başlamadan önce yedek almayı unutmayınız.

çok tşk.

Rica ederim. Umarım faydalı olabilmişizdir.

LDF Uzantılı dosyalar (Log Data File) SQL Server daki log dosyalarıdır. Bu dosyaları silmeniz halinde db yi SQL Servera direkt attach etmekte zorlanırsınız. Silmek yerine shrink işlemi ile küçültebilirsiniz.

merhaba Sinan Bey Haklı silmeyiniz.Bu dosyalar data dosyasında yapılan değişiklikleri loglar ve silerseniz database suspect olur.Bunun ile alakalı şöyşle bir çözüm olabilir.Database özelliklerinden recovery altında model kısmında full yazar bunu simple yapmanız gerekir.sonrada sinan beyin söylediği gibi shrink yapabilirsiniz.Yine aynı kısımda autoshrink var chek atarsanızda belli zaman sonra küçültür dosyayı.
bu işlemden sonra tekrar recovey modu full yapınız.
selamlar

Merhabalar,

değerli yorumlarınız için ben de konuya girerek teşekkür etmek isterim.

Benim de bir süre önce LDF lerin boyutunun çok yüksek olması olayı başıma gelmişti. Ben bu konuda şunları merak ediyorum:

1..Benim LDF dosyam gb lar mertebesindeydi, fakat anlayamoyrum , Ne oluyorda LDF dosyaları bazen boyle yuksek rakamlara cıkıyor, sebebi nedir?

2. "Database özelliklerinden recovery altında model kısmında full yazar bunu simple yapmanız.."  diye cevaplamıs hocam. ben de buna benzer bir yontem yapmıstım, fakat bilmeden, oneri uzerine. Hazır yeri gelmisken Recovery seceneginin FULL olması ne saglıyor, Simple olması ne saglıyor? LDF uzerindemi etkili bu secenek?

Selam;

Recovery Model, bir veritabanı özelliğidir ve istenildiğinde
değiştirilebilir. Backup ve Restore işlemleri
Recovery Model altında gerçekleşir. Veritabanınız için
belirlediğiniz Recovery Model, veritabanınızın yedeğini alma ve açma
seçeneklerinizi belirleyecektir. Bu nedenle özellikle trafiği yoğun
olan veritabanlarında çok dikkat etilmesi gereken bir ayardır. Bir
veritabanının Recovery Model ayarı, Transaction Log' ların nasıl
kaydedileceğini belirler. SQL Server' da, Transaction Log' un
tutulmaması diye bir şey yoktur. Her halükârda Transaction Log' a
veriler kaydedilir , ama
bu kayıtların nasıl işleneceğini ve yönetileceğini Recovery Model'
larla belirlersiniz.

FULL Recovery Model
Eğer DB niz Production bir DB ise yani DB çalışan ve dinamik bir sistemde kullanılıyorsa, bir sorun olduğunda veri
kaybını göze alamayacaksak ve ciddi bir yedekleme gerekiyorsa DB nizin Recovery Model' ının FULL olması gerekmektedir.
Böylece, DB üzerinde gerçekleştirilen her işlem tam olarak
kaydedilir ve yedeği alınabilir. Böylece Hata Anı denilen ana
kadar verilerinizin yedeğini alabilir ve o ana yedekleriniz ile tekrar
ve tam olarak dönebilirsiniz. Bunu en güvenli şekilde FULL Recovery
Model ile sağlayabilirsiniz.

SIMPLE Recovery Model
Program geliştiriciler,
veritabanını test edenler, raporlama amaçlı kullanılan DB ler, üzerinde çok nadir güncelleme yapılan DB ler için en uygun Recovery Model' dır. Her işlem
Transaction Log' a kaydedilir. SIMPLE Recovery Model' da da aynen FULL Recovery Model' da olduğu gibi
tüm işlemler Transaction Log' a kaydedilir, fakat her Checkpoint' ten Inactive Virtual Logs Transaction
Log dosyası içinden silinirler. Böylece Transaction Log dosyanız
sürekli büyümez. Aktif olmayan sanal kayıtlar, temizleme esnasında
Transaction Log dosyası içindeki dosyanın en sonunda bulunan aktif
sanal kaydına kadar temizlenebilir. Aktif sanal kayıt da, Transaction
Log dosyasında o anda hâlâ işlem görüyor olan bir Transaction
işlemidir. Aktif sanal kayıtlar, işlem bitene kadar
temizlenemezler.

 

Hocam çok teşekkür ederim.

Anlattığınız şekilde her zaman FULL kullanmalıyım, çünkü sürekli yazılan bir database im var. Sanırım Simple secenegi Exchange 2003 deki circular logging in aktif edilmesi gibi birsey oluyor. Çalışılan zamandan daha önceki bir zamandaki backup dan donerken veri kaybı kacınılmaz gorunuyor.Doğru mu anlamışım?

Bir de ne kadar sağlıklı oluyor bilmiyorum ama şunu sormak istiyorum: 

1.SQL 2000 üzerinde her aksam Full backup alıyorum. Full backup dan sonra LDF dosyasına yazılan veriler tamamen gercek database e yazılıyor diye biliyorum. Normalde FULL backup alnmazsa hangi aralıklarla LDF dosyalarından database e aktarılıyor veriler bunu çok merak ediyorum?

2. Bir de Full backup gibi  Incremential backup dan sonra da  LDF dosyasındaki veriler database e yazılmıs oluyor mu?

 

Merhaba,

Sql Query Analyzer ile, script ile de küçültebilirsiniz.

--
BACKUP LOG VERITABANIADI with truncate_only
GO
DBCC SHRINKFILE(VERITABANIADI_log)
--

dosyanın boyutu otomatik olarak 504 kb'a düşer.

Selam;

Recovery Model, bir veritabanı özelliğidir ve istenildiğinde değiştirilebilir. Backup ve Restore işlemleri Recovery Model altında gerçekleşir. Veritabanınız için belirlediğiniz Recovery Model, veritabanınızın yedeğini alma ve açma seçeneklerinizi belirleyecektir. Bu nedenle özellikle trafiği yoğun olan veritabanlarında çok dikkat etilmesi gereken bir ayardır. Bir veritabanının Recovery Model ayarı, Transaction Log' ların nasıl kaydedileceğini belirler. SQL Server' da, Transaction Log' un tutulmaması diye bir şey yoktur. Her halükârda Transaction Log' a veriler kaydedilir , ama bu kayıtların nasıl işleneceğini ve yönetileceğini Recovery Model' larla belirlersiniz.

FULL Recovery Model
Eğer DB niz Production bir DB ise yani DB çalışan ve dinamik bir sistemde kullanılıyorsa, bir sorun olduğunda veri kaybını göze alamayacaksak ve ciddi bir yedekleme gerekiyorsa DB nizin Recovery Model' ının FULL olması gerekmektedir. Böylece, DB üzerinde gerçekleştirilen her işlem tam olarak kaydedilir ve yedeği alınabilir. Böylece Hata Anı denilen ana kadar verilerinizin yedeğini alabilir ve o ana yedekleriniz ile tekrar ve tam olarak dönebilirsiniz. Bunu en güvenli şekilde FULL Recovery Model ile sağlayabilirsiniz.

SIMPLE Recovery Model
Program geliştiriciler, veritabanını test edenler, raporlama amaçlı kullanılan DB ler, üzerinde çok nadir güncelleme yapılan DB ler için en uygun Recovery Model' dır. Her işlem Transaction Log' a kaydedilir. SIMPLE Recovery Model' da da aynen FULL Recovery Model' da olduğu gibi tüm işlemler Transaction Log' a kaydedilir, fakat her Checkpoint' ten Inactive Virtual Logs Transaction Log dosyası içinden silinirler. Böylece Transaction Log dosyanız sürekli büyümez. Aktif olmayan sanal kayıtlar, temizleme esnasında Transaction Log dosyası içindeki dosyanın en sonunda bulunan aktif sanal kaydına kadar temizlenebilir. Aktif sanal kayıt da, Transaction Log dosyasında o anda hâlâ işlem görüyor olan bir Transaction işlemidir. Aktif sanal kayıtlar, işlem bitene kadar temizlenemezler.

 

merhabalar,

konu eski biraz ama gercekten öğretici,ben bu konuyla ilgili Sinan hocamın cevabında gecen aktif sanal kayıt ve aktif olmayan sanal kayıt kavramına takıldım. Transaction log dosyasına yazılmış ama henuz database e gercek anlamda yazılmamıs olan kayıtlara mı aktif sanal kayıt diyoruz, ben oyle hayal ettim çünkü:) aydınlatırsanız sevinirim

Arkadaşlar ortalama ne kadar küçülür shrink işlemi yaptığımızda. database e göre değişir ama 16 GB lık ldf dosyası var bende. akşam önce backup sonra shrink işlemi başlatacağım.

o andaki log kullanımınıza bağlı. logun ne kadarının kullanıldığına

DBCC sqlperf('logspace')

komutu ile bakabilirsin.

Ne kadarının dolu olduğu o anda açık olan transactionlara ve recovery model'ine bağlıdır. Full recovery model'de commit edilmiş transaction lar delete edilmez. Dolayısıyla log dosyası sürekli büyür. Log backup alınarak truncate edilebilir.

Simple recovery model de Log backup alınması gerek yoktur zaten alınamaz. Commit edilmiş transaction lar periyodik olarak silinir.

Merhaba database dosyasını ve ldf dosyasını shrink yaptım. Tahmin ettiğim gibi küçültme işlemi yapmadı. LDF dosya boyutu : 16 GB Database boyutu 1 Gb. Bundan bir ay önce kadar CA backup yazılımım backup alamadığı için database simple moda geçirmiştim.

shrink te succesfull almama rağmen bu dosyalar küçülmedi. Ne yapabilirim?

Teşekkürler.

Veritabanınızı FULL recovery moda alıp sırasıyla aşağıdaki işleri yapmalısınız:

1. Veritabanının FULL backup alınmalı


2. Transaction Log Backup alınmalı


3. Log file shrink edilmeli

Transaction Log Backup'ı alan bir maintenance plan tanımlarsanız log dosyanız çok fazla büyümez.

Merhaba database dosyasını ve ldf dosyasını shrink yaptım. Tahmin ettiğim gibi küçültme işlemi yapmadı. LDF dosya boyutu : 16 GB Database boyutu 1 Gb. Bundan bir ay önce kadar CA backup yazılımım backup alamadığı için database simple moda geçirmiştim.

shrink te succesfull almama rağmen bu dosyalar küçülmedi. Ne yapabilirim?

Teşekkürler.

dbcc sqlperf(logspace) sorgusunun sonucunu gönderir misin

db            Log Size(mb): 18301.68            Log Spaced Used (%): 93.19046   Status: 0

 

Veritabanınızı FULL recovery moda alıp sırasıyla aşağıdaki işleri yapmalısınız:

1. Veritabanının FULL backup alınmalı


2. Transaction Log Backup alınmalı


3. Log file shrink edilmeli

Transaction Log Backup'ı alan bir maintenance plan tanımlarsanız log dosyanız çok fazla büyümez.

Mehmet bey dediğinizi dün akşam yapmıştım. Bir gelişme olmamıştı. Ancak son cümlenizi nasıl yapacağımı tam olarak bilmiyorum.

"Transaction Log Backup'ı alan bir maintenance plan tanımlarsanız log dosyanız çok fazla büyümez."  Teşekkürler.