Forum
Bildirimler
Hepsini Temizle
SQL Server
3
Yazılar
3
Üyeler
3
Likes
1,502
Görüntüleme
Konu başlatıcı
Arkadaşlar selam. Forumda Shrink işlemi ile ilgili bir kaç yazı vardı inceledim. Fakat isabetli bir çıkarım yapamadım. SQL yapısına çok hakim birisi değilim fakat, bir mdf dosyasının boyutu 466mb iken bu dosyanın ldf uzantılı log dosyası 9.5gb olabiliyor. Gün içinde 45-50 kullanıcının bağlanıp veri giriş çıkışı yaptığı bu veri yapılarında manuel olarak shrink işlemi uygulanması ve ardından ilgili veritabanlarına defrag yapılması bize ne kazandırır ne kaybettirir? Shrink işleminden sonra veri yapılarındaki parçalanma yüzdelerinin normalden çok fazla olduğu konusunda bir çok yazı var. Shrink işlemi ardından söz konusu veri tabanına defrag uygulandığında bu meydana gelen parçalanma normal düzeylere indirilemiyormu ? Aynı zamanda bu konuda yaptığım araştırmalarda gördüğüm şey şu ki, Mikro, Netsis, Logo vb. uygulamalar ile sistem kuran çözüm ortakları oluşturulan veritabanlarına bırakın shrink ve defrag gibi işlemleri, veritabanının recovery modelini dahi olduğu gibi bırakıp ellemiyorlar. Çalışan bir sistemin hiç ellenmemesi gibi bir gelenek var galiba. Konu hakkında yardımlarınızı, fikirlerinizi beklerim. İyi çalışmalar.
Gönderildi : 30/01/2022 23:12
https://www.brentozar.com/archive/2017/12/whats-bad-shrinking-databases-dbcc-shrinkdatabase/
https://straightpathsql.com/archives/2009/01/dont-touch-that-shrink-button/
Sorunuz biraz detaylı bir konu bu tip analizleri okuyabilirsiniz. Temel anlayış farkı DB yapılarının disk tablo yapılarından farklı olmasında yatıyor. Merak halinde bunların detay araştırılması yerinde olur. Benzer durum ve önerileri bu tip uygulamaların best practice altında da görebilirsiniz.
Backup ve loging konusunda ise bu tip çalışmalara bakabilirsiniz.
https://www.sqlshack.com/sql-server-transaction-log-architecture/
https://www.sqlshack.com/sql-server-transaction-log-administration-best-practices/
'balık vermez, nasıl tutulabildiğine yönlendirir'
****************************************************************
Probleminiz Çözüldüğünde Sonucu Burada Paylaşırsanız. Sizde Aynı Problemi Yaşayanlar İçin Yardım Etmiş Olursunuz. Eğer sorununuz çözüldü ise lütfen "çözüldü" olarak işaretlerseniz diğer üyeler için çok büyük kolaylık sağlayacaktır.
*****************************************************************
Gönderildi : 31/01/2022 12:35
Merhabalar,
Şöyle bir açıklama ile başlayayım.
MSSQL'de şöyle bir yapı var. Her bir db için bir mdf ve bir ldf dosyası bulunur.
MDF dosyası datanın kendisini tutarken, ldf bu data için yapılan transactionları tutar.
Kaba tabirle şöyle.
Musteriler isimli bir tablomuz olsun.
Insert into musteriler (Id,musteriadi) values (1,'ömer çolakoğlu') cümlesinin çalıştırıldığını düşünelim.
data olarak kaplanan yer integer bir alan için yaklaşık 4 byte musteriadi için ortalama 20 harf desek 20 byte=24 byte.
Bu işlem 1000.000 kez gerçekleşirse bu tablonun boyutu 24x1.000.000=yaklaşık 24 MB
Fakat log kısmında bu işlemin transaction bilgisi tutulur. Kaba tabirle sql cümlesi bilgisi diyebiliriz.
Yani bir kayıt eklemek için datanın kendisi 24 byte iken transaction bilgisi 200 byte tutabilir.
Yani log dosyasının şişmesinin sebeplerinden biri budur.
Diğer taraftan
Update musteriler set status=0 dediğimizde 1.000.000 satır için değişiklik yapılır ve bu datayı büyütmez.
Ama log dosyasını 1 milyon işlem kadar büyütür.
Delete from musteriler dedin tablodan kayıt sildin log yine bu tablo boyutu kadar büyür.
Burada log dosyasının bu kadar detaylı içerik tutmasının sebebi herhangi bir sıkıntıda istenilen saniyeye dönebilmektir.
Tabi burada olumsuz olan durum log dosyasının sürekli büyümesidir.
Bunu önlemenin iki yolu var.
Bir, transaction log backup alarak log dosyasını küçültmek.
İki,DB recovery modeli full modda tutmadan simple modda tutmak. Böylece transaction log dosyasının sürekli büyümesinin önüne geçmek. Tabi bu noktada full mode un avantajı tlog üzerinden istediğin saniyeye kadar backuptan dönebilirken simple mode da sadece full ya da diff yedek aldığın zamana dönebilmek.
Ama çok mission critical durumlarınz yoksa ben şahsen günde 2-4 kez full ve yarım saatte bir differential backup almanızı tavsiye ederim.
Recovery model full olmadığı zaman tlog un böyle absürt büyümeleri ile karşılaşmazsınız. Performanslı da çalışır.
Çok büyüyünce de manuel shrink yapmak yeterlidir.
Backup ile alakalı bu makalelere bakmanı tavsiye ederim.
https://www.cozumpark.com/sql-serverda-backup-stratejileri-4-transaction-log-backup/
Umarım anlatabilmişimdir.
Gönderildi : 31/01/2022 17:17
