FIREBIRD Server stürzt immer ab... 20 Arbeitsplätze lahm...

[Meta777]

Zitat von webcss:

Hmm, beim Flug übers Log fällt folgendes auf

Zitat:

SERVER2 (Server) Thu Aug 03 11:43:17 2006
Shutting down the Firebird service with 123 active connection(s) to 1 database(s)

Zitat:

SERVER2 (Server) Tue Aug 01 12:20:11 2006
Shutting down the Firebird service with 109 active connection(s) to 1 database(s)

Zitat:

SERVER2 (Server) Mon Aug 07 12:49:09 2006
Shutting down the Firebird service with 97 active connection(s) to 1 database(s)

usw. Bei nur 20 Clients ein bischen viel, oder?

Ja, in der Tat etwas viel. Auch wenn es etwas mehr als 20 clients sind. Aber es sind auch mindestens 2 Progs mit DB Connection pro client am laufen.

Zitat von webcss:

Das sieht mir ganz danach aus als würde sich FB in Connections und lang laufenden Transactions verhedern,
sprich: (viele) offene Clients mit vielen Abfragen welche alle jeweils eine eigene Verbindung mit einer (oder mehreren) Transaktionen offenhalten. Da muß eine Multiversionen-Datenbak irgenwann mal ins trudeln kommen.

Abhilfe: so bitter es klingt, die Anwendungssoftware nach derartigen fehlern durchforsten, Tranasction für leseoprationen nur Read-Only, Write Transaction regelmäßig Commiten (hard commit nicht retained), eventuell Timergestützt um den Anwendern die "Macht" zu nehmen.
Überlegen, ob nicht eine Verbindung pro Client doch ausreichend ist.

Wie gehts das mit den Read-Only transactions? Muss bei "Params" sicher eingetragen werden, or?
Momentan haben wir auch in manchen Teilen der Software mehrere DB Verbindungen was wir auch noch änderen könnten...

Zitat von webcss:

Wie erfolgt der Zugriff? Native, BDE, Ado ...?

Wenn mit "Native" der Zugriff über TIBDatabase, TIBTransaction und TIBQuery etc gemeint dann ist der Zugriff native

@All:
Liege ich in der Annahme richtig das bei .Free einer TIBTransaction oder einer TIBDatabase die Verbindung nicht abgebaut wird? Macht jedenfalls den Eindruck...

Danke für eure Hilfe
Gottes Segen

[Lemmy]

Hi,

wann wurde das letzte mal ein Backup-Restore bei der Datenbank gemacht? Wenn das schon lange her ist ein Backup ziehen und auf einem TESTRECHNER das Backup einspielen und testen ob das in Ordnung ist, dann das Original auf dem Server überbügeln.

TIBQuery ist eigentlich nicht für den produktiven Betrieb geeignet, Du solltest das schleunigst gegen TIBDataset austauschen! Auf Firebird 2 würde ich mit IBX als Komponentenbibliothek nicht unbedingt wechseln....

Und ein Transaction.Free schließt nicht unbedingt die Transaction, zumindest nicht unbedingt so wie du es gerne hättest!

Schau mal ob das mit dem Backup klappt und spiele das dann auf dem Server ein und teste dann die Stabilität nochmal. Baue auf jeden Fall so bald wie nur möglich deine Anwendungen um, damit die vernünftig arbeiten (kein TIBQuery und vernünftiges Transaction-Handling).

Grüße
Lemmy

Nachtrag: Warum greifen eigentlich alle auf eine Datenbank zu? Hängen die Daten der unterschiedlichen Programme zusammen oder wurde das gemacht, weil man das bei MySQL beim Webhosting auch os macht?

[Meta777]

ZWISCHENSTAND:
Nach heute Morgen hat sich gegen Mittag der FB SRV wieder verabschiedet. Daraufhin hab ich mit netstat gesehen dass von einen unserer anderen Server sehr viele Verbindungen NICHT geschloßen waren. Deshhalb fragte ich vorhin ob .Free DB-Verbindungen schließt. Nachdem ich vor dem .Free die DB geschloßen habe (TIBquery.Close TIBTransaction.Commit und TIBDatabase.Close) scheint es jetzt stabil zu laufen.

Zitat von Lemmy:

Hi,

