Discussion:
ldf mdf den büyükse
(too old to reply)
mahmut
2008-04-04 07:52:00 UTC
Permalink
merhaba;

xxx.ldf dosyası =37 gb , xxx.mdf dosyası = 7 gb
anormal bir durum olduğu ortada yazılımcı olmadığım için kendi başıma bir
çözüm üretemedim arama sitesinden aradım ama bişey çıkmadı

bu durum için ne önerirsiniz
mahmut
2008-04-04 08:56:01 UTC
Permalink
logo ticari ürününü kullanıyorum.sql 2000 var
ldf > mdf den büyük. internette biraz daha araştırdıktan sonra
DBCC SHRINKDATABASE (db, NOTRUNCATE)
DBCC SHRINKDATABASE (db, TRUNCATEONLY)
bu yardımı buldum.sanal bilgisayarda bu işlemi uyguladım
xxx.mdf=6.7 gb
xxx.ldf = 19 gb
ye düştü .
logo ticari ürününü açtım ve raporlar aldım bir hata vermedi
yukarıdaki işlem database e zarar verirmi ?
ve ldf dosyası halen mdf den büyük
bu sorun olurmu


teşekkürler
Post by mahmut
merhaba;
xxx.ldf dosyası =37 gb , xxx.mdf dosyası = 7 gb
anormal bir durum olduğu ortada yazılımcı olmadığım için kendi başıma bir
çözüm üretemedim arama sitesinden aradım ama bişey çıkmadı
bu durum için ne önerirsiniz
Ekrem Önsoy
2008-04-04 09:21:02 UTC
Permalink
Aşağıda adresini verdiğim makalemi okuyabilirsin:
http://www.ekremonsoy.net/makaleler/sql/tlog_buyumesi/tlog_buyumesi.aspx
--
Ekrem Önsoy
http://www.ekremonsoy.net , http://ekremonsoy.blogspot.com
MCDBA, MCITP:DBA, MCSD.Net, MCSE, MCBMSP, MCT
Post by mahmut
merhaba;
xxx.ldf dosyası =37 gb , xxx.mdf dosyası = 7 gb
anormal bir durum olduğu ortada yazılımcı olmadığım için kendi başıma bir
çözüm üretemedim arama sitesinden aradım ama bişey çıkmadı
bu durum için ne önerirsiniz
HÝLMÝ
2008-04-07 07:16:03 UTC
Permalink
merhaba

