Feb. 2006 Der Chefentwickler der Parity Software, Schwieberdingen bei Stuttgart nennt in einem Interview Qt, Perl und db++ seine bevorzugte Entwicklungsumgebung, mit der man Anwendungssoftware so flexibel und effizient, wie es sich nur wünschen lässt, entwickeln kann. Er freut sich noch heute über den Hinweis der Concept asa vor acht Jahren auf Qt, das damals zur Entscheidung gegen Java und Nutcracker anstand.

Jan. 2006 Die Exact Software Deutschland, München liefert wie jedes Jahr den Update für ihr Lohn- und Gehaltsabrechnungssystem LohnXL/XXL mit dem Datenbankkern db++ auf Windows für über 10.000 Installationen aus.

Sept. 2005 Die Parity Software, Schwieberdingen bei Stuttgart liefert nach umfangreichen Tests mit ihrem Applikations-Simulationsprogramm dbstresser die Version 8.11.29 an ihre Kunden aus.

Sept. 2005 Auslieferung eines spezifisch auf die Belange der dsoftware, Neuss zugeschnittenen Updates, das mit der dort eingesetzten ASS-Entwicklungsumgebung und db++ Variante kompatibel ist. Wesentlich ist dabei die Möglichkeit, Tabellen mit mehr als 2GB Größe auf der 32Bit-Betriebssystemvariante von Linux und ab Dez. 2005 auch auf Windows einzusetzen.

2004/2005 Der David Concept asa zwingt in einem langwierigen Markenrechtsstreit den Goliath DB AG in die Knie. Seit September 1997 versuchte die Concept asa die Marke db++ nicht nur als Bildzeichen, da war es schon seit 1990 in Deutschland und im Ausland geschützt, sondern auch als Wortzeichen schützen zu lassen. Nach anfänglichen Widerständen gelang dies im Februar 2001. Die Freude bei der Concept asa währte jedoch nicht lange, da die DB AG im Oktober 2002 erfolgreich die Löschung der Wortmarke erreichte. In einer endgültigen Verhandlung vor dem 27ten Senat des Bundespatentgerichtes Ende August 2004 setzte sich die Concept asa aber abschließend durch. Das Wortzeichen db++ ist jetzt endgültig alleiniges Eigentum der Concept asa. Wir sind jedoch nicht nachtragend und fahren weiter auf Fernreisen bevorzugt mit der Bahn, sofern wir nicht unseren bescheidenen Geschäftswagen, einen 3L-Lupo, gemäß dem Motto „db++ ist das 3L-Auto unter den Datenbanksystemen - schlank, schnell und effizient“, benutzen.

2003/2005 Entwicklung der db++ Versionen 8.11.19 bis 8.11.31. Im Einzelnen erfolgten dabei folgende Erweiterungen/Optimierungen:

Wenn im folgenden viel über Performancegewinne berichtet wird, dann heißt dies nicht, dass db++ bisher langsam gewesen ist; im Gegenteil db++ war bisher schon immer sehr schnell – es ist aber unser Ehrgeiz weiterhin zu den schnellsten Datenbanken zugehören, ganz abgesehen davon dass ein erfolgreiches Optimieren unsere Kunden und uns selbst immer wieder neu motiviert.

in 2003

1. Beginn der völligen Integration der Linux/Unix und Windows Makefilesysteme mit dem Ziel, dass ein simples „make“ genügt, um db++ auf allen Plattformen zu kompilieren.
   
2. Übertragung und erste Implementation der für EADS Airbus für Sun Sparc entwickelten Möglichkeit Tabellen >2GB zu verwenden auf die Betriebssysteme Linux und Windows.
   
   
3. Dabei im Linux/Unix-relevaten Teil des Sourcecodes Ersetzen der letzten verbliebenen nicht-posix-konformen Aufrufe durch posix-konforme. In der neuen 2005 fertig entwickelten >2GB-Version von db++ werden jedoch unter Windows nicht mehr die orginalen Posix-Aufrufe genutzt, sondern interne native, effizientere Windows Input/Output Calls von einem posix-liken Interface aus, da sich in der Windows-Umgebung die orginalen Posix-Aufrufe als zu langsam erwiesen haben.
   
   
4. Es erfolgte ein teilweises Redesign des Mapping-Mechanismus, der virtuelle Tabellennamen den realen Direktories auf den verschiedenen Host Rechnern und db-Servern zuweist, was im RELFTAB-File spezifiziert wird, um die Transparenz zwischen Linux/Unix und Windows in heterogenen Umgebungen zu erhöhen.
   
   
5. Erweiterung der cdbFind() und cdbCount() Routinen im einzelnen:
   (a) Sowohl cdbFind() als auch cdbCount() können veranlasst werden, einen “Buffer” mit Datensätzen zurückzugeben. Standardmäßig können so 8 Kilobytes an Datensätzen bei einem Aufruf gepuffert werden; darüberhinaus kann aber auch die Anzahl der Datensätze für den Puffer in den Argumenten der erweiterten Routinen vorgegeben werden. Subaufrufe mit cdbCount() können vorgenommen werden bis end-of-scan erreicht ist.
   (b) Bei Setzen eines neu eingerichteten Flags, kann optional eine Suchoperation ausgelöst werden, bei der der Status der letzten Suche (des letzten Scans) erhalten bleibt. D.h. es werden zunächst nur die ersten 10 Datensätze des neuen Scans retourniert, wobei die folgenden cdb_next(), cdb_previous() etc. Operationen jedoch auf den alten Scan zurückgreifen.
   
   