wann wurde das letzte mal ein Backup-Restore bei der Datenbank gemacht? Wenn das schon lange her ist ein Backup ziehen und auf einem TESTRECHNER das Backup einspielen und testen ob das in Ordnung ist, dann das Original auf dem Server überbügeln.

Backup - Restore wurde gestern gemacht. hatte keine Auswirkung.

Zitat von Lemmy:

TIBQuery ist eigentlich nicht für den produktiven Betrieb geeignet, Du solltest das schleunigst gegen TIBDataset austauschen! Auf Firebird 2 würde ich mit IBX als Komponentenbibliothek nicht unbedingt wechseln....

Und ein Transaction.Free schließt nicht unbedingt die Transaction, zumindest nicht unbedingt so wie du es gerne hättest!

Schau mal ob das mit dem Backup klappt und spiele das dann auf dem Server ein und teste dann die Stabilität nochmal. Baue auf jeden Fall so bald wie nur möglich deine Anwendungen um, damit die vernünftig arbeiten (kein TIBQuery und vernünftiges Transaction-Handling).

Grüße
Lemmy

Uns würde interessieren WARUM TIBQuery nicht geeignet sei und warum TIBDataset es ist?

Eins hab ich noch: Sind IBX die Komponenten die bei Delphi 7 standardmäßig dabei sind oder ist es eine andere bibliothek?

Zitat von Lemmy:

Nachtrag: Warum greifen eigentlich alle auf eine Datenbank zu? Hängen die Daten der unterschiedlichen Programme zusammen oder wurde das gemacht, weil man das bei MySQL beim Webhosting auch os macht?

Die Programme hängen alle zusammen - es ist ein System

[Lemmy]

Zitat von Meta777:

scheint es jetzt stabil zu laufen.

sehr schön...

Zitat von Meta777:

Uns würde interessieren WARUM TIBQuery nicht geeignet sei und warum TIBDataset es ist?

ganz einfach: Weil der Programmierer der IBX, Jeff Overcash, es so gesagt hat: Er hat TIBTable und TIBQuery nur entwickelt, um einen einfachen BDE-Umstieg ermöglichen zu können. TIBTable und TIBQuery sollen dann auf TIBDataSet oder TIBSQL umgerüstet werden!

Zitat von Meta777:

Eins hab ich noch: Sind IBX die Komponenten die bei Delphi 7 standardmäßig dabei sind oder ist es eine andere bibliothek?

Ja, das sind die IBX.

Lemmy

[webcss]

Falls ihr über kurz oder laang vorhabt auf FB 2 umzusteigen: nix wie weg von IBX.
Schau Dir mal uib + alexdataset oder ZeoS (hab keinen link) an (kostenlos),
oder kommerziell FIBPlus bzw. ganz neu IBCore.

Ansonsten kann ich nur empfehlen, schau dir das Application design in punkto zugriff an, s. post weiter oben.
Readonly gibst du als parameter einer Transaction an. Die meisten der oben genannten komponenten sets bieten die möglichkeit, zwei unterschiedliche transactionen, eine für nur lesen und eine zum schreiben, einzustellen. somit bekomst du weniger schwierigkeiten mit dem versioning von FB.

Vorab schon mal viel spass und glück!

[Meta777]

Zitat von webcss:

Falls ihr über kurz oder laang vorhabt auf FB 2 umzusteigen: nix wie weg von IBX.
Schau Dir mal uib + alexdataset oder ZeoS (hab keinen link) an (kostenlos),
oder kommerziell FIBPlus bzw. ganz neu IBCore.

GAAAANNNNNZ WICHTIG FRAGE: - Warum -
Wir haben folgenden Situation: mind. 10 Progs mit TIbQuery & Co, dass sind bestimmt hunderte Komponenten die wir austauschen müssten.
Darum müssen wir wissen ob es sich lohnt. Und was ist so wesentlich besser bei den genannten Komponenten als IBX und könnte man die Komponenten parralel zu IBX laufen lassen so dass wir nach und nach umstellen könnten?
Und welche dieser Sets ist am Besten? Gibts da einen Vergleich oder ne Übersicht?

Zitat von webcss:

Ansonsten kann ich nur empfehlen, schau dir das Application design in punkto zugriff an, s. post weiter oben.
Readonly gibst du als parameter einer Transaction an. Die meisten der oben genannten komponenten sets bieten die möglichkeit, zwei unterschiedliche transactionen, eine für nur lesen und eine zum schreiben, einzustellen. somit bekomst du weniger schwierigkeiten mit dem versioning von FB.

