Kürzlich fragte mich ein Kollege nach den Unterschieden und den Einsatzmöglichkeiten der beiden neuen Tabellentypen Blockchain und Immutable Tables.  
Was sind eigentlich native Oracle Blockchain und Immutable Tabellentypen? Kurz zusammengefasst handelt es sich um spezielle Tabellentypen, die für unveränderliche Tabellen gedacht sind, die nur INSERT-only verwendbar sind und die – je nach Auswahl des Typs – zusätzlichen Schutz und Sicherheit bieten. Damit eröffnet sich ein weites Feld von neuen Möglichkeiten für Anwendungen mit der Oracle Datenbank. 

Wozu gibt es zwei verschiedene Datentypen? Zuerst wurde der Blockchain Tabellentyp im Pre-Release 20c eingeführt. Mittlerweile ist er in 23ai, 21c und auch in 19c ab er Version 19.10 in der Oracle Datenbank verfügbar. Jede Zeile einer Blockchain Table ist mit der vorherigen Zeile durch einen kryptografischen Hash verkettet. Der Hash-Wert einer Zeile wird auf der Grundlage der Zeilendaten und des Hash-Werts der vorherigen Zeile in der Kette errechnet, so dass jede mögliche Änderung und Manipulation einer Zeile aufgedeckt bzw. mit einer speziellen Verifikationsprozedur überprüft werden kann. Die Möglichkeit zusätzlich User Signaturen zu hinterlegen, erhöht dabei die Sicherheit gegen Manipulationen.
Eine ausführliche Beschreibung mit Beispielen findet man in folgendem älteren deutschsprachigen Blog siehe https://blogs.oracle.com/coretec/post/blockchain-inside-oracle-database

Immutable Tables hingegen besitzen diese zusätzlichen Sicherheitsmechanismen wie Hashing und Signaturen nicht. Sie stellen somit eine “abgespeckte” Form des Blockchain Tabellentyps dar.
Ein kurze Gegenüberstellung der Eigenschaften findet man auch im Handbuch in der Tabelle 20-8 Differences Between Immutable Tables and Blockchain Tables

Ein kurzer Vergleich der Eigenschaften findet sich im Administrator’s Guide (see table Table 19-8 Differences Between Immutable Tables and Blockchain Tables).
Update 2025: Die Erweiterungen in 23ai blockchain kann man here finden.

Gemeinsamkeiten und Unterschiede im Detail

Beide Tabellentypen sind für unveränderliche, INSERT-only Tabellen gedacht. Verfügbar sind sie out-of-the Box ab 21c. Möchte man die Technologien in 19c verwenden, ist mindestens das Release Update 19.10 für Blockchain und 19.11 für Immutable Tables erforderlich. Unbedingt beachten muss man dabei, dass der COMPATIBLE Parameter dazu verändert werden muss. Ansonsten erhält man beispielsweise im Falle von Blockchain Tables folgende Fehlermeldung:

SQL> CREATE BLOCKCHAIN TABLE block.test_blockchain 
     (test VARCHAR2(128), t NUMBER) 
     NO DROP UNTIL 1 DAYS IDLE 
     NO DELETE UNTIL 16 days after INSERT 
     HASHING USING "SHA2_512" VERSION "v1"; 

CREATE BLOCKCHAIN TABLE block.test_blockchain 
(test VARCHAR2(128), t NUMBER) 
* ERROR at line 1: ORA-00406: 
COMPATIBLE parameter needs to be 19.10.0.0.0 or 
greater ORA-00722: Feature "Blockchain table"


Welche Implikationen das Setzen von COMPATIBLE haben kann, sollte dabei berücksichtigt  werden. Mike Dietrich hat diese Thematik in einem seiner Blog Posts gut dokumentiert – siehe https://mikedietrichde.com/2021/02/18/oracle-database-19-10-0-and-blockchain-tables-and-compatible/. In meinem Fall ist COMPATIBLE auf 19.11 gesetzt worden, so dass beide Features in den folgenden Beispielen verwendet werden können.

Beide Tabellentypen sind für unveränderliche, reine INSERT-Tabellen vorgesehen. Beide Tabellentypen werden unter Verwendung der Hidden-Columns-Funktionalität in Oracle Database implementiert, verfügen jedoch über eine eigene Paket- und Data-Dictionary-View-Infrastruktur. Das folgende Beispiel zeigt die Erstellung einer BLOCKCHAIN-Tabelle in Oracle Database.  Die NO DROP-Klausel bestimmt, wie lange die Tabelle vor dem Löschen geschützt ist – in unserem Fall 1 Tag. Die NO DELETE-Klausel bestimmt die Aufbewahrungsfrist. Wie lange jede Zeile vor dem Löschen geschützt ist.

Anmerkung:

Blockchain-Tabellen können nicht im Root-Container und in einem Anwendungs-Root-Container erstellt werden. Der Initialisierungsparameter COMPATIBLE muss auf 19.10.0.0 oder höher gesetzt werden, um eine V1-Blockchain-Tabelle zu erstellen, und auf 23.0.0.0 oder höher, um eine V2-Blockchain-Tabelle zu erstellen.
Sie müssen die Version angeben, wenn Sie eine Blockchain-Tabelle erstellen, entweder V1 oder V2. Die Version V2 erzeugt zusätzliche von Oracle verwaltete versteckte Spalten als V1.
Ein detaillierte Beschreibung des CREATE TABLE Klausel findet sich here.

SQL> CREATE BLOCKCHAIN TABLE BLOCKC_v1 (test VARCHAR2(128), t NUMBER)
     NO DROP UNTIL 1 DAYS IDLE
     NO DELETE UNTIL 16 DAYS AFTER INSERT
     HASHING USING "SHA2_512" VERSION v1;
Table created 

