Interbase 7.1, immer wieder Indexfehler

[Andreas Schilling]

Vor jedem Zugriff unserer Software auf die Datenbank (liegt auf Server) erfolgt eine Prüfung der Datenbank auf Fehler was auch gut funktioniert. Bei einem Kunden schlägt die Prüfung einmal die Woche Alarm und die Datenbank muss repariert werden, zum Glück nur Indexfehler aber immer wieder die gleichen Tabellen. Diese Tabellen werden von einem bestimmten Modul verwendet, welches immer am Tag vor den Fehlermeldungen benutzt wird. Da das Modul / die Software auch von anderen Kunden verwendet wird und dort noch viel intensiver, und dabei keine Fehler auftreten, gehe ich davon aus, das es sich um ein Kundenspezifisches Problem handelt.

Die Frage ist jetzt: bekommt man einen Index "kaputt" durch "falsche" Update/Insert- Anweisungen oder ist in der Regel defekte Hardware verantwortlich?

Oder liegt es an der Interbaseversion 7.1 (hat sonst kein anderer, ansonsten entweder 6.5 oder Firebird 2.0)?

In der einen Tabelle werden Termine verwaltet die jede Woche aktualisiert werden (werden verschoben, deaktiviert, neue angelegt) und in der anderen Tabelle die dazugehörenden Mitarbeiter (diese werden hinzugefügt, ausgetauscht oder deaktiviert).

Dazu nun die Interpretation der Logdatei vom letzten Freitag: (Interbase wird vor Datensicherung per Batchdatei beendet)
1) der Interbase-Server wurde nicht planmäßig nach der Datensicherung gestartet (eigentlich immer zwischen 1:00 und 2:00 Uhr) weil die Datensicherung nicht ordnungsgemäß beendet wurde
2) beim ersten Zugriff auf Datenbank um 8:20 Uhr wird Indexfehler festgestellt
3) nach dem dritten Reparaturversuch um ca. 8:40 Uhr mit korrekten Backup/ Restore konnte wieder mit der Datenbank gearbeitet werden.

Auszug aus IB-Logdatei
--------------------
DC01 (Server) Fri Jul 10 07:53:25 2009
Server: setting SWEEP_QUANTUM to 250, USER_QUANTUM to 250, SWEEP_YIELD_TIME to 1 ms
and MAX_THREADS to 1


DC01 (Server) Fri Jul 10 07:53:25 2009
SERVER/set_process_affinity: setting ProcessAffinityMask to 1

DC01 (Client) Fri Jul 10 07:53:25 2009
Guardian starting: C:\Programme\Borland\InterBase\bin\ibserver.exe


DC01 (Server) Fri Jul 10 07:56:14 2009
Server: setting SWEEP_QUANTUM to 250, USER_QUANTUM to 250, SWEEP_YIELD_TIME to 1 ms
and MAX_THREADS to 1


DC01 (Server) Fri Jul 10 07:56:14 2009
SERVER/set_process_affinity: setting ProcessAffinityMask to 1

DC01 (Client) Fri Jul 10 07:56:14 2009
Guardian starting: C:\Programme\Borland\InterBase\bin\ibserver.exe


DC01 (Server) Fri Jul 10 08:20:27 2009
Database: C:\PROGRA~1\SR\HM\TABELLEN\HM_DB.GDB
Index 3 is corrupt on page 17065 in table P_WOPLANPERS (226)


DC01 (Server) Fri Jul 10 08:25:50 2009
INET/inet_error: read errno = 10054 client host = TECHNIK connection name = dc01 user name = MSCHMIDT

DC01 (Server) Fri Jul 10 08:25:54 2009
INET/inet_error: send errno = 10054 client host = TECHNIK connection name = dc01 user name = MSCHMIDT

DC01 (Server) Fri Jul 10 08:37:58 2009
Database: C:\PROGRA~1\SR\HM\TABELLEN\HM_DB.GDB
Index 3 is corrupt on page 17065 in table P_WOPLANPERS (226)


