Firebird de ince ayar nasıl yapılmalı?

[try]

Selamlar,

Kullanmakta olduğumuz program 4 GB ı aşkın bir DB oluşturdu. Firebird 1.5 kullanmak zorundayız bu arada. (malesef 2.0 a veya 3.0 a şu an için geçemiyoruz) conf dosyasına baktım. hiçbir düzenleme yok. Varsayılan neyse o.

Sorunumuz ise eğer günde bir bakım yapılmazsa sistemimiz yerlerde sürünüyor.

her gece saat 3-4 arası bakım yapıyoruz. önce gfix ile mevcut bağlantıları düşürüyoruz. (çünkü bu database aynı zamanda web sitesi ile entegre çalışıyor)

ardından gbak ile yedek alıyoruz. sonra bu yedeği tekrar açıyoruz. bağlantıları tekrar açıyoruz. (yaklaşık sabaha karşı 1 saat uykusuz kalıyoruz)

böylece bakım yapılmış oluyor. Ama bu bence çok yanlış. yani 3 günde bir bakım yapılması gerekmemeli. acaba conf dosyasıyla ilgili bir düzenleme yapmam gerekir mi?

Bu düzenlemeleri yaparsam bu bakım işinden kurtulur muyum?

Server özelliklerine gelince:
4 gb ddr2 bellek
3 scsi disk (raid 5)
2 x Xeon 3.2 Ghz
windows 2003
firebird 1.5 kurulu (ama kurulu sistem superserver mı yoksa classic mi emin değilim)

CHKDSK ile ayırma birimlerinde 4096 bayt kullanılıyormuş, ayrıca DB oluşturulurken 8192 pagesize verilmiş.

Ayrıca kullandığımız yazılımın da bunu yapıyor olma ihtimali var elbette.(hatta kuvvetle muhtemel yazılımımızdan oluyor) Ama yazılımı ben yapmadığım için neden kaynaklandığını anlayamıyorum. Hatta belki alınan bir rapor bile sistemi tıkıyor olabilir. Eğer sistemi neyin tıkadığını bulabilsem bu bile bir gelişme olabilir tabi.

Acaba konfigürasyon dosyasında değişiklik yaparak sistemi kasan işlemlerin belirli bir süre sonunda kapatılmasını sağlama şansım var mı?

Sistemin kasılmasının neden olduğunu bulma şansım var mı?

Bağlantılarda program içerisinden timeout olmasa bile server ın o bağlantıyı kesmesini sağlamam mümkün mü?

[aslangeri]

forumda conf dosyasındaki ayarların ne işe yaradığı konusunda bilgiler mevcut onları incelerseniz faydalanabilirsiniz.
kolay gelsin.

[rsimsek]

Soru bir makaleye konu olabilecek detaylı bir soru olmuş. Elde sıfır bilgi ile gerçekten bir şey söylemek zor. Nasıl bir veri tabanı Tablo yapıları nasıldır İndeksler nasıl yapılandırılmış Arama yapılan alanlar indekslenmiş mi Stored Procedure ler ne şekildedir, yani birbirlerini çağırıyorlar mı Kaç kullanıcı ne yoğunlukta erişiyor vb. sorulara cevap verdikçe çözüme yaklaşmanız kolaylaşacaktır. Ayrıca duyup da paylaştığım gibi disk perfomansı için birim küme (cluster size) boyutunun mümkün olduğunca yüksek olması disk erişim hızını artıracaktır. Bu sebeple birim küme boyutundan küçük dosyalardan dolayı ihmal edilebilecek bir miktar disk kapasitesi kaybı olacaktır. Günümüz devasa boyutları için bu ihmal edilebilir. Birebir yedekleme yapılıp partititon magic gibi programlarla küme boyu artırılabilir. Tabi diske bağlı bir dar boğaz varsa. Ayrıca ilk başta yapılması gerekenlerden biri de veritabanı pagesize ının bu küme boyutunda seçilmesi (örn. 16K=16384 Bayt).
Kısaca öneride bulunmak için biraz daha fazla bilgiye ihtiyaç olacak

[try]

1093 adet domain
341 adet table
322 adet view
370 adet procedure
1752 adet trigger
336 adet generator
158 UDF
891 adet index

