veritabanını açmaya çalıştığımda
internal gds software consistency check (can't continue after bugcheck).
ib expert /servicess/database valitation yaptığında düzeldi fakat bu hatayı
neden yaptığını bulamadım.belki daha önceden karşılaşmış olabilirsiniz diye
sorayım dedim.
Firebird-1.5.0.4027-RC7
delphi 6
kolay gelsin iyi çalışmalar...
firebird veritabanı problemi
elektrik kesilmelerinde veya database server'in normal olmayan yontemlerle kapanmasından kaynaklanan bir sorun olabilir ve de veritabanını kaybetme ile de sonuclanabilir... Bu durumlar icin su mesaj isinize yarar.
viewtopic.php?t=1329
bunun dısında bu tur bozulmaları minimuma indirecek bir yontemden bir arakdas bahsetmisti ama tam hatirlayamadim su anda....
viewtopic.php?t=1329
bunun dısında bu tur bozulmaları minimuma indirecek bir yontemden bir arakdas bahsetmisti ama tam hatirlayamadim su anda....
Aslında bu bir optimizasyon problemi. Bir ucunda güvenlik, diğer ucunda performans var. İkisi birden aynı anda sağlanabilse, ya da tam lazım olduğu sırada gerekli olan kendini devreye sokabilse.. Bazıları emniyet kemeri takmayı sevmezler. Tabii sürekli bir rahatlık var. Ama tam kaza sırasında kemeri takmak mümkün olmaz. Bu tip durumlarda genel güvenlik önlemi olarak:
1. Kesintisiz Güç kaynağı (güvenli kapanış için yeterli olanları o kadar ucuz ki, kullanmayanların şebeke kesintilerinden şikayet etmeye pek hakları yok)
2. Parçaları zamanında değiştirilen, sesi dinlenen ve temiz tutlan bir sistem
3. Günlük, haftalık, aylık yedek setleri oluşturmak
4. Yedeklerin bir setini bina dışında bulundurmak. (yangından sonra yedeğiniz olmuyor)
5. Acil durum kardeş sistemi oluşturmak. (Öyleki sisteminiz tamamen yok olsa, makul bir kayıpla, çok hızlı bir şekilde ayağa kalkabilmelisiniz)
Bütün bunları yapmayı ihmal etmeden diğer teknik ayrıntılara bakılabilir:
1. Gölge dosyaların, ikinci bir diskte tutulması. (disk bozulursa, yedeği de kaybolmasın) Mümkünse gölge dosyanın başka bir sistemde tutulması.
2. Transactionların en kısa süre açık kalmasını sağlamak. Mümkün olan her durumda bilgiyi diske yazmak.
3. Operating sistem hakkında bilgi sahibi olmak. Bir yerde okuduğuma göre; NT service olarak çalışan databaselerde flush işlemi sistem kapatılırken yapılıyor, yani siz database ileişinizin bittiğini sanıyorsunuz ama bilgiler hala cache de bulunuyor.
Amerikadaki araştırmalardan okuduğum bir yazıda; veri tabanını kaybeden şirketlerin 1.5 yıl içerisinde iflas ettikleri yazılıyordu.
Yani bu risk; bilgisayarcıların, programcıların, IT yöneticisinin sorumluluğuna transfer edilip unutulacak bir şey değil. İşletmesinin nakit/risk yönetimini yapanlar aynı ilgiyi bilgi sistemleri güvenliğe göstermezlerse, ileride paralarını ve risklerini yönetecek ortamı bulamıyorlar.
Kolay Gelsin,
1. Kesintisiz Güç kaynağı (güvenli kapanış için yeterli olanları o kadar ucuz ki, kullanmayanların şebeke kesintilerinden şikayet etmeye pek hakları yok)
2. Parçaları zamanında değiştirilen, sesi dinlenen ve temiz tutlan bir sistem
3. Günlük, haftalık, aylık yedek setleri oluşturmak
4. Yedeklerin bir setini bina dışında bulundurmak. (yangından sonra yedeğiniz olmuyor)
5. Acil durum kardeş sistemi oluşturmak. (Öyleki sisteminiz tamamen yok olsa, makul bir kayıpla, çok hızlı bir şekilde ayağa kalkabilmelisiniz)
Bütün bunları yapmayı ihmal etmeden diğer teknik ayrıntılara bakılabilir:
1. Gölge dosyaların, ikinci bir diskte tutulması. (disk bozulursa, yedeği de kaybolmasın) Mümkünse gölge dosyanın başka bir sistemde tutulması.
2. Transactionların en kısa süre açık kalmasını sağlamak. Mümkün olan her durumda bilgiyi diske yazmak.
3. Operating sistem hakkında bilgi sahibi olmak. Bir yerde okuduğuma göre; NT service olarak çalışan databaselerde flush işlemi sistem kapatılırken yapılıyor, yani siz database ileişinizin bittiğini sanıyorsunuz ama bilgiler hala cache de bulunuyor.
Amerikadaki araştırmalardan okuduğum bir yazıda; veri tabanını kaybeden şirketlerin 1.5 yıl içerisinde iflas ettikleri yazılıyordu.
Yani bu risk; bilgisayarcıların, programcıların, IT yöneticisinin sorumluluğuna transfer edilip unutulacak bir şey değil. İşletmesinin nakit/risk yönetimini yapanlar aynı ilgiyi bilgi sistemleri güvenliğe göstermezlerse, ileride paralarını ve risklerini yönetecek ortamı bulamıyorlar.
Kolay Gelsin,
- Yusuf AYDIN
- Üye
- Mesajlar: 69
- Kayıt: 02 Oca 2004 05:45
- Konum: Antalya
Yazdığım bir projede bu hata banada sıklıkla geliyordu.
IB Concole veya IB Expert te işlemi Shutdown yapılmalı.. Bazan gdb kapanmış göstemesine rağmen açık kalabiliyor. Buda Validation işleminde başka aksamalara neden oluyor.
Bundan sonra GDB hala hata veriyor ise Validation öyle yapılmalıdır.
Validation işleminden sonra hata hala devam ederse . son çare olarak Maintenance içindeki Sweep çalıştırılmalıdır. (Sweep işlemini IB Expert içinde göremedim. Ama IBConsole içinde var.)
Daha sonra Validation işlemine tekrar baş vurulmalıdır.
SWEEP: Bazan bilgi kaybına neden olabiliyor.
Validation işleminden sonra Orpan Pageler olaşa biliyor. bunlarıda ancak Backup ve restor işlemleri temizler diye duymuştum.
Türkçe karakter setini desteklemediği içinde deneyemedim.
BU HATANIN OLUŞMAMASI İÇİN...
GDB nin Pagesize'nı yüksek tutmayın (default 1024) size 1024 olarak GDB creatını yapın.
Shadow oluşturmayıda deneye bilirsiniz. Ama buda hızda büyük düşüşlere neden oluyor.
GDB ile ilgili post, delete veya update hatta Close işlemlerinde bile Transcation mutlaka kullanılmalıdır.
- CommitRetaining veya
- RollbackRetaining
Kolay Gelsin.
IB Concole veya IB Expert te işlemi Shutdown yapılmalı.. Bazan gdb kapanmış göstemesine rağmen açık kalabiliyor. Buda Validation işleminde başka aksamalara neden oluyor.
Bundan sonra GDB hala hata veriyor ise Validation öyle yapılmalıdır.
Validation işleminden sonra hata hala devam ederse . son çare olarak Maintenance içindeki Sweep çalıştırılmalıdır. (Sweep işlemini IB Expert içinde göremedim. Ama IBConsole içinde var.)
Daha sonra Validation işlemine tekrar baş vurulmalıdır.
SWEEP: Bazan bilgi kaybına neden olabiliyor.
Validation işleminden sonra Orpan Pageler olaşa biliyor. bunlarıda ancak Backup ve restor işlemleri temizler diye duymuştum.
Türkçe karakter setini desteklemediği içinde deneyemedim.
BU HATANIN OLUŞMAMASI İÇİN...
GDB nin Pagesize'nı yüksek tutmayın (default 1024) size 1024 olarak GDB creatını yapın.
Shadow oluşturmayıda deneye bilirsiniz. Ama buda hızda büyük düşüşlere neden oluyor.
GDB ile ilgili post, delete veya update hatta Close işlemlerinde bile Transcation mutlaka kullanılmalıdır.
- CommitRetaining veya
- RollbackRetaining
Kolay Gelsin.
Re: firebird veritabanı problemi
konuyu hortlatmış gibi olacağım ama aynı hatayı ben de aldım ve nette araştırma yaparken şu mesajı buldum.
gfix ile data düzelebiliyormuş, data çok hasar görmüşse işe yaramayabilir demişler ama bende işe yaradı çok şükür. belki ihtiyacı olan biri olur diye buraya da yazayım dedim...
gfix ile data düzelebiliyormuş, data çok hasar görmüşse işe yaramayabilir demişler ama bende işe yaradı çok şükür. belki ihtiyacı olan biri olur diye buraya da yazayım dedim...
bazen yükselmek için önce dibi görmek gerekir...
forumda soru sormadan önce bakılmalı bence
daha fazlası için...
yürümeyi öğrenmeden koşmaya çalışanlar için, tökezleyip düşmek kaçınılmazdır...

forumda soru sormadan önce bakılmalı bence
daha fazlası için...
yürümeyi öğrenmeden koşmaya çalışanlar için, tökezleyip düşmek kaçınılmazdır...