log dosyalarýnýn yani ldf in mdf den büyük olmasý gayet normal zaten belli
bir zaman sonra ldf mdf i geçmediyse ldf'in çalýþmasýnda bir sorun var
demektir. ldf dosyasý mdf üzerinde yapýlan her deðiþikliðin kaydýný tutar
yani mdf üzerinde yapýlan her kayýt ekleme, silme düzenleme ldf üzerinde
tarih saat olarak nerede yapýldýðýna dair gibi kayýtlar tutulur. örneðin mdf
üzerinde 1000 kayýt üzerinde güncelleme yapýlýrsa mdf in boyutunda bir
deðiþiklik olmamasýna raðmen ldf her satýrýn deðiþtiði bilgisini kaydeder ve
böylece ldf dosyasý büyürde büyür bilmem anlatabildim mi, Bu ldf dosyasýný
küçültmenin yolu var tabi eðer full ldf alýnmazsa biraz daha yavaþ büyür ve
database üzerine gelip task'tan shrink denildiði taktirde gereksiz loglar
temizlenir.
Post by mahmut
merhaba;
xxx.ldf dosyasý =37 gb , xxx.mdf dosyasý = 7 gb
anormal bir durum olduðu ortada yazýlýmcý olmadýðým için kendi baþýma bir
çözüm üretemedim arama sitesinden aradým ama biþey çýkmadý
bu durum için ne önerirsiniz
Murat Altay
2008-04-07 17:33:50 UTC
Permalink
Burada kafamda oturtamadýðým bir konu var. Recovery mode Full olan bir veri
tabanýnýn Log'unu shrink yaptýðýmýzda logtan geri dönmek sorun olmaz mý.
Logu Shrink yapmak tamamlanmýþ olan transacationlarý silmek anlamýna
gelmiyor mu. Shrink ne yapar tam olarak.
Post by mahmut
merhaba
log dosyalarýnýn yani ldf in mdf den büyük olmasý gayet normal zaten belli
bir zaman sonra ldf mdf i geçmediyse ldf'in çalýþmasýnda bir sorun var
demektir. ldf dosyasý mdf üzerinde yapýlan her deðiþikliðin kaydýný tutar
yani mdf üzerinde yapýlan her kayýt ekleme, silme düzenleme ldf üzerinde
tarih saat olarak nerede yapýldýðýna dair gibi kayýtlar tutulur. örneðin mdf
üzerinde 1000 kayýt üzerinde güncelleme yapýlýrsa mdf in boyutunda bir
deðiþiklik olmamasýna raðmen ldf her satýrýn deðiþtiði bilgisini kaydeder ve
böylece ldf dosyasý büyürde büyür bilmem anlatabildim mi, Bu ldf dosyasýný
küçültmenin yolu var tabi eðer full ldf alýnmazsa biraz daha yavaþ büyür ve
database üzerine gelip task'tan shrink denildiði taktirde gereksiz loglar
temizlenir.
Post by mahmut
merhaba;
xxx.ldf dosyasý =37 gb , xxx.mdf dosyasý = 7 gb
anormal bir durum olduðu ortada yazýlýmcý olmadýðým için kendi baþýma bir
çözüm üretemedim arama sitesinden aradým ama biþey çýkmadý
bu durum için ne önerirsiniz
Ayse Uysal
2008-04-07 12:14:55 UTC
Permalink
Shrink, boþluklarý temizliyor, arada boþluklar varsa boþluklarý siliyor,
veriyi kaydýrýyor.
Ben log dosyalarý büyüdüðünde database'i detach ediyorum. Daha sonra log
dosyasýnýn adýný deðiþtiriyorum.
Tekrar attach ederken yeni bir log dosyasý oluþtuyor.
Esli log dosyasýný da ya siliyorum, yada baþka bir yerde saklýyorum Çünkü bu
büyüme zaman zaman diskte yer býrakmayacak kadar artabiliyor

