Fire bird hakkında

YouTube · Mesaj gönderen **Kuri_YJ** » 03 Mar 2004 09:20

Selamlar,

UPS'siz ve Backup'sız bir sistemle çalışmak demek, peşin peşin bütün riskleri göze almak demektir. Freni tutmayan arabaya biner misiniz?

Kolay Gelsin.

Mesaj gönderen **freeman35** » 03 Mar 2004 09:48

walla ben 7-8 yıl oldu galiba IB 5x ti galiba başlıyalı. ogünden beri sadece 2 kez karşılaştım elektrik kesilmesinden çıkan bozukluk. Müşterilerime şiddetle UPS öneriyorum. Ve programların hepsinde main application kapanırken ekrana Yedek almayı unutmayınız diye mesaj verdirtiyorum. Bu sorumluluğu benim üzerimden alıyor ve ayrıcada kullanıcıya hatırlatma yapıyor. Ayrıcada yedek programı yazdım

ufak bir proje değilse bu yedek alma modülünüde programın içerisine koyuyorum. Her seferindede kullanıcıya söylüyorum, yedek al eğer bilgilerin uçarsa kurtaramayabilirim, sorumlusuda sensin. ben sana yedek alman için programda yaptım diyorum. tabi bu çözüm değil.

@name sanırım senin yazılımdan kaynaklanan bir şey olabilir. Tahminim transection lar açık kalıyor. bu güne kadar gözlemlediklerim eğer transection lar açıksa db de bozulma ihtimali daha da yükseliyor. Bu düzeltme içinde lck dosyasını silip makinayı bir açıp kapatmak db yi kurtarabiliyor ama en son yazılan kayıtlar yani transection içindeki bilgiler kayboluyor.

Bir diğer öneride NTFS kullanın fat den daha güvenilirdir. veri kaybınız daha az olacaktır.
bir başkasıda @sair in dediği gibi shadow ama bunu aynı disk üzerinde değilde ikinci bir disk(fiziksel olarak) üzerinde yapmak daha güvenilir olacaktır.

Kolay gele

Mesaj gönderen **name** » 03 Mar 2004 07:38

İyi çalışmalar

Böyle bir kanı oluşmadı ama öncelikle yeni bir database arayışı içinde olmadığımı belirteyim. Çünkü Firebird ile rahatlıkla daha az maliyetli ve rekabet gücü daha yüksek yazılımlar yapılabilir.

Benim aslında vurgulamak istediğim database bozulmalarının (data kayıpları değil) nasıl önlenebiliceği değil, FB/IB gibi geliştirilmeleri büyük bir hız ile devam eden, ileri programcılık teknikleri kullanılarak yazılmış veritabanı yönetim yazılımlarının bu tip olaylardan ne kadar kolay etkilenebildiğine değinmekti. Tabiiki müşterilerimize şiddetli bir şekilde ups kullanmalarını ve yedek almalarını öneriyoruz. Bize düşende, freeman35'in dediği gibi yaptığımız programda kullanıcıya hissetirmeden bu yedek işlemlerini almak olabilir. Mesala windows işletim sistemlerinin mantığı gibi eğer program olumsuz bir şekilde sonlandı ise en son yedek alınan data dosyasına geri dönülebilir (ufak ölçekli veri yapılarında tabiiki). Yani böyle bir olayı minimuma indirmek için yapılacaklar çok.

Ayrıca, sadece elektrik kesilmelerinden değil, programda çalışırken bilgisayar kilitlenir ise böyle bir bozulma yine oluşabiliyor. Birde kullanıcı tarafından olaya bakmak gerekiyor bence. Mesala müşteri, bana görede biraz haklılık payı olan şu soruyu soruyor: "Sizin programda olduğu gibi muhasebe programımdada (eta for windows,lks2 gibi) aynı bozulmanın olması gerekmez mi?"

Yanlış düşünüyor olabilirim ama düşüncelerim bunlar.

Mesaj gönderen **mussimsek** » 04 Mar 2004 09:05

Merhaba,

bence müşterinin şunu anlaması lazım. Tüm veritabanlarında bozulma ihtimali var, özellikle elektrik kesintisinde. Bu durumda yapılacak olayda yedekten geri dönmek olacağı için, yedek almaya önem vermeli.

Logo vs.'in bozulmadığını kim söyledi. Daha geçen ay bizim muhasebeciler işlem yaparken bozuldu veritabanı. Gerçi daha çok diskle alakalı bir problemdi ama onlar da bozulabiliyor yani. Yedeklerden geri döndük.

Kolay gelsin.

csyasar · Mesaj gönderen **csyasar** » 04 Mar 2004 10:18

iyi siz de elektrik kesiliyo diye bakkal defterine geri dönün. bilgisayarları bırakalım o zaman.

dünyada hiçbir zaman risksiz iş olmaz. mesela siz araba çarpar diye dışarıçıkmamazlık edebilir misiniz? işlerimizde o kadar kolaylık sağlıyor bilgisayarlar. yedeği var ups'i var. bunları kullanarak sorun yaşamadan işlerinizi halletmeye çalışın.

