Es gab bereits einen Artikel bei uns, welcher sich mit Blockchain Tables auseinandersetzte. Jedoch kam nun die Frage auf, was denn der Unterschied zu Immutable Tables sei, welche ebenfalls mit dem 21c Release hinzukamen.
Die Gemeinsamkeiten sind offensichtlich. Beide Tabellen sind nachträglich nicht mehr anpassbar. Lediglich Deletes, anhand von der initialen Tabellen Erstellung, sind möglich.
Wenn wir die Syntax vergleichen, sehen wir direkt ein paar Unterschiede:
CREATE BLOCKCHAIN TABLE test_blockchain_table (NAME VARCHAR2(128), HIRE_DATE DATE, SALARY NUMBER)
NO DROP UNTIL 31 DAYS IDLE
NO DELETE until 30 days after insert
HASHING USING "SHA2_512" VERSION "v1";
CREATE IMMUTABLE TABLE test_immutable_table(NAME VARCHAR2(128), HIRE_DATE DATE, SALARY NUMBER)
no drop until 31 days idle
no delete until 30 days after insert;
Wir sehen, dass die Syntax beinahe identisch ist. Lediglich der Objektname ist unterschiedlich und die HASHING-Klausel fehlt. Letzteres ist im Endeffekt der gravierende Unterschied.
Da der Hash bei Immutable Tables fehlt, können Daten nicht mehr innerhalb der Datenbank verändert werden. – Aber was ist, wenn eine Änderung außerhalb der Datenbank stattfinden (OS Tools etc.)?
Dies würde bei Immutable Tables vermutlich nicht auffallen. Bei Blockchain Tables hingegen sorgt die Verschlüsselung der Rows mittels HASH dafür, dass bei Änderungen alle darauffolgenden Rows nicht mehr übereinstimmen und somit die Anpassung sofort auffällt.
Das ist ein Tausch von Sicherheit gegen Performance. Das Verschlüsseln der Daten mittels Hash kostet einiges an Zeit. Nach internen Tests im schlimmsten Fall bis zu 6x mehr als Immutable Tables und im Idealfall sind diese bis zu 35x schneller.
Sidenote:
Wenn Sie selbst die Tests nachspielen wollen, bedenken Sie: Das Hashing der der Blockchain Table findet erst BEIM commit statt. Der Insert ohne commit sollte bei beiden Tabellen Typen etwa gleich schnell sein.
Ein lang ersehntes Feature hat es endlich in den neusten DB Release geschafft. – Eine Checksum-Funktion für Datapumps.
Es bestand schon immer die Möglichkeit Dumpfiles der Datapumps mit wenig Energie und einem HEX Editor anzupassen und so Datensätze zu verfälschen. Von Strings bis Numbers, kann alles nach Belieben angepasst werden.
Eine Checksum-Funktion verhindert dies, da, wie der Name schon verrät, eine Checksum für das exportierte File erzeugt wird. Diese kann dann beim Import eingelesen werden. Sollte sich an dem Dump auch nur ein Byte geändert haben, stimmen die Checksums nicht mehr überein und der Datapump bricht ab. Wir empfehlen, dieses Vorgehen in Zukunft als Standard zu etablieren, um Sicherheit zu haben.
Hier ein kleines Beispiel wie schnell es funktioniert und im Anschluss die Nutzung des Checks um Parameter:
Diese Werte exportieren wir aus der Ursprungstabelle:
Nach dem erfolgreichen Export öffnen wir das Dumpfile und passen eine Kleinigkeit an - von...
...zu:
Jetzt importieren wir das Ganze normal:
Der neuste Mitarbeiter „Daniel“ ist nun eingetragen und keiner hat etwas mitbekommen.
Mit den Parametern:
lässt sich das verhindern.
Spielen wir das gesamte Szenario noch einmal durch, jedoch diesmal beim Exportieren mit dem
Checksum-Parameter und beim Import mit dem Verify:
Im Export Log findet sich folgender Hinweis:
Nach dem Anpassen mit einem HEX Editor führen wir nun einen Import aus:
Wie wir sehen, bricht der Import ab, da sich die Checksum nach dem Anpassen geändert hat. Somit ist sichergestellt das keine auf dem OS manipulierten Daten aus dem Dumpfile in der Datenbank landen.
Keine Sorge! Der Dump ist nicht verloren. Sollte nun doch das Interesse bestehen zu prüfen, wieso die Daten anders sind, gibt es natürlich immer noch die Möglichkeit den kompromittierten Dump ohne den Import-Parameter in eine Testdatenbank zu laden. So können die fehlerhaften Daten geprüft werden.
Mit 21c kommt eine Ergänzung am Protokollverhalten der Datenbank.
Bis dato war das Alert.log das Heiligtum jedes DBAs. In 21c könnte sich dies ändern. Im Laufe der Jahre wurde das Alert.log immer voller und ist übersät mit Informationen, die teilweise sehr stark verwirren und in der Masse irreführend sind.
Das neu eingeführte Attention.log hilft in Zukunft bei der Fehleranalyse. Es ist ein in JSON formatierte nutzbare Datei, welche alle Infos direkt im Vorfeld klassifiziert und kategorisiert und in einem bestimmten Format zur Verfügung stellt. Somit sind auch Daten kompakter und besser verwaltbar. Hier ein kleiner Ausschnitt aus dem neuen Log nach dem Neustart einer Datenbank:
Wie wir sehen können, erzeugt dieses Szenario lediglich zwei „INFO“-Events, welche sofort wichtige Infos liefern. Zusätzlich können wir es nun in diverse JSON Tools einbinden.
Im Ganzen bringt die 21c interessante Neuigkeiten mit. Neben den hier ausgeführten gibt es noch viele weitere Dinge. Unter anderem:
Gerne beraten wir Sie bei Fragen und Problemen. Kontaktieren Sie uns gern über unsere Hotline oder per E-Mail.
In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den
Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.