Die Version 5.8.01, die in Kürze freigegeben wird, enthält die Unterstützung für 64-bit-Datensatz-IDs. Welche Vorteile diese Erweiterung bringt und welche Konsequenzen sich daraus ergeben, erklärt der folgende Artikel.
Einleitung
Die Datensatz-ID ist Bestandteil eines jeden, in der Datenbank abgelegten, Datensatzes und kennzeichnet diesen (innerhalb seiner Tabelle) eindeutig. Die Datensatz-ID wird vom Datenbank-Server anhand des sogenannten Prime-Counters vergeben. Hierbei handelt es sich um einen 32-Bit breiten, vorzeichenbehafteten Wert, der pro Tabelle verwaltet wird. Eine neu angelegte Tabelle besitzt zunächst den Prime-Counter 0. Werden Datensätze eingefügt, dann ändert sich der Wert des Prime-Counters fortwährend. Mit jedem eingefügten Satz reduziert sich also die Anzahl der zu Verfügung stehenden Datensatz-IDs. Das Löschen eines Satzes hingegen verändert den Prime-Counter nicht, so dass es bei sehr vielen Lösch- und Einfüge-Operationen zwangsläufig zu einem Überlauf des Prime-Counters kommt. In diesem Fall können ohne weitere Maßnahmen keine Datensätze mehr in die Tabelle eingefügt werden.
Ein Zurücksetzen des Prime-Counters ist nur möglich, wenn die Tabelle keine Datensätze enthält. Bei einem Überlauf besteht die Konsequenz also darin, die bestehenden Datensätze auszuspielen, den Prime-Counter zurückzusetzen (Recover durchführen) und anschließend die Datensätze wieder einzuspielen. Der Prozess kann je nach Datenvolumen und vorhandenen Schlüsseln sehr lange dauern. Des Weiteren ist der nächste Überlauf absehbar, da sich an der zugrunde liegenden Problematik nichts geändert hat.
Umstellung auf 64-Bit
Da der Prime-Counter durch einen 32-Bit-Wert dargestellt wird, ergibt sich ein Wertebereich von -2.147.483.647 bis +2.147.483.647. Hieraus ergibt sich eine maximale Anzahl von 4.294.967.295 Einfügeoperationen bis es zum Überlauf kommt. Die Lösung des Problems ist die Umstellung des Prime-Counters auf 64-Bit und damit auf über 18 Trillionen (18.000.000.000.000.000.000) unterschiedliche Ausprägungen. Hierdurch ist der Vorrat an Datensatz-IDs auf absehbare Zeit abgedeckt (Erläuterung).
Die Version 5.8.01 knüpft an die beschriebenen Überlegungen an, so dass nun die Möglichkeit existiert, Tabellen auf 64-Bit Primes umzustellen. Hierzu ist allerdings die Konvertierung der Datenbank in den Stand 5.8 notwendig.
Vergabe der Prime-Werte
Der Prime-Counter ab der Version 5.8.01 ist als 64-Bit vorzeichenloser Wert definiert. Die Datensatz-IDs sind somit alle positiv (> 0) und werden fortlaufend vergeben.
Bestehende Datensätze (aus der Version 5.7 oder früher) enthalten jedoch auch Datensatz-IDs, die negativ sind. Diese werden vom Datenbank-Server nun ebenfalls in einer positiven Darstellung zurückgegeben. Die Datensatz-ID eines bereits gespeicherten Datensatzes unterscheidet sich somit von der Datensatz-ID der Version 5.8. Wird die Datensatz-ID von der Anwendung als Referenz auf einen Zieldatensatz gespeichert, sind Anpassungen in der Anwendung notwendig, damit der referenzierte Satz gefunden wird.
Einen Blog-Artikel mit Lösungsansätzen zu diesem Thema, werden wir separat veröffentlichen.
Aktivierung der 64-Bit Datensatz-IDs
Die Aktivierung der 64-Bit Datensatz-IDs muss explizit vorgenommen werden. Aktivieren Sie hierzu das Häkchen „64-Bit Datensatz-IDs“ bei der gewünschten Tabelle im Datenstruktur-Editor (siehe Abb.1).
Abb.1: Aktivierung der 64-Bit VerarbeitungDie Aktivierung kann unter folgenden Bedingungen nicht ausgeführt werden (Häkchen ist ausgegraut):
- Es handelt sich um eine untergeordnete Datei.
- Die Option „sequentielles Einfügen“ ist nicht gesetzt.
- Der Prime-Counter (ersichtlich rechts oben im Datenstruktur-Editor) ist größer 0xFAFFFFFF.
Für untergeordnete Tabellen ist eine Aktivierung nicht erforderlich, da die Verarbeitung über die Hauptdatei definiert wird.
Für Dateien ohne sequentielles Einfügen sind 64-Bit Datensatz-IDs nicht möglich. Soll die Aktivierung dennoch erfolgen, muss die Option „sequentielles Einfügen“ aktiviert werden. Dies ist allerdings nur möglich, wenn die Datei leer ist.
Ist der Prime-Counter größer dem Grenzwert 0xFAFFFFFF müssen die Datensätze exportiert, der Prime-Counter zurückgesetzt und anschließend die Datensätze wieder importiert werden.
In den überwiegenden Fällen wird es jedoch so sein, dass diese Grenze nie erreicht wurde. Damit kann durch einfaches Setzen der Option die 64-Bit Datensatz-IDs aktiviert werden. Das oben beschriebene langwierige Verfahren (Export/Import der Datensätze) entfällt komplett.
Überprüfung bestehender Tabellen
Damit bereits vor dem Umstieg auf die Version 5.8 überprüft werden kann, bei welchen Tabellen der Prime-Counter evtl. überschritten (also > 0xFAFFFFFF) ist, steht am Ende des Artikels eine kleine Prozedur zur Verfügung. Diese analysiert den Prime-Counter aller in der Datenbank vorhandenen Tabellen und generiert einen Status-Code gemäß dem Ampel-System. Nach dem Starten der Prozedur in der zu untersuchenden Datenbank wird eine Textdatei generiert und angezeigt:
Prime-Statistik für Datenbank MyDataBase
Datei : 1
Prime : -20.000
Verbrauchte Prime-Werte : 20.000
Verfügbare Prime-Werte (5.7) : 4.294.947.295 (99%)
Verfügbare Prime-Werte (5.8) : 4.194.283.999 (99%)
Verwendung für Version 5.8 : grün
Datei : 2
Prime : -2
Verbrauchte Prime-Werte : 2
Verfügbare Prime-Werte (5.7) : 4.294.967.293 (99%)
Verfügbare Prime-Werte (5.8) : 4.194.303.997 (99%)
Verwendung für Version 5.8 : grün
* Zusammenfassung
2 Dateien überprüft.
2 Dateien mit Status grün.
Keine Datei mit Status gelb.
Keine Datei mit Status rot.
________________________________________________________
grün : Die Datei ist ohne Änderung in Version 5.8 verwendbar.
gelb : Die Datei ist in der Version 5.8 verwendbar. Es sollten jedoch die 64-Bit Datensatz-IDs aktiviert werden.
rot : Es sind keine Prime-Werte mehr verfügbar. Zur Verwendung mit Version 5.8 müssen die Datensätze ausgespielt,
ein Recover durchgeführt und anschließend die Datensätze wieder eingespielt werden.
Für jede Tabelle werden die verbrauchten und die verfügbaren Prime-Werte angezeigt. Im obigen Beispiel der Datenbank ‚MyDataBase‘ gibt es zwei Tabellen, beide mit Status ‚grün‘, da noch 99% verfügbare Prime-Werte vorhanden sind. In der Zusammenfassung am Ende der Ausgabe wird angezeigt, wie viele Tabellen mit Status grün, gelb und rot existieren. Danach folgt die Erklärung der Farben:
- grün : Die Datei ist ohne Änderung in Version 5.8 verwendbar. Ein Überlauf des Prime-Counters ist noch nicht erfolgt.
- gelb : Die Datei ist in der Version 5.8 verwendbar. Es sollte jedoch die 64-Bit Datensatz-IDs aktiviert werden.
- rot : Es sind keine Prime-Werte mehr verfügbar. Der Überlauf des Prime-Counters ist bereits erfolgt. Zur Verwendung mit Version 5.8 müssen die Datensätze ausgespielt, ein Recover durchgeführt und anschließend die Datensätze wieder eingespielt werden. Danach sollte die 64-Bit Datensatz-IDs für die Tabelle aktiviert werden.
Aussicht
Im zweiten Teil des Artikels wird darauf eingegangen, warum für die prozedurale Verarbeitung von 64-Bit Datensatz-IDs auch Anpassungen einiger conzept 16-Befehle notwendig sind.
17 Antworten
Aktuell gibt es keine Möglichkeit zu ermitteln, ob bei einer Tabelle die Option "64-Bit Datensatz-IDs" gesetzt ist. Wir können das aber gerne als Erweiterungsvorschlag aufnehmen.
Gibt es eine Auskunftfunktion welche Tabelle 32-/64-bit hat?
Bei vorhandenen Tabellen ist das Setzen nur sinnvoll, wenn zu erwarten ist, das der Prime-Counter überläuft. In diesem Fall ist auch der Prozedur-Code entsprechend anzupassen, da z.B. die von RecInfo() zurückgegebenen Datensatz-IDs nicht mehr in 32-Bit darstellbar sind (siehe auch Blog-Artikel zur "Integrierten Typkonvertierung").
Ok. Was würde denn passieren, wenn ich den 64-Bit-Haken auf der Entwicklungs-DB in jeder Tabelle setzte und diese Änderung dann per Update auf eine Kunden-DB übertragen würde, auf der der PC bereits übergelaufen ist? Vermutlich würde das Update fehlschlagen, oder? Deshalb diese Prüfung?
Abgesehen von diesem Szenario scheint ja überhaupt kein Nachteil daraus entstehen zu können, die 64-Bit-RecIds zu aktivieren und daher auch keine Notwendigkeit für eine vorherige Prüfung zu bestehen.
Nein, das ist richtig. Jedoch bietet die Version 5.8 jetzt den Vorteil, das Problem eines Überlaufes schon im Vorfeld durch die Aktivierung der 64-Bit Datensatz-IDs zu beheben, ohne zeitaufwändigen Ex- und Import von Datensätzen.
Früher oder später werden natürlich alle Datenbanken in die neue Version konvertiert werden.
Aber: Angenommen auf einer DB ist der Prime Counter in einer Tabelle übergelaufen, dann kann man in diese Tabelle keine DS mehr einfügen, EGAL ob man auf die 5.8. aktualisiert oder nicht, oder verstehe ich das falsch?
Konkret heisst dies, dass es nicht mehr möglich ist, weitere Datenätze in die Tabelle einzufügen. Der Datenbank-Server würde in diesem Fall die Meldung "Prime counter overflow" im Datenbank-Log generieren. Ansonsten kann normal auf der Tabelle gearbeitet werden (lesen,löschen,modifizieren).
Den Überlauf würden Sie also erst beim Einfügen von Datensätzen feststellen.
Deshalb ist eine Überprüfung mit der angehängten Prozedur sinnvoll. Es brauchen auch nur Datenbanken überprüft werden, die in die Version 5.8 konvertiert werden.
Ich meine umgekehrt: Falls ersteres 🙂
Hm, die Frage ist, wie dieser Satz aus dem Beitrag zu verstehen ist: "Zur Verwendung mit Version 5.8 müssen die Datensätze ausgespielt, ein Recover durchgeführt und anschließend die Datensätze wieder eingespielt werden."
Soll das heissen, ansonsten kann man die Version 5.8 gar nicht verwenden oder nur: ansonsten kann man die neuen 64-Bit RecIds nicht verwenden?
Falls letzteres, dann müsste man wohl oder übel sicherheitshalber jede Datenbank kontrollieren, bevor dort ein Update eingespielt wird.
Das ist richtig. Im Normalfall weichen die Prime-Counter einer Entwicklungsdatenbank von den Werten der Datenbank eines Kunden ab. Daher sollte die Prozedur auf der Kunden-Datenbank durchgeführt werden. Wie bereits von Michael erwähnt, besteht aber in den allermeisten Fällen kein Handlungsbedarf, da der Grenzwert von 4.294.967.295 nicht so ohne weiteres erreicht wird.
Ich denke schon, aber vielleicht hat ja morgen einer meiner Kollegen einen Tipp =).
Merci.
Ich habs mal durchlaufen lassen, bei mir ist alles grün :-). Aber eigentlich muss ich das ja jetzt bei jeder Kunden-Datenbank durchführen, bevor ich dort ein Update auf 5.8.01 durchführe, oder?
Sie haben Recht =). Ich habe die Prozedur korrigert.
Die Prozedur PrimeTest liefert bei mir einen Laufzeitfehler "Typkonvertierung nicht möglich" auf zeile 52 🙂
Mein Client ist 5.7.10j, daher ist DbaClnRelSub = 106 und lässt sich also nicht als zweistelliger String darstellen, was der Code aber voraussetzt.
Ich habe den Blog-Artikel etwas angepasst:
– Bezüglich der 18 Trillionen Grenze habe ich im Absatz "Umstellung auf 64-bit" einen Link (auf einen älteren Blog-Artikel) zur Erläuterung hinzugefügt.
– In den allermeisten Fällen wird die Grenze (0xFAFFFFFF) bei bestehenden Tabellen nicht erreicht sein. Somit ist ein Export- und Import von Daten (wie dies in vorherigen Versionen von CONZEPT 16 der Fall war) überflüssig. Es braucht lediglich die Option "64-Bit Verarbeitung" aktiviert zu werden. Das habe ich im letzten Absatz unter "Umstellung auf 64-bit" hervorgehoben.
Die ersten beiden Fragen werden im nächsten Teil des Blog-Artikels behandelt.
Die 18 Trillionen ergeben sich, weil 64-bit insgesamt 18.446.744.073.709.551.616 = 2^64 verschiedene Werte abdeckt.
Diese Erneuerung ist natürlich absolut genial, insbesondere aus längerfristiger Sicht bei stark wachsenden Datenbeständen.
Entsprechend weist sie jedoch dem bisher weniger verbreiteten Datentyp Big Integer (ganzzahlig 64) eine ganz neue Bedeutung zu. Aus diesem Grund stellen sich mir momentan folgende Fragen:
– Datensatzauswahlen werden gerne in einer dynamischen Struktur (Cte-List / Cte-Tree) zwischen gespeichert. Dies trifft bekanntlich auch auf das Multi-Select bei RecLists zu, deshalb ist eine entsprechende Lösung offenbar bereits gegeben. Wird die Eigenschaft «spID» von Cte-Items ebenfalls 64-Bit-Zahlenwerte aufnehmen können bzw. wird es eine «spID64»-Eigenschaft geben?
– Bekanntlich unterscheiden sich die Datentypen Byte (int8), Word (int16) und Integer (int32) lediglich durch deren Wertebereich. Wird es künftig möglich sein, auch das Format Big Integer (int64) wie einen normalen ganzzahligen Wert zu verwenden, ohne den Zusatz «b» bei Konstanten oder CnvBI()- bzw. CnvIB()-Befehle verwenden zu müssen? Dies würde das ganze Handling stark vereinfachen.
– Weniger bedeutend, da auch 9 Trillionen bereits eine gigantische (bzw. «exantische») Menge sind: Bekanntlich wird künftig auf das Vorzeichen bei RecIDs verzichtet. Mir ist deshalb unklar, wie es technisch möglich ist, bis zu 18 Trillionen unterschiedliche Ausprägungen darzustellen, ohne auf den Datentyp Decimal (256-Bit) auszuweichen.
Wie dem auch sei. Es ist ein sehr interessanter Artikel. Auf jeden Fall freue ich mich auf den zweiten Teil und die Freigabe der 5.8.01.