mevcut. sorunu bakarak bulmak biraz zor olacak gibi. Benim amacım bunun yerine server ı yoran işlemi öldürmenin yolunu bulmak. Yada sistemi yoran işlemi bulmanın en kolay yolu nedir?

[try]

ayrıca bir diğer merak ettiğim nokta bir database in yedeğini alıp o yedeği tekrar geri dönmek gerçekten bir performans artışı sağlar mı? Yani firebird ün buna gerçekten ihtiyacı var mı?

[rsimsek]

Tasarım ve yapıları bilmeden bu bilgiler de fazla bir şey ifade etmeyecektir. Orta ölçek üzeri bir sistem olduğu ortada fakat sizin kurduğunuz tasarımın en verimli olması diğer yan etkilerin etkisini zaten en az hissedilecek hale getirecektir. Yedekleyip geri almak sadece çöp/garbage lerin ayıklanmasından başka birşey değildir. O da kayıt değişikliği, kayıt silme vs den dolayı gerçekte o kayıtlar ilk etapta veri tabanından silinmeyip indekslerden çıkartılır veya silindiklerine dair işaret konur (tam detayını bilmiyorum) onların elenmesini sağlar

[try]

o halde tüm konfigürasyon ayarlarını tekrar yapılandıracağım. ilginiz için teşekkür ederim.

[doganzorlu]

Selam,

Ben sunucularımı hiç kendi başına bırakmam hep izlerim. Siz de böyle yapmalısınız. Peki nasıl ? Ben Linux makinalarda mrtg yi kullanıyorum. Birkaç küçük betikle destekleyince çok verimli oluyor. Günlük, haftalık ve aylık olarak sunucunun;

CPU Yüklemesini
IO Yüklemesini
Dışardan yapılmış olan bağlantılarını
Disk boyutunu
Ağ kullanım miktarını

grafik olarak izliyorum. Herhangi bir darboğaz olduğunda bunun olduğu zamanları karşılaştırıyorum ve bir frekans bulmaya çalışıyorum. Eğer içerdeki SQL ler ya da uygulama içindeki bir takım iterasyonlar değilse sorun %99 neyin sorun olduğunu bulabiliyorum. FB de nasıl olur bilmiyorum ama Progress ve Oracle da db leri de bu listeye ekleyip, bağlantı sayılarını max buffer hit bilgisini de grafik olarak izliyorum. (Progress le çalışmıyorum artık). Eğer utilizasyonu çok yükselmiş bir tablo mevcutsa o tabloda eksik olabilecek ve fullscan taramaya sebep olabilecek index leri düzenliyordum.

Bir sistem yöneticisi ya da dba için bu bilgiler problemlerin çözümünde çok işe yarıyor.

Siz de sisteminizi buna benzer şekilde izlemelisiniz ve anlık olmayıp bir grafik üzerinde zamana göre değişimlere bakmalısınız.

Darboğazı bulduktan sonra bir tedbir alabilirsiniz aksi takdirde ne yaptığınızı bilemezsiniz.

Kolay gelsin,

[try]

bunu windowsta ve firebird kurulu bir sistemde yapmanın da bir yolu var aslında ama malesef bahsettiğiniz gibi grafiksel olarak değil process id (pid) ile cpu kullanımından anlaşılabiliyor.

Ama işin kötü bir tarafı da sistemimizin yerlerde süründüğü zamanlarda cpu kullanımının normal olması gibi bir durum var.

acaba bir bağlantının sistemi yorması durumunda windowsun refleks olarak o process i düşürmesi mümkün mü, yada çok uzun süre bağlı kalan bir işlemin kapatılması...

kolay gelsin.

[mussimsek]

Windows 2003 ile ilgili daha önce de garip sıkıntılar geldi. Süreci bilmiyorum ama XP makina üzerine DB'yi taşıyıp, denemeyi düşündünüz mü? Eski makina aynen kalsın, yeni bir makina hazırlayıp bir deneyin.

Kolay gelsin.

[try]

biraz riskli olsa da denemeye çalışacağım. gerçi sunucunun update lerini günlük yapıyoruz ama belki sorun henüz microsoft tarafından anlaşılamamış da olabilir tabi.

teşekkürler