Hallo Steffen
du sprichts mich mit deinem Beitrag direkt an. Daher gehe ich nun eigentlich ungewollt, nochmals auf das Thema ein.
Ich wollte die PG-ISAM-EMU wirklich ernsthaft einsetzen und wartete auch einige Wochen auf die neue Version. Die neue Version war auch Pt.1 der Argumente um meine Sub zu verlängern.
Um den letzten Teil einer App und deren Umfangreiche Datenbestände auf Postgres zu migrieren setzte ich grosse Hoffnung auf die von euch angekündigte Super-Performance des PG-ISAM-EMU.
Damit hätte der Code der betreffenden bereits lange bestehenden App nicht verändert werden müssen. Der grosse Teil der restlichen App wurde über die letzten Jahre Stück für Stück überarbeitet und die Daten auf PG migriert.
Bei Beginn dieser Arbeiten gab es gar noch keine PGDBE so dass dazu eigene Klassen und Funktionen die direkt auf der libpq.dll (PostgreSQL Access Library) Aufbauen erstellt wurden.
Aktuelle ist die Version dieser Lib 11.0.X. Es ist das Modul welches die Kommunikation mit dem PG-Server erledigt. Auch beim Server ist die Version 11 aktuell.
Die von euch unter anderm Namen verwendete Version dieses Moduls ist die Version 8.3. Dieser Release von Client und Server stammt aus dem Jahre 2008 und wird seit mehreren Jahren nicht mehr unterstüzt und hat den Status "End of Life".
Idealerweise passt das Clientmodul zum Server hat also die selbe Version.
Bis vor kurzem war ein Upsize mit dem Upsize Tool zu einem aktuellen Postgres Server gar nicht möglich es stürzte ab. Es funktionierte nur mit einem alten Server 8.3.
Diese veraltete Serverversion steht für das von uns verwendete Unix System schon längst nicht mehr zur Verfügung.
Sie, die angesprochenen Tests sollten nun zeigen ob nun ein Upsize überhaupt möglich und wie es mit der Performance des ISAM-EMU's aussieht.
Die Tests wurde auf einem dem Zielsystem entsprechender Ausrüstung durchgeführt.
Zu Test wurden z.B. eine Datenbank DBF-File mit einem Index und ca. 535'000 Datensätzen in 10 Feldern verwendet.
Der Transfer mit dem Upsize Tool hatte Anfangs, zu beginn des Transfers eine bessere Performance nach ca. 230'000 Datensätzen wurden noch ca. 25 Datensätze/Sek. übertragen
und sank weiter auf 10 Datensätze/Sek. bis ich den Versuch abbrach.
Sicher könnte man die Daten ohne Index upsizen das geht schneller und den Index danach erstellen. Das dauert dann nur einige Stunden.
Dies ist aber nicht einmal das Hauptproblem! Das Hautproblem ist die Performance nach dem Upsize. So wie es auch andere User in diesem Thread beschrieben haben.
Der Kunde wartet doch nicht 1 Minute bis die Datenbank im ISAM-EMU Mode 100 Positionen einer Bestellung weggeschieben hat!
Was soll ich da Ihren Support kontaktieren? Wie kann mir der Support hier helfen?
Mit den oben beschriebenen Tools dauerte das Wegschreiben in eine normale PG Datenbank (die keine Alaska spezifischen Felder/Trigger hat) 0.1 Sekunden. Wie gesagt haben die Performance Probleme auch andere User in Ihren Beiträgen festgestellt.
Ich muss alle Daten bis Ende Jahr auf Postgres bringen. Nach diesen Tests mit dem PG-ISAM-EMU stand für mich fest dass ich das gesetzte Ziel nur auf anderen Wegen, nicht mit dem PG-ISAM-EMU erreichen kann. Denn der Termin ist fix und nicht änderbar. Mit den vorhandenen und mir bekannten Tools ist dieses Ziel auch mit überarbeiten des Code noch gut erreichbar. Zeit für weitere Experimente ist da aber nicht mehr vorhanden.
Deshalb soll der PG-ISAM-EMU in den tiefen MEINER Festplatten in Frieden Ruhen. Er wird von mir nicht benötigt ich muss den Zeitplan einhalten und deshalb zwingend andere Wege gehen.. RIP-ISAM-EMU
Ich bin sicher dass Ihr einige Zeit in die Entwicklung der PGDBE (nicht nur den EMU) gesetzt habt.
Es sind dabei sicher viele, viele viele gute und schöne Funktionen und Möglichkeiten entstanden und nun enthalten.
Ich würde diese auch gerne nutzen!! Nur WIE? Ihr entwicklt viele viele neue, schöne Funktionen nur gibt es dazu aber weder ausreichend Code-Bespiele noch eine Dokumenation. Viele Punkte der Doku enthalten wenn überhaupt vorhanden nur "TBD"
Lieber Steffen, wie benutzt du etwas von dem du:
a) nicht weisst dass es vorhanden ist
b) du gar keine Doku mit den zum Einsatz nötigen Infos hast
c) keine Code Bespiele zum "lernen" hast.
Möglich dass du Hellseher bist und diese Infos zum Arbeiten nicht benötigst. Leider fehlt mir die Fähigkeit des Hellsehens....
ich finde ein "RIP PG EMU" ganz schön anmaßend. Du führst Tests durch, stellst eine schlechte Performance fest und legst die DBE beiseite.
Nein. Ich finde dies nicht anmassend. Nur MEINE Entscheidung für MICH. Sie ist jetzt an meinen Aufgaben und dem gesetzten / geforderten Ziel und den heute vorhandenen Möglichkeiten orientiert.
Nachdem diese jetzt anstehende Aufgabe erledigt ist stehe ich gerne für weitere Tests zur Verfügung.....