Index-Organisation im Netzbetrieb

Beitrag von **henxl** » Do, 23. Feb 2006 11:29

Hallo,

mein Programm lief bisher nur im Einzelplatzbetrieb (Daten- und Indexdateien in einem Ordner). Ich verwende NTX.
Nun will ich das Programm auf Netzbetrieb umstellen. Ich habe in den Foren einiges gelesen über die Organisation der Indexdateien und bin als "Nicht-Profi" einigermaßen verwirrt über den optimalen Weg.

Ein Neuaufbau beim Öffnen einer Datei kommt für mich nicht in Frage, weil es zu lange dauert. Deshalb meine Frage:

Ist es besser, die Indexdateien zusammen mit den Daten im Netz abzulegen, so dass jeder Benutzer dieselben Indexdateien öffnet (geht das überhaupt ?) oder ist es besser, dass jeder Benutzer auf seinem PC eigene Indexdateien erstellt, die dann bei jedem Öffnen aktualisiert werden müssen ?
Kann ich das mit NTX-Dateien realisieren oder verwende ich besser CDX ?

Wenn jemand bereit ist, mich telefonisch zu beraten, bin ich gerne bereit, seine Zeit zu vergüten.

Vielen Dank.

Heinz

PS. Ich hoffe, ich langweile nicht mit meiner "Anfängerfrage".

Beitrag von **Martin Altmann** » Do, 23. Feb 2006 11:34

Hallo Heinz,
ich denke mal, die Indexdateien lokal zu halten, ist vom eigentlichen Programmablauf her schneller! Jedoch entspricht ein Reorganisieren ja einem Neuaufbau - und wenn das für Dich nicht in Frage kommt...
Wie sieht es denn aus mit einem "richtigen" Wechsel? Also am besten gleich zu SQL - da brauchst Du Dich um sowas nicht im Detail kümmern, da der Server seine Indexe selber verwaltet...

Viele Grüße,
Martin

Beitrag von **Manfred** » Do, 23. Feb 2006 11:50

Hallo Heinz, hallo Martin,

im Moment bin ich etwas verwirrt....
Wenn das Programm im Netzwerk betrieben werden soll, dann kann ich doch davon ausgehen, dass es von mehreren Benutzern gleichzeitig genutzt werden soll?!

Wieso soll dann der Index lokal gehalten werden? Das wäre doch vollkommener Unsinn?

Außerdem habe ich bisher festgestelt, dass eine Netzwerkanwendung, die einen Fileserver benutzt, immer schneller war, als eine lokale Anwendung. Hat mich zwar auch ein wenig nachdenklich gestimmt, aber ich gehe mal davon aus, dass ein Fileserver das Caching dazu besser organisieren kann weil er für sowas ausgelegt ist.