Mesaj gönderen **name** » 09 Mar 2004 01:23

iyi çalışmalar

@name sanırım senin yazılımdan kaynaklanan bir şey olabilir. Tahminim transection lar açık kalıyor. bu güne kadar gözlemlediklerim eğer transection lar açıksa db de bozulma ihtimali daha da yükseliyor.

freeman35 Transaction'lar ile ilgili ayrıntılı bilgiyi nereden bulabilirim. Bu forum'da arama yaptım ama ayrıntılı ve sadece Transaction'lar üzerine yazılmış bir bilgi bulamadım.

Mesaj gönderen **husonet** » 09 Mar 2004 03:55

Merhaba

FİREBIRD ve INTERBASE için TRANSACTION.
Veritabanına bağlantı yapıldığı anda Transaction başlar. Transaction.Start komut verildiği anda başladığı andada veritabanı işlemler için hazırdır.Tek farkı transaction işlemleri cache de tutar. commit veya commitretaining komutu verilirse Harddiske yazar.Disk işlemleri önemli değildir çünkü delphi de herhangi bir veritabanını açtığın anda her şeyi cacheden alınıp verilir, kayıt sorgulandığında veya bir kayıt çağrıldığında bu kayıt Harddiskten okunmaz cache den çağrılır commit komutu ise cache deki bilgileri diske yazar işte transactionu roollback yaptığında ise eski kayıtlar geri alınır.

Kolay Gelsin...

Mesaj gönderen **name** » 09 Mar 2004 06:57

İyi çalışmalar
Cevabınız için teşekkür ederim hüseyin bey. Aslında Transaction kullanımında daha fazla verim nasıl alınabilir, ibx bileşenleri ile kullanmak zorunlu mu? vb.. sorular takıldı aklıma.

Mesaj gönderen **sadettinpolat** » 09 Mar 2004 07:19

SQL

Bölüm 12: Hareket İşleme

Orjinal İsmi: (The Complete Reference)

James R. Groff - Paul N. Weinberg

Alfa KitapEvi

izolasyon düzeyleri (transection) hakkında detaylı bilgi bu kaynaktan bulabilirsiniz.

Mesaj gönderen **safak** » 09 Mar 2004 09:24

UPS bulunmalı ve yedekleme işlemi düzenli olarak yapılmalı.
Firebird'de tüm işlemleri anında diske yazma olanağı var. Bu durumda veri güvenliği çok yüksek. Fakat cache kullanılmadığı için performans düşük. FB iki aşamalı commit diye bir yapı olmalı. Bu sayede asılı transactionlar kolayca çözülebiliyor.

Transactionlarda temel ilke "mümkün olan en kısa süre açık kalmalı" şeklinde. Yani sanki iğne üzerinde oturuyormuş gibi düşünülmeli. Bilginin yazılışı, silinişi, güncellenmesi, gerekiyorsa okunması, bir kayıtta/tabloda yapılan işlemlerin diğer kayıtlara/tablolara yansıtılması sırasında transactionlar açılıp kapanmalı. Bunun dışında açık kalan transactionlar önemli tasarım hatalarına işaret eder. Ayrıca bir bilgiyi başka bir tabloya yansıtmak (bazen tekrarlamak) şiddetle kaçınılması gereken bir çözüm. "Cari hesapları , genel muhasebeye yansıttım" gibi birşey duyuyorsanız ya da düşünüyorsanız alarm zilleri çalmaya başlamıştır. Normalizasyon kurallarına, bilginin tekrarsızlığına dikkat edilmeli. Bilgi herzaman tek kaynaktan orijinal olarak elde edilmeli. Bunlara dikkat edildiği zaman transaction süreleri son derece kısalır. Kısa transactionlar veri erşim hızını artırır, veri kaybı olasılığını düşürür.

Mesaj gönderen **name** » 10 Mar 2004 12:41

Merhaba

Teşekkürler şafak bey.

Peki Transaction'un "params" özelliği hangi konumda olmalı.

Mesaj gönderen **freeman35** » 10 Mar 2004 10:26

Bir kaç ilavede ben yapayım, Ben Read Commited kullanıyorum, neden hızlı bir şekilde Transectionlar db ye gömülsün ve kullanıcılar bunu görüp kullanabilsinler.
Transection doğru bir cache dir. Ama bunu Server üserinde yapar. Mantığınızı kurarken dikkat edin eğer kayıt post edildi ise ve bu db gömülmeye hazırsa bunu direk commit retaing edin. bunuda afterpost, afterdelete te yaptırın. afteracancel de rollbackretaing koymayı unutmayın.
Eğer bir master-detail ise, 2 tablo var demektir. bu 2 table ı aynı transection a bağlayın. Burada makbuz mantığı olduğu için yani detail kayıtların ne kadar olduğu belli değil ise transaction dan önce cachedupdate i kullanmanızı öneririm. cache işlemi local de yapın. daha sonra ApplyUpdate yapın. hemen arkasındanda commitretaing.

elektrikler kesildi

Kolay gele