DC01 (Server) Fri Jul 10 08:39:50 2009
Database: C:\PROGRA~1\SR\HM\TABELLEN\HM_DB.GDB
Index 3 is corrupt on page 17065 in table P_WOPLANPERS (226)


DC01 (Server) Fri Jul 10 08:42:18 2009
INET/inet_error: read errno = 10054 client host = TECHNIK connection name = dc01 user name = MSCHMIDT
------------------------

[Stormy]

Zitat von Andreas Schilling:

Die Frage ist jetzt: bekommt man einen Index "kaputt" durch "falsche" Update/Insert- Anweisungen oder ist in der Regel defekte Hardware verantwortlich?

Kurz gesagt: Ja!
Ich hatte das gleiche Problem was dadurch entstand dass das Client-Tool einen Wert in die DB einfügen (Insert) wollte der vom falschen Typ war. Dabei war nicht die "Main-Table" davon betroffen sondern eine damit verknüpfte Abhängigkeit.


Gruß
Stormy

[hoika]

Hallo,

lange Antwort: kommt drauf an...

Klar ist defekte Hardware (RAM, Platte) ene mögliche Ursache.
Es könnte aber auch an der Software liegen,
z.B. falsche DLL-Version (ist das immer noch gds32.dll ?)

Läuft das andere Modul auf einem gesonderten Rechner ?
Dann mal dort auf verschiedene Client-DLLs prüfen.

Wie sieht der Connection-String aus (server:d:\data\data.fdb).
Zumindestens ältere IB-Versionen hatten ein Problem,
wenn verschiedenen Connection-Strings verwendet worden sind,
z.B. server:d:\data\data.fdb vs 192.168.100.1:d:\data\data.fdb

Welche IB-Version (SS oder CS) ?

Wie sieht es aus mit dem Virenscanner ?
Das DB-Verzeichnis mal in die Ausnahmen packen.


Heiko

[Blup]

Neben Hardwarefehlern und Virenscannern die sich mit Vorliebe an Datenbanken versuchen...

Als Ursache kommt z.B. eine noch offene Transaktion und/oder Datenbankverbindung in Betracht.
(Kunden die ihre Rechner aussschalten oder schlafen schicken ohne das Programm zu beenden.)
Dann ist natürlich die Frage, ob Interbase wirklich beendet wurde, steht das so in der IB-Logdatei?
Das Beenden des Dienstes kann nach der Anforderung unter Umständen mehrere Minuten dauern.
Wird danach in einer Schleife geprüft, ob der Dienst bereits beendet ist, bevor die Sicherung startet?

Ist das Servicepack für IB 7.1 installiert?

[Andreas Schilling]

Zitat von Blup:

Dann ist natürlich die Frage, ob Interbase wirklich beendet wurde, steht das so in der IB-Logdatei?

nein, steht so nicht drinnen, aber auf meinem Firmen-PC steht es auch nur drinnen, wenn ich über den Interbase Manager den Server beende.

Zitat von Blup:

Wird danach in einer Schleife geprüft, ob der Dienst bereits beendet ist, bevor die Sicherung startet?

nein

Zitat von Blup:

Ist das Servicepack für IB 7.1 installiert?

nein

Zitat von hoika:

Läuft das andere Modul auf einem gesonderten Rechner ?
Dann mal dort auf verschiedene Client-DLLs prüfen.

Alle Clients haben die komplette Programm-Installation und die gleiche gds32.dll.
Wird mit dem Hauptprogramm gearbeitet (Wiederholungsaufträge anlegen, Rechnungen erstellen) passiert nichts, wird mit dem Modul Terminplanung gearbeitet (1 X pro Woche), dann kracht es am nächsten Tag. Und es betrifft auch immer wieder die zwei gleichen Tabellen, welche nur von diesem Modul benutzt werden.

Zitat von hoika:

Wie sieht der Connection-String aus (server:d:\data\data.fdb).

sollte auf allen gleich PC gleich sein, da die Konfigurationsdatei von einem PC auf den anderen kopiert wurde

