firebird veritabanı problemi

Firebird ve Interbase veritabanları ve SQL komutlarıyla ilgli sorularınızı sorabilirsiniz. Delphi tarafındaki sorularınızı lütfen Programlama forumunda sorunuz.
Cevapla
Kullanıcı avatarı
ahmetk
Üye
Mesajlar: 3
Kayıt: 11 Oca 2004 10:32

firebird veritabanı problemi

Mesaj gönderen ahmetk »

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...
Kullanıcı avatarı
fahrettin
Admin
Mesajlar: 2619
Kayıt: 11 Haz 2003 10:38
Konum: İstanbul
İletişim:

Mesaj gönderen fahrettin »

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....
Kullanıcı avatarı
gkimirti
Admin
Mesajlar: 1956
Kayıt: 02 Eyl 2003 04:44
Konum: İstanbul

Mesaj gönderen gkimirti »

sanırım birisi her datasetin yada tablonun afretpost olayına transaction.CommitRetaining kodunu eklemek
ikincisi de shadow komutu ile surekli yedekli calısmak
ÜŞENME,ERTELEME,VAZGEÇME
Kullanıcı avatarı
safak
Şafak EBESEK
Mesajlar: 165
Kayıt: 05 Ağu 2003 04:39
Konum: Istanbul
İletişim:

Mesaj gönderen safak »

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,
Kullanıcı avatarı
safak
Şafak EBESEK
Mesajlar: 165
Kayıt: 05 Ağu 2003 04:39
Konum: Istanbul
İletişim:

Mesaj gönderen safak »

Kusura bakmayın.
İnternet dondu.
İki defa aynı mesaj gelmiş.
Kullanıcı avatarı
mussimsek
Admin
Mesajlar: 7602
Kayıt: 10 Haz 2003 12:26
Konum: İstanbul
İletişim:

Mesaj gönderen mussimsek »

Merhaba,

birini sildim. Eğer hiçkimse mesajdan sonra cevap yazmadı ise, mesajını sağ üstteki X işaretine basarak silebilirsin. Eğer birisi cevap yazmışsa, forum silmeye izin vermiyor (moderatorler hariç).

Kolay gelsin.
Kullanıcı avatarı
Yusuf AYDIN
Üye
Mesajlar: 69
Kayıt: 02 Oca 2004 05:45
Konum: Antalya

Mesaj gönderen Yusuf AYDIN »

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.
Kullanıcı avatarı
unicorn64
Üye
Mesajlar: 919
Kayıt: 04 Nis 2006 08:56
Konum: yine yeniden Ankara ^_^

Re: firebird veritabanı problemi

Mesaj gönderen unicorn64 »

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...
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...

Resim
Cevapla