database çok hızlı büyümeye başladı.

[meron06]

sel.al.arkadaşlar.firebird 2.0.1 database kullanılan bi projem var.dün programın çok yavaşladığı şikayeti ile müşteriye gittim.databasein boyutu 1548 mb tı.disk te boş yer kalmamıştı.eski yedekleri silip diskte 20 gb kadar boş alan açtım.daha sonra yedek aldım .normalde 15 dakikada biten yedek tam 45 dakika sürdü.daha sonra almış olduğum yedeği yeniden restore yaptım.normal hızda restoresini yaptı daha sonra yeniden yedek aldığımda ise 15 dakikada bitti.restore işlemi sonunda database boyutu 1254 mb a düştü.bugun sabah kontrol ettiğimde database boyutu 1301 mb olmuştu.üstelik gece programa kayıt girilmiyor.yani 3 saat lik bir kayıt sonucu database in 47 mb büyümesi normalmidir.az önce baktım database boyutu 1302 mb olmuş bi sıkıntı var sanki böyle bi durumla karşılaşan arkadaşlar varmı.

[aslangeri]

s.a.
tabloların yapısı nasıl ki?

[meron06]

aslangeri kardeş daha önce yedek alıp restore etmeden önce günlük 3-4mb büyüyordu tablo.şimdi ise son 1 saat içinde 4 mb daha büyüdü.bugun girilen kayıt sayısı diğer günlerin yarısı kadar bile deyil.

[serkan]

evet bu tür şeyler oluyor database'in boyutu çok önemli değil tablo yapılarını düzgün kurduysan tabi.sebebine gelince ben pagesize olayından şüpeleniyorum..gdb dosyası 1024'lük hücreyi doldurduktan sonra sen bir stok kartı bile girsen diğer 1024 lük hücreye geçiyor teknik olarak ayrıntısını bilmiyorum kabaca böle bişey.dosya sistemi yapısından deyip geçelim .. backup/restore dendiğinde dosya boyutu küçülüyor yani aslında gdb dosyasının boyutu içinde o kadar veri olduğunu göstermez diskde kapladığı alan o kadar buda tamamen hdd nin cluster yapısı ile ilgili.

[meron06]

serkan kardeş resotore işlemindmen önce günlük 3-4 mb olarak büyüyordu.database de herhangi bi değişiklik yapmadım .aynı server.sadece restore yaptım.page size da aynı.anlamadığım daha önce 3-4 mb büyüyen data şimdi neden bi kaç saat içinde 60 mb büyüdüğü ve halada büyümeye devam ediyor.

[serkan]

hmm nasıl desem bende şimdi elimde 116 MB'LIK müşterinin datası vardı demo sürüm için içindeki bilgileri boşalttım bacup/restore yaptım 2,35 MB'ta düştü.sonra boş datadan açıp stokgrupları tablosuna (2 field var GRUPADI,GRUPKODU) 3 adet kayıt girdim.dosya boyutu 4,2'ye yükseldi.3 tane kayıt 2 MB'yer kaplamıyor tabiki.Samanlıktaki samanların kapladığı alanları değil samanlığın alanını verdiği için gdb dosyasının boyutu doğru yorum yapamıyoruz.Bunu bir arkadaşım üşenmemiş yapmıştı öyle bir durumda harddiski değiştirmişti aşırı boyut artışı düzelmişti.sende değiştir demiyorum ama dosya sistemi yapısı ve dosyaların HDD üzerindeki fiziksel olarak kaydedilme durumu ile ilgili olmasından kaynaklandığını açıklıyor,disk birleştiricide hdd nin iç durumunu gösteriyor onu hayal et
windows'unkine güvenmiyorum 3.parti bir disk birleştirici ile diski birleştirip deneyebilirsin madem 20 gb bilgi sildin kim bilir ne hale gelmiştir dosya yapısı onunda etkisi vardır.

[mkysoft]

Benim aklıma, programınızda veri tabanına blob olarak resim veya dosya kaydediyor olabileceğiniz geldi. Son günlerde ürün resimleri gibi birşeyler ekleyip siliyorlarsa database daha çabuk şişebilir. bakup/restore yapınca silinen kayıtlar tamamen atılıyor bu nedenlede küçülüyor.

[meron06]

mkysoft hocam projemde resim yada blob alan kaydı yapılan bi bölümün yok .kullanıcıların girdiği kayıtlar standart kayıtlar.yalnız veritabanında 2000 karakterlik bi kaç tane varchar alanım var ama bu tablolara öyle çok kayıt girlmedi kontrol ettin 423 adet kayıt girilmiş.bu tabloya.pagesize ım 8192 .

[undefined]

Aklıma gelen bir olasılık;
Eğer transactionlar hep commitretaining şeklinde uzun süre devam ediyorsa bu record versiyon datalarının silinmemesine sebep olur buda dbyi büyütür.
Bunun için sweep interval'i ayarlaman yardımcı olabilir, zaten ayarılıysada sweep interval değerini düşür. Default değer 20.000.

Dolma noktasına gelmiş harddisklerde fragmantasyon kaçınılmaz oluyor, bide pagefile.sys ve hiberfil.sys çok fragmante olmuşsa defrag buna el süremiyor, ve bunların dağınıklığıda diğer büyüyen dosyalarıda bölüyor. (Tecrübeyle sabittir)