6. Beim ersten Handshake zwischen einem Client-Programm und einem db-Server wird festgestellt, ob Client und Server denselben Endian verwenden. Wenn dies der Fall ist, werden die Daten als kompakter Opaque Data Block anstatt eines Vielfachen von unterschiedlichen Datentypen transferiert. Dadurch wird die Anzahl der XDR Aufrufe signifikant reduziert.
   
   
7. Der alte ODBC-Treiber „dbq“ wurde durch Erweiterungen an „dbquery“ ersetzt. Der neue Treiber unterstützt dabei nicht nur ODBC sondern auch native AQL und SQL Queries. Dies macht die undokumentierte, aber bisher oft genutzte Funktion aqlexec() überflüssig.
   
   
8. Eine in einer älteren Version von db++ kundenspezifisch schon einmal implementierte Optimierung der dbServer „Browse“-Routinen (cdb.next() et al.) steht jetzt für die Version 8. allgemein zur Verfügung. Durch eine Vorabmarkierung der Key Positionen (first, last) wird bei einem unvollständig definierten Constraint unnötiges sequentielles Suchen gezielt verhindert. Darüberhinaus wird eine Suche sofort abgebrochen, wenn cdb_setindex() erkennt, dass ein oder mehrere Suchkriterien mit keinem Spaltennamen matchen. Auch damit werden große Tabellen nicht unnötig lange bis zum Ende durchsucht.
   
   
9. Erste Performancetest mit dem in Zusammenarbeit mit der Parity Software GmbH entwickelten Programm dbstresser, das eine typische kommerzielle Applikation simuliert. Dies ist die Basis für das Profiling mit dem begeisternden „kcachegrind“ Tool. Dabei konnten viele Einsichten für zusätzliche Performance-Verbesserungen gewonnen werden, insbesondere durch das Vermeiden von teueren System und Library Calls (allein das Vermeiden von sprintf()-Aufrufen bringt eine Verbesserung von 10% für den dbServer).
   
   

in 2004

1. Diverse kleinere Optimierungen
   (a) Benutzung von assembly für string comparison.
   (b) Einsatz einer modifizierten Fibonacci-Funktion zur Vermeidung zeitaufwendiger String-Length-Recalculationen bei jedem Insert, was vor allem bei multiplen Inserts ins Gewicht fiel. Dass dabei manchmal die Formatierung mit den db++internen Ouput-Routinen nicht ganz perfekt ausfällt ist vernachlässigbar, da diese ja in der Regel meist durch applikationsspezifische Ausgabemöglichkeiten ersetzt werden.
   (c) Zusätzlicher Secondary Cache zum schnelleren Auffinden besonders häufig benötigter Pages der Btrees.
   (d) Beim Suchen nach einer Freepage, um dort neue oder modifizierte Daten einzufügen, begann die Suche bisher am physikalischen Startpunkt des Tabellenfiles. Ein neuer Algorithmus versucht nun eine Freepage eher in der Nähe der logischen Umgebung im Btree zu finden. Zudem bewirkt dieser Algorithmus, dass die Daten von Primär- und Sekundärindizes pysikalisch separiert, d.h. geclustert werden.
   
   