Ýyi Günler
Post by Murat Altay
Burada kafamda oturtamadýðým bir konu var. Recovery mode Full olan bir veri
tabanýnýn Log'unu shrink yaptýðýmýzda logtan geri dönmek sorun olmaz mý.
Logu Shrink yapmak tamamlanmýþ olan transacationlarý silmek anlamýna
gelmiyor mu. Shrink ne yapar tam olarak.
Post by mahmut
merhaba
log dosyalarýnýn yani ldf in mdf den büyük olmasý gayet normal zaten belli
bir zaman sonra ldf mdf i geçmediyse ldf'in çalýþmasýnda bir sorun var
demektir. ldf dosyasý mdf üzerinde yapýlan her deðiþikliðin kaydýný tutar
yani mdf üzerinde yapýlan her kayýt ekleme, silme düzenleme ldf üzerinde
tarih saat olarak nerede yapýldýðýna dair gibi kayýtlar tutulur. örneðin
mdf
Post by mahmut
üzerinde 1000 kayýt üzerinde güncelleme yapýlýrsa mdf in boyutunda bir
deðiþiklik olmamasýna raðmen ldf her satýrýn deðiþtiði bilgisini kaydeder
ve
Post by mahmut
böylece ldf dosyasý büyürde büyür bilmem anlatabildim mi, Bu ldf dosyasýný
küçültmenin yolu var tabi eðer full ldf alýnmazsa biraz daha yavaþ büyür
ve
Post by mahmut
database üzerine gelip task'tan shrink denildiði taktirde gereksiz loglar
temizlenir.
Post by mahmut
merhaba;
xxx.ldf dosyasý =37 gb , xxx.mdf dosyasý = 7 gb
anormal bir durum olduðu ortada yazýlýmcý olmadýðým için kendi baþýma
bir
Post by mahmut
Post by mahmut
çözüm üretemedim arama sitesinden aradým ama biþey çýkmadý
bu durum için ne önerirsiniz
Ayse Uysal
2008-04-07 12:20:53 UTC
Permalink
Bu arada ayný database'e üstüste çok kereler shrink yapmak tavsiye edilen
bir yöntem deðil diye biliyorum
Post by Ayse Uysal
Shrink, boþluklarý temizliyor, arada boþluklar varsa boþluklarý siliyor,
veriyi kaydýrýyor.
Ben log dosyalarý büyüdüðünde database'i detach ediyorum. Daha sonra log
dosyasýnýn adýný deðiþtiriyorum.
Tekrar attach ederken yeni bir log dosyasý oluþtuyor.
Esli log dosyasýný da ya siliyorum, yada baþka bir yerde saklýyorum Çünkü
bu büyüme zaman zaman diskte yer býrakmayacak kadar artabiliyor
Ýyi Günler
Post by Murat Altay
Burada kafamda oturtamadýðým bir konu var. Recovery mode Full olan bir veri
tabanýnýn Log'unu shrink yaptýðýmýzda logtan geri dönmek sorun olmaz mý.
Logu Shrink yapmak tamamlanmýþ olan transacationlarý silmek anlamýna
gelmiyor mu. Shrink ne yapar tam olarak.
Post by mahmut
merhaba
log dosyalarýnýn yani ldf in mdf den büyük olmasý gayet normal zaten belli
bir zaman sonra ldf mdf i geçmediyse ldf'in çalýþmasýnda bir sorun var
demektir. ldf dosyasý mdf üzerinde yapýlan her deðiþikliðin kaydýný tutar
yani mdf üzerinde yapýlan her kayýt ekleme, silme düzenleme ldf üzerinde
tarih saat olarak nerede yapýldýðýna dair gibi kayýtlar tutulur. örneðin
mdf
Post by mahmut
üzerinde 1000 kayýt üzerinde güncelleme yapýlýrsa mdf in boyutunda bir
deðiþiklik olmamasýna raðmen ldf her satýrýn deðiþtiði bilgisini kaydeder
ve
Post by mahmut
böylece ldf dosyasý büyürde büyür bilmem anlatabildim mi, Bu ldf dosyasýný
küçültmenin yolu var tabi eðer full ldf alýnmazsa biraz daha yavaþ büyür
ve
Post by mahmut
database üzerine gelip task'tan shrink denildiði taktirde gereksiz loglar
temizlenir.
Post by mahmut
merhaba;
xxx.ldf dosyasý =37 gb , xxx.mdf dosyasý = 7 gb
anormal bir durum olduðu ortada yazýlýmcý olmadýðým için kendi baþýma
bir
Post by mahmut
Post by mahmut
çözüm üretemedim arama sitesinden aradým ama biþey çýkmadý
bu durum için ne önerirsiniz
Ekrem Önsoy
2008-04-07 17:35:34 UTC
Permalink
Bence bu çok sakıncalı bir yöntem. Veritabanını sürekli ayırıp\iliştirmek
riskli.

Log dosyasını kontrol altında tutmak çok daha kullanışlı bir yöntem.
Transaction Log içerisindeki Aktif Sanal Kayıtları kontrol altında tutup,
zaman zaman da Pasif Sanal Kayıtları Transaction Log Yedeği alarak
temizlemek (ve yerli yersiz Shrink yapmamak) gerekiyor.

