Stabile Indexdateien

[peterdahlmann]

Hallo, habe seit ca. 20 Jahren eine Anwendung laufen mit ca. 10 Usern im Netz. Früher unter Clipper, jetzt Alsaka. Die Performance ist gut trotz fehlender Client-Server DB wie z.B. ADS Server.
Ich habe nur ein Problem. Hin und wieder sind die Indexdateien corrupt (vermutlich nach Abstürzen oder wenn jemand seinen PC "hart" gekillt hat). Nicht mehr so häufig wie unter Clipper, aber ab und zu noch vorhanden. Das äußert sich durch einen echten Fehler oder dadurch, dass einzelne Datensätze nicht mehr sichtbar sind. Letzteres natürlich tödlich bei Auswertungen. Die Software öffnet die Index-Datein bei Start und schliesst sie am Ende zusammen mit den Tabellen. Dazwischen mache ich commits (bin aber nicht sicher, ob die wirklich der Stabilität zuträglich sind)
Gibt es Erfahrungswerte welche Indexe die stabilsten sind. Wie gesagt es passt alles - nur die Stabilität könnte besser sein.
Peter

[Manfred]

Hi,

bei mir haben die Probleme drastisch nachgelassen seit dem ich von NTX auf CDX umgestiegen bin. Ist auch m.E. einfacher zu verwalten, da nur 1 Datei mit allen TAGs drin und komprimiert, dadurch auch in Netzwerken schneller.

[brandelh]

Das wichtigste für stabile Indexe sind stabile Netzwerkverbindungen. Hier liegt mein Problem seit wir auf MS Server 2008 umgestiegen sind.
Mit den nötigen Registryeinstellungen sollte man zwar alle System stabil bekommen, aber spätestens bei Hardwarefehlern (Stromausfall, Spannungsschwankungen, Abschalten des Rechners, Netzwerkkarte, Netzteil usw.) kann Xbase++ nichts mehr retten.

Leider kann man beim Öffnen nicht erkennen ob eine Indexdatei defekt ist.
Seit ich massive Probleme habe, lösche ich die Indexdateien und baue neu auf, sobald:
1. XppError.LOG oder XppFatal.LOG gefunden werden (diese benenne ich gleichzeitig durch Anhängen eines Datums+Zeit um).
2. Einmal im Monat.
3. Logdatei protokolliert Öffnen und Schließen der Anwendung, wenn diese am Vortag nicht ausgeglichen sind, löscht der erste Rechner die Indexe
Danach baue ich immer wieder neu auf.

Ich persönlich habe lange die NTXDBE benutzt, allerdings besteht hier die Gefahr, dass man im Programm ab und an eine vergisst (insbesondere wenn man neue braucht).
Mit den CDXDBE kann einem das nicht passieren.

[Rolf Ramacher]

Ich mache dies seit langem so, daß ich wenn Programmteile und Masken erstellt werden, die Datenbank geöffnet wird und in arrays geladen werden. Dann werden die DBF wieder geschlossen und erst wieder geöffnet, wenn gespeichert wird. Dadurch habe ganz selten Index-probleme

[peterdahlmann]

ich hatte früher mehr Probleme aber seit ich vor vielen Jahren die Windows-Server durch Linux-Server + Samba ersetzt habe gibt es nur noch Probleme nach Abstürze der Clients. Reindiziert wird sowieso morgens täglich und automatisch, aber es ist auffällig, dass die Auswertungen am Nachmittag (z.B. Umsatzauswertungen) ab und an dahingehend fehlerhaft sind, dass Datensätze nicht im Index enthalten sind und daher "überlesen" werden.
Aufgrund Eures Echos werde ich es mal anstelle von NTX mit CDX probieren..
Danke
Peter

[Jan]

Hallo Peter,

reindizieren ist keine gute Idee. Immer den Index löschen und neu anlegen. Manche Fehler werden durch reindizieren nicht behoben. Außerdem wächst die Indexdatei an.

Jan

[brandelh]

schneller ist es auch nicht

[Manfred]

Interessant,

ich benutze auch Linux mit Samba, habe aber keine Probleme damit. Allerdings erst im Zusammenhang mit CDX wurden die Probleme verschwindend gering.

[Koverhage]

Ist CDX denn schneller ?
Was muss man alles tun um von NTX auf CDX zu wechseln?
Welche DbeInfo Einstellungen sollten gemacht werden ?

[Wolfgang Ciriack]