SQL> CREATE BLOCKCHAIN TABLE BLOCKC_v2 (test VARCHAR2(128), t NUMBER)
     NO DROP UNTIL 1 DAYS IDLE
     NO DELETE UNTIL 16 DAYS AFTER INSERT
     HASHING USING "SHA2_512" VERSION v2;
Table created.

Eine Abfrage auf die Spalten – auch die Hidden Columns, ergibt dann folgendes Ergebnis.

SQL> SELECT test, t,
ORABCTAB_SPARE$,ORABCTAB_USER_NUMBER$, ORABCTAB_HASH$,
ORABCTAB_SIGNATURE$, ORABCTAB_SIGNATURE_ALG$, ORABCTAB_SIGNATURE_CERT$,
ORABCTAB_SEQ_NUM$, ORABCTAB_CHAIN_ID$, ORABCTAB_INST_ID$, ORABCTAB_CREATION_TIME$
FROM blockc_v1;

TEST
--------------------------------------------------------------------------------
         T
----------
ORABCTAB_SPARE$
--------------------------------------------------------------------------------
ORABCTAB_USER_NUMBER$
---------------------
ORABCTAB_HASH$
--------------------------------------------------------------------------------
ORABCTAB_SIGNATURE$
--------------------------------------------------------------------------------
ORABCTAB_SIGNATURE_ALG$ ORABCTAB_SIGNATURE_CERT$         ORABCTAB_SEQ_NUM$
----------------------- -------------------------------- -----------------
ORABCTAB_CHAIN_ID$ ORABCTAB_INST_ID$
------------------ -----------------
ORABCTAB_CREATION_TIME$
---------------------------------------------------------------------------
test
         1

                  136
556BC29D35C670F311A03FEA5F37B0E6B8209E9CEAAFF986009256383BAE4BAF93937EC3D8C338E1
846EDF25780C58A930AB42DCA46DD4F87A6D44A9BC77AA38

                                                                         1
                19                 2
22-MAY-25 10.23.27.712315 AM +00:00

Führt man dieses Beispiel mit dem Tabellentyp IMMUTABLE aus, sieht das Beispiel folgendermaßen aus:

SQL> CREATE IMMUTABLE TABLE test_immutable (test VARCHAR2(128), t NUMBER)
     NO DROP UNTIL 1 DAYS IDLE
     NO DELETE UNTIL 16 DAYS AFTER INSERT; 
Table created.
SQL> insert into test_immutable values ('I1',1);
1 row created.

SQL> commit;
Commit complete.

SQL> select * from dba_immutable_tables;

SCHEMA_NAME
--------------------------------------------------------------------------------
TABLE_NAME      ROW_RETENTION ROW_RETEN TABLE_INACTIVITY_RETENTION
--------------- ------------- --------- --------------------------
TABLE_VERSION         CURRENT_EPOCH
--------------------- -------------
DELETE_TIME
---------------------------------------------------------------------------
SCOTT
TEST_IMMUTABLE             16 NO                                 1
V1                                1


Wie man erkennen kann, wird nur eine hidden Column gefüllt – nämlich ORACTAB_CREATION_TIME$. 

Arbeiten mit BLOCKCHAIN und IMMUTABLE Tabellen

Wie kann man mit diesen neuen Tabellentypen arbeiten? In Applikationen lassen sich damit normale Datenbank- und reguläre Tabellen in Abfragen und Transaktionen mischen. Wie gerade demonstriert wurde, können beispielsweise wie gewohnt INSERT-Statements durchgeführt werden. Um Testtabellen auch wieder entfernen zu können, ist ein DROP TABLE- Kommando möglich gemacht worden – allerdings nur wenn eine NO DROP UNTIL – Klausel im CREATE TABLE verwendet wurde. Operationen wie UPDATE, MERGE und Änderungen an Spalten sind natürlich gemäß Definition nicht erlaubt. Das Löschen von Zeilen hingegen kann ermöglicht werden, falls die Klausel NO DELETE UNTIL verwendet wurde. Hierzu gibt es spezielle Funktionen der Packages DBMS_IMMUTABLE_TABLE bzw. DBMS_BLOCKCHAIN_TABLE. Weitere Oracle Datenbank-Operationen sind natürlich möglich – darunter auch das Anlegen von Views und Indizes und vieles mehr. 
Allerdings gibt es auch Einschränkungen, über die man im Handbuch mehr erfahren kann. Hier sind die beiden zugehörigen Links aus der aktuellen 19c Dokumentation:

Alle “Standard” Datentypen werden unterstützt; Datentypen wie Object Types, BFILE, XMLTYPE usw.  werden allerdings nicht unterstützt. Einschränkungen gibt es auch bei der Verwendungen von DIRECT PATH LOADs, Flashback Table oder beim Oracle Data Pump Import und Export. So werden BLOCKCHAIN und IMMUTABLE Tables als reguläre Tabellen exportiert und importiert. 

Fazit

Immutable und Blockchain Tables sind wichtige Features der Oracle Converged Datenbank. Damit ist es möglich Blockchain- oder Insert-Only Anwendungen zentral in der Datenbank abzulegen und zu verwalten. Bei der Verwendung in 19c ist zu beachten, dass der Parameter COMPATIBLE angepasst werden muss. Falls es nur um die Unveränderbarkeit der Tabellen geht, sollte man sich für das Feature IMMUTABLE Table entscheiden. Das Befüllen von weniger Hidden Columns bedeutet nämlich, daß man weniger Ressourcen und Verarbeitungszeit benötigt, und man mit einer besseren Performance beim Befüllen der IMMUTABLE Tables rechnen kann. Ansonsten lohnt ein Blick in das Handbuch (siehe Links), dort werden die beiden Technologien ausführlich beschrieben.

Links