Bir çok işlem Transaction Log dosyasına kaydedildiği için elbet büyüyecek,
ama kontrollü olduğu sürece bu büyüme sorun olmaz.
--
Ekrem Önsoy
http://www.ekremonsoy.net , http://ekremonsoy.blogspot.com
MCDBA, MCITP:DBA, MCSD.Net, MCSE, MCBMSP, MCT
Shrink, boşlukları temizliyor, arada boşluklar varsa boşlukları siliyor,
veriyi kaydırıyor.
Ben log dosyaları büyüdüğünde database'i detach ediyorum. Daha sonra log
dosyasının adını değiştiriyorum.
Tekrar attach ederken yeni bir log dosyası oluştuyor.
Esli log dosyasını da ya siliyorum, yada başka bir yerde saklıyorum Çünkü
bu büyüme zaman zaman diskte yer bırakmayacak kadar artabiliyor
İyi Günler
Burada kafamda oturtamadığım bir konu var. Recovery mode Full olan bir
veri
tabanının Log'unu shrink yaptığımızda logtan geri dönmek sorun olmaz mı.
Logu Shrink yapmak tamamlanmış olan transacationları silmek anlamına
gelmiyor mu. Shrink ne yapar tam olarak.
Post by mahmut
merhaba
log dosyalarının yani ldf in mdf den büyük olması gayet normal zaten
belli
bir zaman sonra ldf mdf i geçmediyse ldf'in çalışmasında bir sorun var
demektir. ldf dosyası mdf üzerinde yapılan her değişikliğin kaydını
tutar
yani mdf üzerinde yapılan her kayıt ekleme, silme düzenleme ldf üzerinde
tarih saat olarak nerede yapıldığına dair gibi kayıtlar tutulur. örneğin
mdf
Post by mahmut
üzerinde 1000 kayıt üzerinde güncelleme yapılırsa mdf in boyutunda bir
değişiklik olmamasına rağmen ldf her satırın değiştiği bilgisini
kaydeder
ve
Post by mahmut
böylece ldf dosyası büyürde büyür bilmem anlatabildim mi, Bu ldf
dosyasını
küçültmenin yolu var tabi eğer full ldf alınmazsa biraz daha yavaş büyür
ve
Post by mahmut
database üzerine gelip task'tan shrink denildiği taktirde gereksiz
loglar
temizlenir.
Post by mahmut
merhaba;
xxx.ldf dosyası =37 gb , xxx.mdf dosyası = 7 gb
anormal bir durum olduğu ortada yazılımcı olmadığım için kendi başıma
bir
Post by mahmut
Post by mahmut
çözüm üretemedim arama sitesinden aradım ama bişey çıkmadı
bu durum için ne önerirsiniz
Kadir Çakır
2008-04-17 21:56:57 UTC
Permalink
Recovery Model i Simple yapıp shrink yaptığınızda bir sorun kalmayacaktır.
Zaten benim bildiğim ticari programlar ldf dosyasından bir bilgi okuyup
yazmıyorlar bundan dolayı simple olmasında bir sakınca yoktur. Dediğim gibi
simple yapın ve shrink yapın. Eğer ısrarla ldf bulk logged olarak
kullanmanız gerekiyorsa bence en iyi fikir büyük bir disk alıp mdf ve ldf
dosyalarını ayrı disklerde tutmaktır.

İyi Çalışmalar,
Post by Ekrem Önsoy
Bence bu çok sakıncalı bir yöntem. Veritabanını sürekli ayırıp\iliştirmek
riskli.
Log dosyasını kontrol altında tutmak çok daha kullanışlı bir yöntem.
Transaction Log içerisindeki Aktif Sanal Kayıtları kontrol altında tutup,
zaman zaman da Pasif Sanal Kayıtları Transaction Log Yedeği alarak
temizlemek (ve yerli yersiz Shrink yapmamak) gerekiyor.
Bir çok işlem Transaction Log dosyasına kaydedildiği için elbet büyüyecek,
ama kontrollü olduğu sürece bu büyüme sorun olmaz.
--
Ekrem Önsoy
http://www.ekremonsoy.net , http://ekremonsoy.blogspot.com
MCDBA, MCITP:DBA, MCSD.Net, MCSE, MCBMSP, MCT
Shrink, boşlukları temizliyor, arada boşluklar varsa boşlukları siliyor,
veriyi kaydırıyor.
Ben log dosyaları büyüdüğünde database'i detach ediyorum. Daha sonra log
dosyasının adını değiştiriyorum.
Tekrar attach ederken yeni bir log dosyası oluştuyor.
Esli log dosyasını da ya siliyorum, yada başka bir yerde saklıyorum Çünkü
bu büyüme zaman zaman diskte yer bırakmayacak kadar artabiliyor
İyi Günler
Burada kafamda oturtamadığım bir konu var. Recovery mode Full olan bir
veri
tabanının Log'unu shrink yaptığımızda logtan geri dönmek sorun olmaz mı.
Logu Shrink yapmak tamamlanmış olan transacationları silmek anlamına
gelmiyor mu. Shrink ne yapar tam olarak.
Post by mahmut
merhaba
log dosyalarının yani ldf in mdf den büyük olması gayet normal zaten
belli
bir zaman sonra ldf mdf i geçmediyse ldf'in çalışmasında bir sorun var
demektir. ldf dosyası mdf üzerinde yapılan her değişikliğin kaydını
tutar
yani mdf üzerinde yapılan her kayıt ekleme, silme düzenleme ldf üzerinde
tarih saat olarak nerede yapıldığına dair gibi kayıtlar tutulur. örneğin
mdf
Post by mahmut
üzerinde 1000 kayıt üzerinde güncelleme yapılırsa mdf in boyutunda bir
değişiklik olmamasına rağmen ldf her satırın değiştiği bilgisini
kaydeder
ve
Post by mahmut
böylece ldf dosyası büyürde büyür bilmem anlatabildim mi, Bu ldf
dosyasını
küçültmenin yolu var tabi eğer full ldf alınmazsa biraz daha yavaş büyür
ve
Post by mahmut
database üzerine gelip task'tan shrink denildiği taktirde gereksiz
loglar
temizlenir.
Post by mahmut
merhaba;
xxx.ldf dosyası =37 gb , xxx.mdf dosyası = 7 gb
anormal bir durum olduğu ortada yazılımcı olmadığım için kendi başıma
bir
Post by mahmut
Post by mahmut
çözüm üretemedim arama sitesinden aradım ama bişey çıkmadı
bu durum için ne önerirsiniz
Ekrem Önsoy
2008-04-18 08:09:39 UTC
Permalink
Kesinlikle aynı fikirde değilim. Makalelerimde de sürekli belirttiğim gibi,
üretim ortamlarında ve OLTP yapısındaki veritabanlarında kesinlikle FULL
Recovery Model' ının kullanılmasını tavsiye ederim. Bu konudaki tüm Best
Practices dokümanlarına bakabilirsiniz, hepsi de aynı şeyi söylüyor olacak.
http://www.ekremonsoy.net/makaleler/sql/recovery_models/recovery_models.aspx