Hallo Klaus,
ist zwar schon ein paar Jahre her, dass ich umgestellt habe, damals war es definitiv so, dass es mit CDX Dateien etwas schneller und stabiler lief. Es gab damals auch in den Newsgroups den Hinweis, maximal 5 Indexschlüssel pro Indexdatei zu verwenden, ob dass heute noch notwendig ist, kann ich nicht sagen, ich habe trotzdem dass bis heute beibehalten und erzeuge bei z.B. 12 Indeschlüsseln 3 Indexdateien. Wichtig war noch bei der Umstellung, die Indexdateien unbedingt vor dem Neuerzeugen unbedingt zu löschen, da sonst die neuen Schlüssel hinten rangehängt werden, dass merkte ich dann, als eine Indexdatei dann mal hunderte von MB groß geworden war.
Meine jetzigen (ob optimal weiss ich nicht) CDX Einstellungen sind diese:

Code: Alles auswählen

IF !DbeLoad( "DBFDBE",.T.)
   DC_WinAlert( "Database-Engine DBFDBE not loaded" )
ENDIF
IF !DbeLoad( "CDXDBE",.T.)
   DC_WinAlert( "Database-Engine CDXDBE not loaded"  )
ENDIF
IF !DbeBuild( "DBFCDX", "DBFDBE", "CDXDBE" )
   DC_WinAlert( "DBFCDX Database-Engine, Could not build engine" )
ELSE
  DbeSetDefault("DBFCDX")
  DbeInfo(COMPONENT_ORDER,CDXDBE_LOCKRETRY,20000000)
  DbeInfo(COMPONENT_ORDER,CDXDBE_LOCKDELAY,10)
  DbeInfo( COMPONENT_ORDER, CDXDBE_MODE, CDXDBE_COMIX )
  DbeInfo(COMPONENT_ORDER, DBE_LOCKMODE, LOCKING_EXTENDED)
ENDIF

[Jan]

Hallo Wolfgang,

die Grenze von 5 Tags je Datei kenn ich garnicht. Und hab mich auch nie daran gehalten. Probleme hatte ich trotzdem nicht.

Ich mach mir die Verwaltung relativ einfach - die Indexdatei heißt so wie die dbf. Das hat in meinen Augen den Vorteil, das Datenbank, Memodatei, und Indexdatei im Explorer immer direkt beieinander stehen. Und ich beim Öffnen auch immer weiß, wie denn eigentlich die Indexdatei heißt.

Jan

[brandelh]

Ist CDX denn schneller ?

Hallo Klaus,

das kommt natürlich auf die Netzwerklast und die Dateigröße an.
Die CDX werden komprimiert gespeichert. Weniger Daten in der Übertragung wirken sich insbesondere auf langsamen Netzen positiv aus.
Auf jeden Fall bringt die Umstellung auf
DbeInfo( COMPONENT_ORDER, DBE_LOCKMODE, LOCKING_EXTENDED )
bei mehreren Stationen im Netz Vorteile solange überwiegend gelesen wird (Nachteile gibt es meines Wissens nicht).
Wenn du zudem noch UPPER(cFeld) sparen kannst, weil CDX nicht zwischen Groß-/Kleinschreibung unterscheidet, dann bringt das was beim Indizieren.

In Verbindung mit der FOXDBE kannst du dann noch kleinere Memofelddateien und mehr Datentypen verwenden.
Oder endlich Daten in ANSI in der Datei speichern.

Auch ich sehe einen großen Vorteil in der Regel ein NAME für alle Dateien !

DBU geht allerdings nicht mehr ohne Anpassung

PS:

DBF mit 500.000 Datensätzen, Indexfeld CHAR 5
NTX: 7.865 KB
CDX: 2.246 KB

[brandelh]

DbeInfo( COMPONENT_ORDER, CDXDBE_MODE, CDXDBE_COMIX )

diese Zeile würde ich nur nutzen, wenn wirklich eine Kompatibilität mit dem alten COMIX Treiber nötig ist.
Laut Beschreibung ist die Standardeinstellung die modernste Version.

[Herbert]

Ist CDX denn schneller ?
Was muss man alles tun um von NTX auf CDX zu wechseln?
Welche DbeInfo Einstellungen sollten gemacht werden ?

Ich habe bei grösseren Kunden auf CDX umgestellt.
Geschwindigkeitsmässig ist der erwartete Gewinn an Geschwindigkeit nicht eingetreten.
Vorteil: 1 Datei für eine dbf, bei .ntx pro Schlüssel eine.
Programmstart: mit cdx schneller
Datensuche mit cdx langsamer (unwesentlich)
Daher: ein Wechsel auf cdx lohnt nicht.

[AUGE_OHR]