2. Optimierung des Matchens innerhalb eines Constraints z.B. von cdb_find(), cdb_next() et al. durch Unterdrückung von unnötigen getprimarytuple() Calls beim Scannen eines Sekundärindizes, was in bestimmten Situationen zu einer mehr als zehnfachen Beschleunigung führen kann.
   
   
3. Vorsortieren modifizierter Pages beim Flushen vom Cache zur Festplatte unter Berücksichtigung der dort vorhandenen physikalischen Ordnung, d.h. Verwendung von Contigues-Writes anstatt von Random-Writes. Bei großen Files werden dadurch die Schreibkopfbewegungen der Plattenspeicher erheblich miniminiert.
   
   
4. Nutzung inaktiver Prozessorzeiten (Millisekunden) um gezielt Flushing-Operationen unabhängig von den Standard-Betriebssystem-Flushes vorab auszulösen und damit die Prozessorlast besser zu verteilen, steuerbar durch die Veränderung zweier Tuning-parameter in Abhängigkeit einer gewichteten Anzahl von Operationen pro Tabelle.
   
   
5. Bei allen Optimierungen von 1. bis 4. wurde das von der Firma Parity Software für Ihre Anwendungen entwickelte Programm dbstresser eingesetzt um die Wirksamkeit der Maßnahmen nachzuweisen.
   
   
6. Das Windows-Client-Programm dbodbc wurde stark überarbeitet, dabei wurden fallweise insuffiziente Query-Operationen und unerwünschte Interface-Probleme z.B. mit MS-Accesss beseitigt. Ebenso wurden Probleme, die bei der Verwendung unterschiedlicher Windows-Versionen insbesondere mit XP auftraten, gelöst.
   
   

in 2005

1. Abschließende Arbeiten am integrierten Linux/Windows-Makefilesystem. Es gibt jetzt nur einen Makefile, sodass nur ein einfaches „make“ für das Kompilieren auf beiden Plattformen genügt. Darüberhinaus wurde eine RevisionControl/History-Funktion ins Makefilesystem integriert, sodass Programme und Libraries über eingebettete Informationen zu Build-Zeitpunkt und -Nummer, und eine Gliederung nach major, minor und mini Revisions verfügen.
   
   
2. Der Large File Support, der die Verwendung von Tabellen >2GB ermöglicht, ist jetzt Standard. Die entsprechenden bisherigen Compiler Optionen können daher entfallen. Dazu wurde ein Set portabler IO-Routinen geschrieben, die Posix Calls unter Windows mit Hilfe von nativen Windows-IO-Operationen simulieren. Dies machte auch die Lösung früherer Inkompatiblitäten beim Locking in heterogenen Umgebungen möglich. Jetzt ist demnach die gleichzeitige Verwendung von nativen, nfs und samba Mounts möglich.
   
   
3. Nochmalige Erweiterung der cdb_find() Routine:
   (a) Eine neue Funktion “cdbFindInScan” sucht nach einem spezifischen Datensatz innerhalb eines existierenden Scans (potentiell innerhalb von tausenden Datensätzen). Diese Funktion ist besonders nützlich, wenn sie zusammen mit cdbSavePos() und cdbRestorePos() eingesetzt wird, um zwischen verschiedenen Positionen innnerhalb eines Scans zu switchen.
   (b) Die Funktion cdbFind() versucht standardmäßig immer den optimalen Index (primär oder sekundär) zu finden um die Suche zu optimieren. Dies führt dazu, dass schließlich der resultierende Scan nach dem vom Programm gewählten Index sortiert ist. Ein neues Argument führt jetzt dazu, dass der Benutzer optional einen spezifischen Index vorab definieren kann, um zu gewährleisten, dass sein Scan in einer von ihm gewünschten Sortier-Reihenfolge und nicht der vom Optimiser gewählten präsentiert wird.
   
   

Zur Zeit in Arbeit

1. Überarbeitung der ursprünglich verfügbaren Memo und Blob Fields, sodass diese nicht nur vom C-Programmierung Interface verfügbar sind, sondern völlig integriert in alle db++ Tools wie „db“, „dbedit“, „dbfsck“ and „dbodbc“.
   
   
2. Nach dem umfangreichen Rewrite in 2004 der ODBC-Client-DLL und nach den Änderungen am jetztigen ODBC-Server „dbquery“ ist die neue Version von db++ mit diesen Erweiterungen Gegenstand intesiver Beta-Tests. Darüberhinaus beinhaltet „dbodbc“ jetzt eine neue Konsolen-Utility „drvsetup“ für das Installieren und Managen von dbodbc-DLLs und Data Sources (DSNs). Diese Utility kann nahezu alles, was der Microsoft ODBC-Manager tun kann, aber von der Konsole aus. Dies wird unseren Partnern das Schreiben von Installationsskripts für ihre neuen und zukünftigen Kunden bedeutend erleichtern. Nach Abschluss der Beta-Tests erfolgt die Auslieferung der Neuen ODBC-Version zunächst über unsere Partner an ausgewählte Kunden.
   
   
3. Ein völlig neuer, nicht aus der Literatur übernommener, Algorithmus zum Sortieren eines kompletten B-trees mit linearen Sortierzeiten, auch für Tabellen > 2GB bei einem Verbrauch von < 64 K Hauptspeicher, wird implementiert. Dabei verneinen wir nicht, dass mit einigen Gigabytes von Hauptspeicher und einem entsprechend hohem Wert für DB_MAXSORTBUF ein ähnliches Ergebnis erzielt wird. Dieser z.Z. experimentelle Code wird in Kürze ins aktuelle Release integriert.