Was das Tempo angeht, bzgl. des Indexaufbaus, so mußte ich in den letzten Wochen (hier nachzulesen:

http://www.xbaseforum.de/viewtopic.php?t=80 )
doch feststellen, dass es verdammt schnell gehen kann, wenn es richtig gemacht wird und wenn die Satzmenge nicht in astronomische Höhen steigt.

Aber ich bin gerne bereit auch hier zu lernen: Also warum sollte ein Index lokal abgelegt werden, wenn das Programm im Netzwerk laufen soll?

Beitrag von **Martin Altmann** » Do, 23. Feb 2006 12:21

Hallo Manfred,

Manfred hat geschrieben:Also warum sollte ein Index lokal abgelegt werden, wenn das Programm im Netzwerk laufen soll?

nicht, dass ich im Netz arbeite. Aber so, wie ich das verstanden habe, wird die NTX-Indexdatei auch gelockt, wenn einer einen Eintrag ändert/hinzufügt.
Das Problem hast Du natürlich nicht, wenn Du der Einzige bist, der auf den Index zugreift.
Mit der nächsten Xbase++-Version soll es diese Locking Probleme bei der NTX-Indexdatei wohl nicht mehr geben.

Viele Grüße,
Martin

Beitrag von **henxl** » Do, 23. Feb 2006 12:21

Hallo Martin und Manfred,

vielen Dank für Eure schnellen Antworten.

Ich werde mich wohl dafür entscheiden, von NTX auf CDX umzustellen und die Indexdateien im Netz abzulegen.

Obwohl dann neue Fragen auftreten, bspw. wie organisiere ich den Neuaufbau, wenn andere Benutzer noch mit dem defekten Index "unterwegs" sind.

Grüße

Heinz

mini990 · Beitrag von **mini990** » Do, 23. Feb 2006 12:29

Eigentlich ist es der normale Weg, Dateien und Indizes auf dem Server abzulegen. Die Dateien werden im Netz "shared" geöffnet und jeder kann dann mit den Dateien und vorhandenen Indizes problemlos arbeiten.
Eine lokale Ablage der Indizes bringt eigentlich keinen Vorteil, da für eine Reindiziereung sowieso die Datei selbst gesperrt werden muß (außer man verwendet extended Locking). Daß der lokale Indexaufbau prinzipiell schneller ist bezweifle ich jetzt mal. Dies hängt doch sehr stark von der verwendeten Hardware ab.
"Sicher" funktionieren NTX Dateien auf dem Server allemal. Bei unserer Anwendung (der Hauppteil läuft noch in Clipper) arbeiten zwischen 2 und 15 User immer zeitgleich. Es wird auf über 100 verschiedene Dateien mit Indizes zugegriffen, die größten Dateien haben in der Regel mehr als 200.000 Datensätze.
Probleme mit Indexdateien gibt es eigentlich nur bei Stromausfall bzw. Ausschalten des Rechners. Dies fange ich beim Start der Anwendung mit gezielten Indexabfragen ab. Defekte Indexdateien werden an dieser Stelle automatisch neu gebildet...

Eine Sperrung des Index kommt nur im Moment des Schreibens zum Tragen. Dieser Moment ist sooooo kurz, daß kein anderer Anwender etwas davon merkt...

Gruß Stefan

Beitrag von **Manfred** » Do, 23. Feb 2006 12:34

Hallo Martin,

Mit der nächsten Xbase++-Version soll es diese Locking Probleme bei der NTX-Indexdatei wohl nicht mehr geben.

Huch, die nächste xBase++ Version? Welche meinst Du denn? 2.x????

Hallo Heinz

Obwohl dann neue Fragen auftreten, bspw. wie organisiere ich den Neuaufbau, wenn andere Benutzer noch mit dem defekten Index "unterwegs" sind.

Hm, nun, die Db und die Indexdateien werden auf jeden Fall shared geöffnet, wenn alles ok ist. Wenn Du einen Index aufbauen willst, dann muß natürlich alles Exclusive geöffnet werden.

Sollte es darum gehen, wie Du den anderen klarmachen kannst/willst, das sie das Programm verlassen sollen/müssen um einen index aufzubauen, dann würde ich zu dem "Trick" greifen, einfach ein Dummyfile leer anzulegen, wonach immer wieder zwischendurch gesucht wird auf der HD. (index.txt) oder so. Sobald ein Programm dieses File findet, weiß es, dass es beenden muß und/oder den Indexaufbau anwirft. Das kann natürlich auch noch verfeinert werden....

Beitrag von **Martin Altmann** » Do, 23. Feb 2006 12:39

Hallo Manfred,

Manfred hat geschrieben:Huch, die nächste xBase++ Version? Welche meinst Du denn? 2.x????

so schnell sch**ssen die Preußen nicht - nenee

Ich meinte latürnich die 1.9. Aber es soll wohl für das Problem mit den NTX-Dateien auch schon einen PFL geben...

Viele Grüße,
Martin

Beitrag von **henxl** » Do, 23. Feb 2006 12:48

Hallo mini990,

wie fragst Du ab, ob eine Indexdatei nicht aktuell bzw. defekt ist ?
Ich habe das mal übers Dateidatum versucht, habe es aber wieder verworfen, weil das Dateidatum der Db auch geändert wird, wenn die Db nicht geändert wurde.

Gruß

Heinz

Beitrag von **henxl** » Do, 23. Feb 2006 12:54

Hallo Manfred,

vielen Dank für den Tipp mit dem temporären File (index.txt). Gute Idee, wede ich "dranbleiben".
Ich hätte allerdings auch selbst auf diese Idee kommen können, zumal ich lokal beim Programmstart einen Errorflag in die registry schreibe und ihn bei normalem Programmende wieder lösche. Ich der Flag beim nächsten Programmstart noch gesetzt, also das Programm nicht normal beendet worden, werden ein Datenbankcheck durchgeführt und die Indexdateien neu aufgebaut ...

Gruß

Heinz

Beitrag von **Manfred** » Do, 23. Feb 2006 12:55

Hallo Heinz,

lies Dir mal aus Spaß den Thread über Indextreiber durch.

Wenn es dafür ein nettes Rezept geben würde, dann wären sehr wahrscheinlich viele Menschen glücklicher.....

mini990 · Beitrag von **mini990** » Do, 23. Feb 2006 13:36

Hallo Heinz,
die Indizes frage ich in zwei Schritten ab.

1. Schritt: Öffnen der Indexdatei.
-> falls korrupt ergibt das eine Fehlermeldung -> Neuaufbau

2. Schritt
ich arbeite die Datei sequenziell ab und prüfe bei jedem Skip ob ich mit einem seek beim gleichen Satz ankomme.
Ist dies nicht der Fall baue ich die Datei neu auf.

Sofern man mit Bildschirmausgaben während der Prüfung (Schritt 2) sehr sparsam ist bzw. ganz darauf verzichtet läuft das ganze schnell genug ab.

Gruß Stefan

Beitrag von **Manfred** » Do, 23. Feb 2006 13:48

Hallo Stefan,

Wenn Du beim Öffnen direkt eine Fehlermeldung erhälst... Prima, Glück gehabt.

wie groß sind die DB mit denen Du es sequentiell testest?

Wie lange dauert es bei Deinen DB Größen?

Ich habe da so meine Zweifel, wenn man in den 100.000er Bereich kommt.

mini990 · Beitrag von **mini990** » Do, 23. Feb 2006 14:44

Hallo Manfred,
der "Glücksfall" tritt normalerweise bei Stromausfall auf.
Bei Schritt 2 prüfe ich die Haupt-Arbeitsdateien. Dies sind 14 Stück mit insgesamt 17 Indizes. Abhängig vom Anwender haben einzelne dieser Dateien weit über 100.000 Datensätze. Momentan liegt die größte bekannte Datei bei ca. 175.000.
Habe diesen Anwender gerade angerufen. Er "schätzt" die Startzeit des ersten Arbeitsplatzes auf 15-30 Sekunden.
Die anderen starten dann normal schnell....

Eingesetzte Rechner beim Anwender sind Standard-Bürorechner mit 2.4GHz und 256MB RAM, MS W2K.
Der Server läuft unter Novell, 1GHz, 512MB RAM, allerdings mit SCSI-Platten und Raid Level 5

Gruß Stefan

Beitrag von **Manfred** » Do, 23. Feb 2006 15:08

Hallo Stefan,

Stromausfall, hm, das hatte ich vergessen. Das ist natürlich der "Glücksfall". Aber ansonsten muß man eben anders herangehen. Das stimmt.

Wie ist denn der Ablauf? Wird das Programm über Tag nie verlassen? Woher weiß das Programm, das es zum 1.Mal gestartet wurde? Was passiert, wenn das Programm offiziell verlassen und danach wieder aufgerufen wird?

Nur mal so aus Neugier, wie andere so Probleme lösen

Beitrag von **henxl** » Do, 23. Feb 2006 15:27

Hallo Manfred,

oben habe ich ausgeführt, dass ich dann, wenn ein Programm nicht odnungsgemäß beendet wurde, immer die Indexdateien neu aufbaue (Errorflag in der Registry). Soviel zu dem "Glücksfall".
Schwieriger finde ich die Prüfung, ob eine Indexdatei fehlerhaft oder nicht aktuell ist.

Gruß

Heinz

Beitrag von **Manfred** » Do, 23. Feb 2006 15:39

wer antwortet denn jetzt wem?????

mini990 · Beitrag von **mini990** » Do, 23. Feb 2006 15:55

@Manfred:
ich versuchs mal zu erklären.....
beim Starten des Programms schreibe ich eine Kennung in die Datei User.
Hier wird erkannt ob bereits User in der Anwendung sind
Die Kennung ist immer eindeutig (bei Novell-Netz Netzwerkkarten-ID, bei Windows-Netz Windows-PC-Name).
Beim ordentlichen Beenden des Programms wird die Kennung wieder entfernt (der Satz gelöscht).
Weiter "senden" die Stationen alle 2 Minuten "ihre Kennung" an die Datei User um zu signalisieren daß sie noch "da" sind. (Dies passiert um nach unerwartetem Programmende den Satz mit der "Kennung" wieder zu löschen bzw. "freizugeben".)

Normalerweise laufen die PC's den ganzen Tag im Programm.
Wenn wirklich alle Stationen die Anwendung tagsüber das Programm beenden und der erste wieder startet wird der Indexcheck neu durchgeführt.

Der ursprüngliche Grund für die "User-Datei" war allerdings ein ganz anderer. Nachdem nicht an allen Stationen Drucker installiert sind/waren, beim Druck jedoch in der Regel bestimmte Formulare verwendet werden müssen war vor vielen Jahren bei etlichen "Novell-Profis" die Anforderung eine entsprechende Novell-Queue einzurichten zu groß. Daher habe ich damals eine programminterne Druckverwaltung eben mit Hilfe dieser User-Datei programmiert.

Über das Zeitproblem beim durchführen hatten wir uns damals auch schon Gedanken gemacht (die Technik war ja noch.....). Die Satz-Indexprüfung kann auch sprungweise durchgeführt werden (d.h. man prüft einfach nur jeden 10. oder 50. oder ?? Satz)

Puuuh viel Text.
ich hoffe die "Erklärung" ist verständlich....

Gruß Stefan

Beitrag von **henxl** » Do, 23. Feb 2006 15:59

Hallo Manfred,

sorry, scheinbar gibt es ungeschriebene Regeln, die ich als Neuling nicht kenne. Ich bin davon ausgegangen, dass eine konkrete Antwort an eine bestimmte Person trotzdem ...

In einer Diskussion versuche ich es zu sagen, wenn ich glaube, etwas zu sagen zu haben ...

Gruß

Heinz

kuhno · Beitrag von **kuhno** » Do, 23. Feb 2006 15:59

Hallo zusammen,

ich betreue ein Clipperapplikation, die ich z.Zt. auf XBASE umstelle. Es sind bis zu 50 Clients angeschlossen, die alle mit dem selben Programm arbeiten. Beim Start des Progs prüfe ich auf dem Server, ob in einem bestimmten Unterverzeichnis eine Datei mit dem Namen des Arbeitsplatzes und der Persnr des Nutzers vorliegt. Ist die vorhanden mach Prog eine kontrollabrage an den User und beendet. Dabei wird diese Datei gelöscht. Nun also Neustart der Prog s und anlegen einer log-Datei.

Index und Datenbasen liegen alle im gleichen Verzeichnis auf dem Server. Probleme gibt es bei großen DBFs ( ab ca. 70 000 Datensätzen). Nicht bei den DBFs selbst, sondern es treten Randeffekte auf. Die DBFs sind aber immer konsistent. Bei der Arbeit werden je User ca. 15 DBFs geöffnet. Zwei davon mit jeweils 15 Indexdateien, der Rest mit zwei bis max. 5 Indexen. Das Zeitproblem der Indexführung sind die beiden DBFs mit den 15 Indexen.

Das soll aber jetzt geändert werden mit PostgreSQL.

Gruß
Manfred

Beitrag von **Manfred** » Do, 23. Feb 2006 16:07

Hallo Heinz,

puh, nix mit ungeschriebenen Regeln, oder so.

Ich hatte Stefan geantwortet und mich vorher vergewissert, dass er nicht schon erklärt hatte, wie er das Problem löst.

Dann kam Deine Antwort und ich dachte: "Oh, Manfred Du Depp, hast dem total falschen geantwortet, bzw. die Frage gestellt." Dann habe ich Dir geantwortet und nach der Einstellung der Antwort festgestellt, dass ich doch richtig lag. Jetzt war ich aber vollkomen konfus und habe die Anwort wieder gelöscht und nur noch gefragt, wer denn jetzt wem überhaupt antwortet um wieder ins Konzept zu gelangen.

Also keine Sorge von wegen Neuling, Regel usw.

Iss scho recht

Beitrag von **Tom** » Do, 23. Feb 2006 16:59

Huhu.

Die Indexdateien werden im Shared-Betrieb bei allen möglichen Operationen (Skip, Seek usw.) gelockt, um sicherzustellen, daß der Datensatz während der Operation aktuell ist, aber nur für minimale Sekundenbruchteile. NTX lockt dabei die komplette Indexdatei, CDX unterstützt in der "normalen" 1.82 bereits ein sogenanntes "Extended Locking", das nur den Datensatz in der INDEXDATEI (!) sperrt, der betroffen ist (beim Locate aber dann alle nacheinander, die durchsucht werden). Es gibt zur 1.82 einen Fix, der Extended Locking auch für DBFNTX zur Verfügung stellt. Aber: Das alles ist bei Applikationen, die nicht datenkritisch sind (mehrere hunderttausend Datensätze pro Datei, sehr viele Arbeitsplätze im Netz), völlig irrelevant, weil man es schlicht nicht spürt. Xbase versucht das Locking der Indexdatei auch automatisch mehrfach nacheinander (man hat als Programmierer keinen Einfluß auf das Locking der Indexdateien), und man kann für datenkritische Applikationen festsetzen, wie oft und in welchen Zeitabständen das gemacht werden soll:

Code: Alles auswählen

  DbeInfo(COMPONENT_ORDER,NTXDBE_LOCKRETRY,20000000)
  DbeInfo(COMPONENT_ORDER,NTXDBE_LOCKDELAY,10)

Zusätzlich kann man, wenn man den Fix zur 1.82 hat, Extended Locking aktivieren:

Code: Alles auswählen

  DbeInfo(COMPONENT_ORDER,DBE_LOCKMODE,LOCKING_EXTENDED)

Das ist im Hinblick auf Indexdateien das einzig wichtige bei der gemeinsamen Nutzung von Datenbanken. Im Normalfall dürfte das, wie gesagt, nicht zu spüren sein. Eine "normale" Anwendung hat in diesem Bereich keine Probleme. In Ausnahmefällen entstehen mal korrupte Indexe (siehe von Martin verlinkte Diskussion), dann führt man einen Reindex durch.

Zusammenfassend: Wenn man vom Einzel- auf den Mehrplatzbetrieb umschaltet, muß man als Programmierer hauptsächlich dafür sorgen, daß in den Datendateien die Datensätze gesperrt und entsperrt werden, die verändert oder gelöscht werden. Die Index aktualisiert die DBE immer automatisch. Man muß sich um derlei nicht kümmern. Und es sollte auch so gut wie keinen Einfluß auf das Laufzeitverhalten haben.

Ergänzung: Und natürlich ist es blanker Unsinn, die Indexdateien lokal zu halten.

Beitrag von **Manfred** » Do, 23. Feb 2006 17:13

Ach Tom,

jetzt haben wir so schön darüber diskutiert, Punkte gesammelt und Du tauchst auf, schreibst einen Text und alles scheint geklärt....

Spielverderber

Beitrag von **Tom** » Do, 23. Feb 2006 17:31

Schulljung.

Beitrag von **Tom** » Do, 23. Feb 2006 17:33

Noch eine Ergänzung:

Hier unterscheidet sich Xbase++ ganz wesentlich von Clipper. Clipper hat "indefinite lockretries" durchgeführt, also schlimmstenfalls bis zum Sanktnimmerleinstag versucht, den Index zu sperren (je nach RDD). Xbase++ hat diese o.g. definierbaren Parameter. Und, wie gesagt - bei einer "kleinen" Applikation mit ein paar tausend Datensätzen und drei, vier Arbeitsplätzen im Netz ist das normalerweise alles zu vernachlässigen.