Gibt es Erfahrungswerte welche Indexe die stabilsten sind. Wie gesagt es passt alles - nur die Stabilität könnte besser sein.

auch wenn deine Applikation und Indexe 100% stimmen wirst du bei einem "File basierendes" System wie DBF Dateien immer ein Problem mit dem M$ Server und SMB haben. man kann das zwar "optimieren" aber die M$ Server sind eben für "grosse" Dateien gedacht und der "Cache" macht ja die Geschwindigkeit aus. Dumm nur wenn der "Cache" nur kleine Häppchen bekommt die den "Cache" gar nicht richtig "füllen" -> SMB Probleme -> defekte Indexe.

glücklicherweise kommt mit Xbase++ v2.x nun pgDBE und damit kann man schon mal Erfahrung mit SQL und Xbase++ sammeln wenn man vorher noch nichts mit SQL zu tun hatte. bei dem jetzigen Konzept werden die IndexKey Ausdrücke von NTX / CDX, bei Verwendung des "UpSizeDbf.EXE", in die Table als internes Fields übernommen und "gepflegt".

[peterdahlmann]

Die Desktop-Datenbanken sind im Netz immer eine Krücke, besonders wenn viele Clients auf die selben Daten zugreifen. Corrupte Indizes treten ja in der Regel und bei aller fehlerfreiheit des Codes gerne nach Abstürzen der Software oder der Netzverbindungen auf. Und da ist ein Client-Server-System um Welten weniger anfällig.

Ja das mit Postgres hört sich gut an, wenn es denn bald kommt. In der Vergangenheit wurden ja die angepeilten Termine immer beliebig gerissen.

Wenn ich es richtig verstanden dann soll es nicht nur einen "Treiber" für Postgres geben, sondern es soll sogar eine Moglichkeit geben die satzbassierten Befehle in Postgres auszuführen. Damit müsste man nicht den kompletten Code umschreiben. Ich bin auf jeden Fall gespannt. Wäre schön, wenn man belastbare Infos bekommen könnte - zu den Features wie zu den Terminen.

[Manfred]

ich denke mal belastbare Infos gibt es nicht, aber dehnbare zuhauf.

[AUGE_OHR]

... sondern es soll sogar eine Moglichkeit geben die satzbassierten Befehle in Postgres auszuführen.

das ist im Prinzip möglich ...

Damit müsste man nicht den kompletten Code umschreiben. Ich bin auf jeden Fall gespannt.

wenn dein Code "so simple" ist und du in 2GB Dimensionen denkst "könnte" es funktionieren ...

pgDBE ist ein Xbase++ "Wrapper" für die libpq.dll API wobei Alaska PostgreSQL v8.x verwendet
diese beziehen sich nur auf "bekannte" Xbase++ Datenbank Functionen und die nutzen längst nicht die Fähigkeiten von PostgreSQL.

Konzept bedingt kann man aber Xbase ( Daten SATZ) und SQL ( Daten MENGE ) aber nicht so einfach unter einen Hut bekommen.
Es gibt also, ohne "Optimierung", nur einen Kompromiss was mit steigender Grösse der Table sich am Tempo bemerkbar macht.

nun sagte ich "so simple" ... "kompliziert" wäre z.b. eine "incrementelle" Suche ...
klar funktioniert wohl dein Code ... die Frage ist nur wie schnell ...
du wirst also vermutlich deinen Code auf die neuen Umstände "anpassen" müssen und teilweise dein Xbase Konzept umstellen wie du mit "Daten" umgehst weil man "so" mit SQL nicht vernünftig arbeiten kann.

Wäre schön, wenn man belastbare Infos bekommen könnte - zu den Features wie zu den Terminen.

Informationen ergeben sich aus Ergebnissen.
Dazu muss man sich "nur" die letzte CTP installieren und PostgreSQL "lernen" ...

PostgreSQL : Das offizielle Handbuch, ISBN 3-8266-1337-6

[peterdahlmann]

Danke für Deinen Hinweis auf CTP. Werde mich mal ranmachen.
Nach meiner Meinung macht es natürlich keinen Sinn Postgres prinzipiell wie xBase anzusteuern. Aber wenn man zumindest alte Programmteile "nur" durch den Austausch der Treiber weiterhin benutzen könnte und dann bei den neuen Teilen die Vorteile von Postgres ausreizt, dann wäre das schon super.
Ich habe mal vor einigen Jahre in einem größeren Bahn-Projekt als Projektleiter in einer sehr großen Anwendung Postgres eingesetzt. Da kannviel machen - viel richtig und ganz viel falsch. Bin auf jeden Fall gespannt.