riesige DBF-Dateien, sprunghaftes Ansteigen der Datensätze

[Chris]

Hallo,

ich habe bei einem Kunden das Problem, dass während des arbeitens mit dem Programm bzw. eventuell auch bei der Indizierung vereinzelt DBF-Dateien entweder auf 2 GB Größe ansteigen oder aus unerfindlichen Gründen plötzlich mehrere Millionen Datensätze haben. Nach umkopieren und append der Datensätze ist auch alles wieder in Ordnung. Aber ich kann nicht nachvollziehen warum und wann das ganze passiert.

Hatte von euch schon mal jemand ein solches Problem. Wenn ja, wie habt ihr es lösen können.

Die Systeme auf denen dies passiert sind jeweils aktuelle Windows Server 2008, 64 bit, teilweise R2. Das ganze tritt hin und wieder auf, lässt sich aber nicht reproduzieren.

Vielleicht weiss ja jemand was dazu.

Danke schonmal.

Gruß,
Christian

[brandelh]

Riecht das nicht nach dem Problem mit den MetaDaten ? Eventuell lokale Caches ...

Um eine "gleichberechtigte" Nutzung von gesharten Dateien zu erzwingen, soll man ein kleines Programm erstellen,
das alle Dateien einmal öffnet und dann einfach nichts tut. Dann würde der Server die DBF nicht in den Cache des Clientrechners schaufeln.

Weiterhin gibt es verschiedene Einstellungen bei Servern und Clients eingestellt werden sollen/müssen, wurde schon häufig diskutiert.

[AUGE_OHR]

2 GB ...

em ... äh ... und welche DBF Grösse sollten sie haben ?
um über 1GB zu kommen MUSST du die DBESYS geändert haben, bitte zeig die uns mal.

ist denn was in den grossen DBF "drin" ? kannst du die überhaupt noch öffnen ?

du spezifizierst zwar das OS() des Server, aber was hast du als Client OS() und welche Xbase++ Version / Hotfixe ? NTX oder CDX ?

wäre auch nicht schlecht zu erfahren was der User gemacht hat ... ein "Logbuch" hilft in solchen Fällen weiter.
auch in das Logbuch des Servers sollte man ab und zu mal schauen ...

[Chris]

Also die Clients haben meistens Windows XP SP 3 mit aktuellen Hotfixes und Updates.

XBase liegt hier in der Version 1.90.355 zu Grunde, auch hier die aktuellen Hotfixes von Alaska verwendet.

Die Datenbanken selbst sollten keine 2 GB groß sein und auch nicht die Menge an Daten enthalten. Eigentlich sollte diese nur etwa 20 - 30 MB haben. Hatte das gleiche heute erst bei einer Datenbank welche 27 Datensätze hatte und plötzlich knapp 1 Mio. Datensätze. Die muss ich mir aber noch ansehen, da diese erst kurz vor der Indizierung so groß geworden ist und auch sonst nur lesend im Zugriff ist, ausser eben bei der Indizierung.

Code: Alles auswählen

DbeLoad( "ADSDBE", .F.)
DbeLoad( "DBFDBE", .T.)
DbeLoad( "NTXDBE",.T.)

DbeBuild( "DBFNTX", "DBFDBE", "NTXDBE" )

DbeSetDefault("DBFNTX")

DbeInfo( COMPONENT_DATA , DBFDBE_LOCKRETRY, 100000 )
DbeInfo( COMPONENT_DATA , DBFDBE_LOCKDELAY, 20  )
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKRETRY, 100000 )
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKDELAY, 20  )

Weiterhin gibt es verschiedene Einstellungen bei Servern und Clients eingestellt werden sollen/müssen, wurde schon häufig diskutiert.

Kannst du mir einen Hinweis geben wo ich das finde, ohne jetzt lang suchen zu müssen?

[AUGE_OHR]

Die Datenbanken selbst sollten keine 2 GB groß sein und auch nicht die Menge an Daten enthalten. Eigentlich sollte diese nur etwa 20 - 30 MB haben. Hatte das gleiche heute erst bei einer Datenbank welche 27 Datensätze hatte und plötzlich knapp 1 Mio. Datensätze. Die muss ich mir aber noch ansehen, da diese erst kurz vor der Indizierung so groß geworden ist und auch sonst nur lesend im Zugriff ist, ausser eben bei der Indizierung.

20 - 30 MB und dann geht die "hoch" ?

du sprichst auch von Indizierung ... "kurz vorher" ... machst du was "kurz vorher" ?

Code: Alles auswählen

DbeLoad( "ADSDBE", .F.)
DbeLoad( "DBFDBE", .T.)
DbeLoad( "NTXDBE",.T.)

DbeBuild( "DBFNTX", "DBFDBE", "NTXDBE" )

DbeSetDefault("DBFNTX")

DbeInfo( COMPONENT_DATA , DBFDBE_LOCKRETRY, 100000 )
DbeInfo( COMPONENT_DATA , DBFDBE_LOCKDELAY, 20  )
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKRETRY, 100000 )
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKDELAY, 20  )

also NTX ... verwendest du die zusammen/gleichzeitig mit Cl*pper ?
wenn ja, hast du bei Cl*pper das NTXLOCK2.OBJ eingebunden ?
wenn ja musst du auch