Shrink de öyle her akla gelindiğinde yapılacak bir işlem değildir. Doğurduğu
ve doğuracağı sorunları bilebilmek için, Shrink' i bilerek kullanmakta çok
fayda vardır.
http://www.ekremonsoy.net/makaleler/sql/tlog_buyumesi/tlog_buyumesi.aspx

Not:
Gönderilen cevapları soruyu soran kişiye verirseniz daha doğru olacaktır;
eğer cevap veren ile tartışmak istediğiniz bir konu varsa bu başka, ama
görüyorum ki bazı arkadaşlar soru sorana cevap vermesi gerekirken cevap
verene cevap veriyor. Biraz daha dikkatli olursak daha düzenli bir
habergrubu oluşturmuş oluruz.
--
Ekrem Önsoy
http://www.ekremonsoy.net , http://ekremonsoy.blogspot.com
MCDBA, MCITP:DBA, MCSD.Net, MCSE, MCBMSP, MCT
Post by Kadir Çakır
Recovery Model i Simple yapıp shrink yaptığınızda bir sorun kalmayacaktır.
Zaten benim bildiğim ticari programlar ldf dosyasından bir bilgi okuyup
yazmıyorlar bundan dolayı simple olmasında bir sakınca yoktur. Dediğim
gibi simple yapın ve shrink yapın. Eğer ısrarla ldf bulk logged olarak
kullanmanız gerekiyorsa bence en iyi fikir büyük bir disk alıp mdf ve ldf
dosyalarını ayrı disklerde tutmaktır.
İyi Çalışmalar,
Post by Ekrem Önsoy
Bence bu çok sakıncalı bir yöntem. Veritabanını sürekli ayırıp\iliştirmek
riskli.
Log dosyasını kontrol altında tutmak çok daha kullanışlı bir yöntem.
Transaction Log içerisindeki Aktif Sanal Kayıtları kontrol altında tutup,
zaman zaman da Pasif Sanal Kayıtları Transaction Log Yedeği alarak
temizlemek (ve yerli yersiz Shrink yapmamak) gerekiyor.
Bir çok işlem Transaction Log dosyasına kaydedildiği için elbet
büyüyecek, ama kontrollü olduğu sürece bu büyüme sorun olmaz.
--
Ekrem Önsoy
http://www.ekremonsoy.net , http://ekremonsoy.blogspot.com
MCDBA, MCITP:DBA, MCSD.Net, MCSE, MCBMSP, MCT
Shrink, boşlukları temizliyor, arada boşluklar varsa boşlukları siliyor,
veriyi kaydırıyor.
Ben log dosyaları büyüdüğünde database'i detach ediyorum. Daha sonra log
dosyasının adını değiştiriyorum.
Tekrar attach ederken yeni bir log dosyası oluştuyor.
Esli log dosyasını da ya siliyorum, yada başka bir yerde saklıyorum
Çünkü bu büyüme zaman zaman diskte yer bırakmayacak kadar artabiliyor
İyi Günler
Burada kafamda oturtamadığım bir konu var. Recovery mode Full olan bir
veri
tabanının Log'unu shrink yaptığımızda logtan geri dönmek sorun olmaz mı.
Logu Shrink yapmak tamamlanmış olan transacationları silmek anlamına
gelmiyor mu. Shrink ne yapar tam olarak.
Post by mahmut
merhaba
log dosyalarının yani ldf in mdf den büyük olması gayet normal zaten
belli
bir zaman sonra ldf mdf i geçmediyse ldf'in çalışmasında bir sorun var
demektir. ldf dosyası mdf üzerinde yapılan her değişikliğin kaydını
tutar
yani mdf üzerinde yapılan her kayıt ekleme, silme düzenleme ldf üzerinde
tarih saat olarak nerede yapıldığına dair gibi kayıtlar tutulur. örneğin
mdf
Post by mahmut
üzerinde 1000 kayıt üzerinde güncelleme yapılırsa mdf in boyutunda bir
değişiklik olmamasına rağmen ldf her satırın değiştiği bilgisini
kaydeder
ve
Post by mahmut
böylece ldf dosyası büyürde büyür bilmem anlatabildim mi, Bu ldf
dosyasını
küçültmenin yolu var tabi eğer full ldf alınmazsa biraz daha yavaş büyür
ve
Post by mahmut
database üzerine gelip task'tan shrink denildiği taktirde gereksiz
loglar
temizlenir.
Post by mahmut
merhaba;
xxx.ldf dosyası =37 gb , xxx.mdf dosyası = 7 gb
anormal bir durum olduğu ortada yazılımcı olmadığım için kendi başıma
bir
Post by mahmut
Post by mahmut
çözüm üretemedim arama sitesinden aradım ama bişey çıkmadı
bu durum için ne önerirsiniz
HÝLMÝ
2008-04-18 06:34:29 UTC
Permalink
Logdan geri dönülmüyorki zaten sadece bacuptan geri dönülüyor benim
bilgidiðim kadarýyla, log sadece bir sorun çýktýðý zaman yani yanlýþ bir
kayýt yapýlmýþ felan bu kayýt hani saatte yapýlmýþ gibi sorunlarý çözmek
için log tutuluyor daha doðrusu iþte þu databasenin þu tablosuna hangi sql
kullanýcýsý hangi saatte nasýl bir kayýt atmýþ. Logdan geri dönmek için
baþka programlar kullanýlýyor onlarda da fazla trasacation olmamasý lazým.
Post by Murat Altay
Burada kafamda oturtamadýðým bir konu var. Recovery mode Full olan bir veri
tabanýnýn Log'unu shrink yaptýðýmýzda logtan geri dönmek sorun olmaz mý.
Logu Shrink yapmak tamamlanmýþ olan transacationlarý silmek anlamýna
gelmiyor mu. Shrink ne yapar tam olarak.
Post by mahmut
merhaba
log dosyalarýnýn yani ldf in mdf den büyük olmasý gayet normal zaten belli
bir zaman sonra ldf mdf i geçmediyse ldf'in çalýþmasýnda bir sorun var
demektir. ldf dosyasý mdf üzerinde yapýlan her deðiþikliðin kaydýný tutar
yani mdf üzerinde yapýlan her kayýt ekleme, silme düzenleme ldf üzerinde
tarih saat olarak nerede yapýldýðýna dair gibi kayýtlar tutulur. örneðin
mdf
Post by mahmut
üzerinde 1000 kayýt üzerinde güncelleme yapýlýrsa mdf in boyutunda bir
deðiþiklik olmamasýna raðmen ldf her satýrýn deðiþtiði bilgisini kaydeder
ve
Post by mahmut
böylece ldf dosyasý büyürde büyür bilmem anlatabildim mi, Bu ldf dosyasýný
küçültmenin yolu var tabi eðer full ldf alýnmazsa biraz daha yavaþ büyür
ve
Post by mahmut
database üzerine gelip task'tan shrink denildiði taktirde gereksiz loglar
temizlenir.
Post by mahmut
merhaba;
xxx.ldf dosyasý =37 gb , xxx.mdf dosyasý = 7 gb
anormal bir durum olduðu ortada yazýlýmcý olmadýðým için kendi baþýma
bir
Post by mahmut
Post by mahmut
çözüm üretemedim arama sitesinden aradým ama biþey çýkmadý
bu durum için ne önerirsiniz
Ekrem Önsoy
2008-04-18 08:15:50 UTC
Permalink
Hayır Hilmi, burada yanlış olduğunu söylemem gerekiyor.