Zitat von hoika:

Welche IB-Version (SS oder CS) ?

keine Ahnung, wie die Voreinstellung halt war. Diesmal habe nicht ich installiert, sondern der EDV-Mann vor Ort.

[hoika]

Hallo,

wie läuft denn die Sicherung ab ?
etwa so:
- IB beenden
- kopieren (copy)
- IB starten

oder wird noch ein Backup/Restore gemacht ?

Warum wird Interbase überhaupt angehalten ?


Das Log vom Donnerstag Abend wäre interessant,
um zu sehen, ob der Server beendet wurde.


Wie wird Interbase beendet ?
Läuft ein Terminal-Server und dort vielleicht das Programm noch (Modus "Verbindung halten") ?

Zu SS (SuperServer) / CS (Classic Server).
Es handelt sich nicht um einen Modus, sondern um grundverschiedene Programmversionen.

Bei CS kann es schon mal vorkommen, das DB-Prozesse hängenbleiben.

Der EDV-Mensch soll mal sehen, ob es einen IBServer-Prozess (SS) in der Taskleiste gibt,
wenn mehrere das Programm offen haben.



Heiko

[dataspider]

Hi,

keine Ahnung, ob das Verhalten in IB genau so ist wie in FB.
Wenn man z.B. eine Domain in der Länge kürzt, so funktioniert das meist.
Gibt es aber indizierte Felder mir dieser Domain, welche bereits längere Werte haben,
so crasht es erst später beim Backup oder Select.

Cu, Frank

[dmagin]

kurzfiristig:

das protokoll sagt ja genau der Index3 ist defekt. diesen index droppen und neu erstellen.


langfristig:

erstmal würde ich auf IB 7.5 updaten was auch kostenlos ist.

dort wurde eine menge von bugfixes gemacht.

backup vorher nicht vergessen und nach der intallation des servers restore machen.

auf einem DB server (wo nur die DB läuft) muss wie schon gesagt wurde, würde ich keinen virenscanner installieren oder die gdb bzw ib dateien ausschliesen.

die client's auf die neue gds32.dll updaten bzw. einfach client installation ausführen


gruss

daniel magin

[dmagin]

Zitat von hoika:

Hallo,

wie läuft denn die Sicherung ab ?
etwa so:
- IB beenden
- kopieren (copy)
- IB starten

oder wird noch ein Backup/Restore gemacht ?

Warum wird Interbase überhaupt angehalten ?


Das Log vom Donnerstag Abend wäre interessant,
um zu sehen, ob der Server beendet wurde.


Wie wird Interbase beendet ?
Läuft ein Terminal-Server und dort vielleicht das Programm noch (Modus "Verbindung halten") ?

Zu SS (SuperServer) / CS (Classic Server).
Es handelt sich nicht um einen Modus, sondern um grundverschiedene Programmversionen.

Bei CS kann es schon mal vorkommen, das DB-Prozesse hängenbleiben.

Der EDV-Mensch soll mal sehen, ob es einen IBServer-Prozess (SS) in der Taskleiste gibt,
wenn mehrere das Programm offen haben.



Heiko

bei Interbase gibts es nicht Superserver und Classic Server geraffel. da Interbase mit korrektem SMP läuft im gegensatz zu FB

nur so zur info

[Andreas Schilling]

Zitat von dmagin:

das protokoll sagt ja genau der Index3 ist defekt. diesen index droppen und neu erstellen.

Datenbank wird immer mit IB_Service- Komponete und Options := [MendDB]; für Backup / Restore vorbereitet welches anschließend durchgeführt wird. Danach ist der Index solange in Ordnung bis wieder mit dem Modul gearbeitet wird

Zitat von dmagin:

erstmal würde ich auf IB 7.5 updaten was auch kostenlos ist.

Das werde ich dann mal machen und sehen ob der Fehler weiterhin auftritt. Esrt einmal allen Dank für die Tips und ich melde mich dann wieder ob das Update etwas gebracht hat oder nicht.