Edit : transactionlar hep aktifse sweep bir işe yaramıyormuş. Bu yüzden DB'ye kimse bağlı değilken manual olarak yapılması asıl etkiyi gösteriyormuş yazıyor burda :
http://www.ibphoenix.com/main.nfs?a=ibp ... ge=ibp_oit (en sonda)
(Ayrıca DB'nin bahsettiğim şekilde büyümesi, çok transactionlı, çok işlem yapılan bir server için geçerli. )

[meron06]

undefined kardeş transactionlarım hep commit olarak kullanıyorum.

[Hakan Can]

UPDATE ve DELETE işlemleri de INSERT işlemi gibi veritabanını büyültüyor.

Bilhassa bu ilk iki işlemin ne kadar yapıldığını takip etmende fayda var.

Trigger'larda bu iki komutu kullanıyor olabilirsin. Yani bir kayıtlık bir işlem belki de perde gerisinde (Trigger) binlerce kaydı değiştiriyor veya siliyor olabilir.

Veya program içinden de bu işlemler yapılıyor olabilir.

Örneğin özel bir tablo oluşturup bu tabloda bu işlemlerin tablo bazlı miktarlarını tutabilirsin. Ve sadece bu tablodan veritabanında ne olup ne bittiğini takip edebilirsin.

[Kuri_YJ]

Selamlar,

firebird.conf dosyasında (Firebird'ün kurulu olduğu dizinde vardır) yapılacak birkaç küçük ayarlama ile performansınızı arttırabilirsiniz. Örneğin CachedPage gibi. Bunların dışında FB'nin yapısında, kayıt silme diye bir şey yoktur. Kaydı silersiniz ama sadece FB gider o kaydın üzerine silindi diye işaret koyar. Backup Restore sırasında sweep işlemi de yaptırabilirsiniz, yani silinmiş olan kayıtları gerçekten DB'den çıkarabilirsiniz.

Bunları deneyin ondan sonra esas önemli nokta olan, Tablo Yapılarınız ve indekslerinize bakmak gerek. Sorgularınızda kullandığınız indeksler düzgün ise, milyonlarca kaydınız bile olsa performans sıkıntısı yaşamazsınız.

Şunu unutmayın, DB sadece bir havuz, gölet, deniz gibi bir yığındır. Performansı genelde sizin o su birikintisinden aldığınız miktar ilgilendirir. Eğer siz bir havuzdan kovayla su çekerseniz farklı, bardakla çekerseniz farklı performans elde edersiniz.

Genelde de karıştırılan bu olmaktadır. Bazı arkadaşlar bütün kayıtları çekmek gibi bir hataya düşüyorlar, hayır bu noktada sadece lazım olan veriyi lazım olduğu anda çekmek, performansınızı oldukça arttırır. Hatta doğru indekslerle kurulmuş olan bir sorgu ile anında yanıt alırsınız.

Kolay Gelsin

Not : Ancak sorun diye kasdettiğiniz DB'nin büyümesi olayı ise, o bir problem değil, pagesize'lar ile ilgili olur ve Defragmantasyon ister (Windows için)

[meron06]

kuri kardeş cachedpage olayını biraz anlatabilirmisin .firebird.conf dosyası ile ilgili dökümanlar da yeteri kadar açıklama bulamadım.çok konu var ama .yeterli deyil .kuri kardeş firebird.conf dosyasında ne gibi ayarlamalar yapıyorsunuz performans için .

[Kuri_YJ]

Selamlar,

Forumumuzda bu konu ile ilgili baya yazıldı çizildi,

viewtopic.php?t=12939&highlight=

derli toplu halde olanlardan birisi yukarıda verdiğim link.

Kolay Gelsin

[ikutluay]

merhaba

buna benzer birşey logo da başımıza gelmişti. tabii o sql server ama sonuçta bunların hepsi rdbms. mantıkları nispeten aynı yani..

bizim yaptığımız şey ise databasei devre dışına alıp transaction logları silip database in büyüme oranını %10 gibi sabit bir orandan alıp fix bir değere eşitlememizdi. transaction loguda fixlemiştik.

disk defrag hız olayına gelince bu konuda ihtisas yaptım denebilir. olay şuki harddiskler byte byte değilde sektör sektör bölünmekte. bir sektörde 512 byte. yanyana sektörler bir cluster olarak adlandırılır. unixlerde dosyalar 512 bytlık clusterlarda dururken windows ve dos tarzı sistemlerde boyuta göre belirlenen cluster boyutunda kullanılır. Örneğin içine tek bir harf bile yazsan bile windowsta bazı dosyalar 32 yada 64 kb yer kaplayabilir. yani, bazen küçük dosyalardan oluşan bir klasör sildiğinizde siz 2 mb dosya silmişsinizdir ama boş alan mikarı 10 mb artabilir. sebebi işte bu cluster düzeneğidir.

windowslarda dosyalar fat yada yeni 2000 serisi için MFT adı verilen tablolarda tutulmaktalar. dosya silindiğinde sadece adının ilk harfi ? işareti yapılıyor. bildiğiniz gibi isimlerde soru işareti kullanılmadığından bu dosya silinmiş varsayılıyor. windows bir dosyanın kaydına alanı ekonomik kullanmak için bu boş alanları dahil ediyor. boş alan çok parça ise dosyada bir çok parçaya bölünerek yazılıyor. haliyle buda yavaşlama demek. defrag denenşeyde bu parçaları ucuca eklemek sadece.

son olarak beleşi bir program öneriyorum. universal defrag sourceforgedan indirebilirsiniz.