Veritabanın "Suspect" duruma geldiğinde ve bunu kurtarmak için hiç bir şey
yapamadığında ne olacak? Son Full \ Differential yedeğinden mi geri
döneceksin? Peki ya son aldığın yedekten sonra girilen veriler ne olacak?
İşte bu noktada veritabanını Emergency Mode' a sokabilir ve Transaction Log'
un yedeğini (Tail Log) alıp, Son tam \ fark yedeğini açtıktan sonra bunun
üstüne Tail Log yedeğini açabilirsin. Böylece en küçük miktarda veri kaybına
uğramış olur veya hiç veri kaybına uğramamış olursun.

Üretim ortamları için Full Recovery Model (tekrar vurguluyorum, özellikle
OLTP için) ölümcül derecede önemlidir.

Ayrıca, SIMPLE Recovery Model' da Transaction Log' un yedeği alınamaz.
Özellikle büyük şirketlerde veri kaybı toleransı sıfırdır. Veri kaybının
olasılığını en aza indirgemek için Transaction Log yedeklerini kullanırız.
Aksi takdirde, elindeki veri yedeği sadece en son aldığın FULL ve
DIFFERENTIAL yedekler kadar yenidir. Bu da genelde günde bir kere olur, yani
bu durumda 48 saatlik verini kaybetme olasılığın söz konusudur.