Code: Alles auswählen

DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKOFFSET, 0xFFFFFFFF ) 

eintragen, aber NUR dann wenn du Cl*pper gleichzeitig mit NTXLOCK2.OBJ verwendest.

... Windows Server 2008, 64 bit, teilweise R2

Also die Clients haben meistens Windows XP SP 3 mit aktuellen Hotfixes und Updates.

XBase liegt hier in der Version 1.90.355 zu Grunde, auch hier die aktuellen Hotfixes von Alaska verwendet.

Kannst du mir einen Hinweis geben wo ich das finde, ohne jetzt lang suchen zu müssen?

XP und W2K8 macht zwar Probleme aber "das" Problem hab ich noch nicht gesehen.

was die "Workarounds" angeht reicht es von neuen Redirector bis hin zum "disable" SMB2, aber die "richtige" Lösung heisst XP raus und Win7 verwenden.

[Wolfgang Ciriack]

Hallo,
ich habe das Problem jetzt bei einem Kunden das 2.Mal erlebt (unter Win7).
Programm schmiert ab, eine Datenbank (bei beiden Malen eine andere) hat dann eine Größe von
2.097.153 KB !
Bevor ich jetzt endlos teste, hat jemand eine Idee, wie man diese DBF wieder "reparieren" kann ?

[Tom]

Hallo, Wolfgang.

Lässt sich die DBF noch mit irgendeinem Tool sichten, etwa dem DBF-Plugin für Ghislers "Total Commander"? Es kann zuweilen geschehen, dass sich innerhalb einer eigentlich korrekten Tabelle Fremddaten befinden, etwa durch falsche Schreibvorgänge u.ä. (physische Ursachen). Dann sieht man verschobene/inhaltlich falsche Datensätze. Die sollten sich eigentlich auch löschen lassen. Und 2 GB ist unter Normalbedingungen eben die Größengrenze. Gut möglich, dass die DBE dann durchdreht.

[UliTs]

Ich hatte im Frühjahr die DBF von Mirco mit Low-Level-Zugriffen repariert, die ca. 2,5 GB groß war.
Wenn Du keine schnelle Lösung findest, kann ich mir die Tabelle gern anschauen.

Uli

[Wolfgang Ciriack]

Das muss ich heute abend erst einmal ausprobieren, bin z.Zt. noch unterwegs.

@Uli,
komme evtl. auf dein Angebot zurück.

[Wolfgang Ciriack]

Ja, mit dem DBU oder Total Commander lässt sich die DBF noch öffnen.
Die ersten 211 Datensätze sind auch noch ok, dann kommt irgendeine Verschiebung der Daten.

Muß morgen mal mit einem Editor ran, um zu sehen, ob man die Verschiebung wieder herausbekommt.

[UliTs]

Hallo Wolfgang,

Genau so eine Verschiebung gab es damals bei Mirco auch...
Uli

[AUGE_OHR]

... aber leider haben wir ja nicht raus bekommen "was" dass Problem verursacht

auch hier zunächst die Frage ob die DBF schon "vorher" > 1GB war oder "nur" paar hundert MB ?
"Stamm" Datei (wenig Änderungen ) oder "Bewegungs" Datei ( viele Änderungen) ?

nun öffnet man ja eine DBF nicht ohne Index ... CDX oder NTX ? wie viele TAGs ?
Ich habe das Problem noch nicht gehabt aber ich "denke" das zunächst der Index "kaputt" geht ...

[Wolfgang Ciriack]

Da dieses Problem bisher nur an diesem einen PC jetzt zum 2. Mal auftaucht, vermute ich einen Defekt in der Hardware (RAM ?).
Die DBF müsste so ca. 1000 - 2000 Datensätze (unter 1MB) enthalten haben, sie hat 3 CDX-Indexdateien mit insgesamt 14 Tags.

[UliTs]

... aber leider haben wir ja nicht raus bekommen "was" dass Problem verursacht

Hallo Jimmy,

ich weiß nicht was "Ihr" nicht raus bekommen habt
Bei Mirco war die Ursache ja eindeutig: eine Fehlbedienung des Anwenders, wodurch viel zu viele Datensätze in die Tabelle eingefügt wurden und dadurch die 2 GB-Grenze weit überschritten wurde.

Wolfgang:
Gibt es eine Sicherung der Tabelle (gegebenenfalls auch etwas älter), die mit der aktuellen verglichen werden kann?
Kann zur Zeit ohne diese Tabelle weitergearbeitet werden?

Uli

[Wolfgang Ciriack]

Hallo Uli,
die gute Nachricht: weitergearbeitet werden kann erst mal, habe die vorhandene DBF erst einmal durch eine leere ersetzt.
die schlechte: Wie das bei einigen Firmen so ist, Datensicherung wird nicht konsequent durchgeführt, trotz fortwährender Hinweise. Soll ich die die DBF mal zusenden (emal-Adresse ?)

[UliTs]

Ja, gern.
Ich habe Dir ne PN zugeschickt.
Uli

[Wolfgang Ciriack]

Danke, ist unterwegs.