Vorab schon mal viel spass und glück!

Danke.
Wir sind auch gerade dabei uns auf eine TIBDatabase Kompo pro App zu beschränken, indem wir eine Globale DB Variable benutzen.

Gottes Segen

[MagicAndre1981]

Zitat von Meta777:

Zitat von webcss:

Falls ihr über kurz oder laang vorhabt auf FB 2 umzusteigen: nix wie weg von IBX.
Schau Dir mal uib + alexdataset oder ZeoS (hab keinen link) an (kostenlos),
oder kommerziell FIBPlus bzw. ganz neu IBCore.

GAAAANNNNNZ WICHTIG FRAGE: - Warum -

Weil die IBX-Komponneten den Firebird nicht offiziell unterstützen und weil sich der Firebird mit jeder Version weiter von seinem Ursprung Interbase entfernt und damit kann es irgendwann zu Problemen führen.

[Lemmy]

Zitat von Meta777:

Und welche dieser Sets ist am Besten? Gibts da einen Vergleich oder ne Übersicht?

Welche Programmiersprache ist die Beste?

Da Ihr eh die Anwendung bzgl. TIBQuery umstellen müsst, würde ich Euch empfehlen in diesem Zug eine andere Komponentenbibliothek einzusetzen. ICH würde dabei FIBPlus bzw. UIB in die enge Auswahl nehmen. FIBPlus für Anwendungen bei denen man mit DB-Komponenten arbeiten will, UIB für ein Mehrschichtenprogramm, was ich inzwischen generell für die "einzig richtige" Programmarchitektur halte. Das dürfte bei Euch aber vermutlich nicht in Frage kommen....

Die Gründe gegen TIBQuery habe ich schon genannt, die gegen die Verbindung IBX-Firebird 2.0 hat Andre schon alles gesagt! Was dabei vielleicht auch noch wichtig wäre: Die IBX die bei Delphi 7 dabei sind, sind nicht die aktuellsten. Es gibt inzwischen 5 oder 6 Updates dafür. Allerdings hatte ich mit den neueren IBX-Updates mit Firebird 1.5 schon das eine oder andere Problem....

Lemmy

[mquadrat]

Wenn die Performance für ihn ihn Ordnung ist, kann er doch bei TIBQuery bleiben. Zitat aus einer BorCon 2003 Präsentation von Jeff Overcash zur TIBQuery:

Zitat:

Performance nearly identical to IBDataset

.

[webcss]

Zitat von Meta777:

Und welche dieser Sets ist am Besten? Gibts da einen Vergleich oder ne Übersicht?

Also, FIBPlus hat einen Performance-Vergleich zu IBX. Inwieweit man das als zuverlässig ansehen kann weiss ich nicht, schliesslich ist es ein kommerzielles Produkt und die wollen eins vor allem: VERKAUFEN! Dabei ist ein Tool um möglichst automatisch von IBX auf FIBPlus umzustellen, für euer Problem mit 100+ Kompos sicher nicht verkehrt!

Ich persöhnlich bevorzuge UIB + Alexdataset, 1. wegen des Preises (Kostet nix) und weil es von Grund auf für Firebird entwickelt wurde und maßgeblich entwickelt wird. FIBPlus hat seine wurzeln wie auch IBX in FreeIBComponents von Gregory Deatz.
AlexDataset ist ein TDataset abkömmling mit den gleichen Features wie FIB(Plus)Dataset, aber halt für UIB gestrickt.
Bei UIB ist auch ein Testprogramm für den Vergleich IBX<->UIB dabei, das spricht Bände!
UIB ist dabei auch noch speziell für den Multithreading-Betrieb entwickelt, im Server-bereich ein klarer vorteil.

Wenn Ihr also mit Datensensitiven Komponenten arbeitet sind beide zu empfehlen.

Die CoreComponents sind "blutjung" und ebenfalls kostenpflichtig, daher habe ich keine Erfahrung damit.

ZeOS ist ein Set aus komponenten mit der der Zugriff auf verschiedene DBMS möglich ist, also macht vor allendingen dann Sinn, wenn ihr Euch irgendwann für ein anderes DBMS entscheiden solltet.