Veri güvenliği bir Veritabanı Yöneticisinin en öncelikli işidir. Bu nedenle
atılan adımların çok dikkatli, temkinli ve doğru atılması önemlidir.
--
Ekrem Önsoy
http://www.ekremonsoy.net , http://ekremonsoy.blogspot.com
MCDBA, MCITP:DBA, MCSD.Net, MCSE, MCBMSP, MCT
Post by HÝLMÝ
Logdan geri dönülmüyorki zaten sadece bacuptan geri dönülüyor benim
bilgidiğim kadarıyla, log sadece bir sorun çıktığı zaman yani yanlış bir
kayıt yapılmış felan bu kayıt hani saatte yapılmış gibi sorunları çözmek
için log tutuluyor daha doğrusu işte şu databasenin şu tablosuna hangi sql
kullanıcısı hangi saatte nasıl bir kayıt atmış. Logdan geri dönmek için
başka programlar kullanılıyor onlarda da fazla trasacation olmaması lazım.
Burada kafamda oturtamadığım bir konu var. Recovery mode Full olan bir
veri
tabanının Log'unu shrink yaptığımızda logtan geri dönmek sorun olmaz mı.
Logu Shrink yapmak tamamlanmış olan transacationları silmek anlamına
gelmiyor mu. Shrink ne yapar tam olarak.
Post by mahmut
merhaba
log dosyalarının yani ldf in mdf den büyük olması gayet normal zaten
belli
bir zaman sonra ldf mdf i geçmediyse ldf'in çalışmasında bir sorun var
demektir. ldf dosyası mdf üzerinde yapılan her değişikliğin kaydını
tutar
yani mdf üzerinde yapılan her kayıt ekleme, silme düzenleme ldf üzerinde
tarih saat olarak nerede yapıldığına dair gibi kayıtlar tutulur. örneğin
mdf
Post by mahmut
üzerinde 1000 kayıt üzerinde güncelleme yapılırsa mdf in boyutunda bir
değişiklik olmamasına rağmen ldf her satırın değiştiği bilgisini
kaydeder
ve
Post by mahmut
böylece ldf dosyası büyürde büyür bilmem anlatabildim mi, Bu ldf
dosyasını
küçültmenin yolu var tabi eğer full ldf alınmazsa biraz daha yavaş büyür
ve
Post by mahmut
database üzerine gelip task'tan shrink denildiği taktirde gereksiz
loglar
temizlenir.
Post by mahmut
merhaba;
xxx.ldf dosyası =37 gb , xxx.mdf dosyası = 7 gb
anormal bir durum olduğu ortada yazılımcı olmadığım için kendi başıma
bir
Post by mahmut
Post by mahmut
çözüm üretemedim arama sitesinden aradım ama bişey çıkmadı
bu durum için ne önerirsiniz
Loading...