Datenbank · ASPICON Newsarchiv

PostgreSQL 19 Beta 3 im Praxistest: Bloat mit dem neuen REPACK-Befehl beseitigen

Sebastian Naumann — Thu, 17 Sep 2026 06:19:45 +0000

Home → Datenbank

PostgreSQL 19 Beta 3 im Praxistest: Bloat mit dem neuen REPACK-Befehl beseitigen

Verfasst von Sebastian Naumann
17 September 2026
08:19
Datenbank, PostgreSQL

Wenn du PostgreSQL-Datenbanken über längere Zeit betreibst, kennst du das Thema sicher: Durch UPDATE- und DELETE-Operationen entstehen Dead Tuples und Tabellen können mit der Zeit deutlich mehr Speicherplatz belegen, als es die tatsächlich vorhandene Datenmenge vermuten lässt. Ein normales VACUUM schafft hier zwar innerhalb der Relation wieder Platz für neue Daten – die physische Größe der Tabelle auf dem Dateisystem reduziert sich dadurch in der Regel jedoch nicht.

Mit PostgreSQL 19 kommt dafür eine neue Möglichkeit direkt in den Core: REPACK schreibt eine Tabelle vollständig neu und kann dadurch ungenutzten Speicher tatsächlich wieder an das Betriebssystem zurückgeben.

Das ist nicht nur aus Sicht des Datenbankbetriebs interessant. Gerade bei großen oder über Jahre gewachsenen Datenbanken kann das physische Verkleinern stark aufgeblähter Tabellen auch den benötigten Storage reduzieren und damit Ressourcen effizienter nutzbar machen.

Wie groß der Unterschied zwischen VACUUM und dem neuen REPACK in der Praxis sein kann, zeigt das folgende Beispiel mit PostgreSQL 19 Beta 3.

Testdatenbank vorbereiten

Die Testumgebung verwendet:

PostgreSQL 19beta3

Zunächst wird eine neue Testdatenbank erstellt:

createdb repacktest

Anschließend werden mit pgbench 10 Millionen Datensätze erzeugt:

pgbench -i -s 100 repacktest

Verbindung:

psql repacktest

Version:

psql (19beta3)

Datensätze prüfen:

SELECT count(*)
FROM pgbench_accounts;

Ergebnis:

count
----------
 10000000

Ausgangsgröße

Dieses Statment wird im Folgenden noch häufiger ausgeführt:

SELECT
    pg_size_pretty(pg_relation_size('pgbench_accounts'))       AS table_size,
    pg_size_pretty(pg_indexes_size('pgbench_accounts'))        AS index_size,
    pg_size_pretty(pg_total_relation_size('pgbench_accounts')) AS total_size;

Ergebnis:

 table_size | index_size | total_size
------------+------------+------------
 1281 MB    | 214 MB     | 1495 MB

Damit ergibt sich folgende Ausgangslage:

Kennzahl    |    Wert
------------+---------------
Datensätze  |    10.000.000
Tabelle     |    1281 MB
Indizes     |    214 MB
Gesamt      |    1495 MB

Bloat erzeugen

Nun werden 50 % der Datensätze gelöscht:

DELETE FROM pgbench_accounts
WHERE aid % 2 = 0;

Ergebnis:

DELETE 5000000

Anzahl der verbleibenden Datensätze:

SELECT count(*)
FROM pgbench_accounts;

Ergebnis:

count
---------
 5000000

Die logische Datenmenge wurde damit halbiert.

Physische Größe prüfen

Es wird das Statement von oben ausgeführt.

Ergebnis:

table_size | index_size | total_size
------------+------------+------------
 1281 MB    | 214 MB     | 1495 MB

Obwohl nur noch die Hälfte der Datensätze vorhanden ist, bleibt die physische Größe unverändert.
Das ist der gewünschte Bloat-Zustand.

Dead Tuples prüfen

SELECT
    relname,
    n_live_tup,
    n_dead_tup
FROM pg_stat_user_tables
WHERE relname = 'pgbench_accounts';

Ergebnis:

     relname      | n_live_tup | n_dead_tup
------------------+------------+------------
 pgbench_accounts |    4999844 |    5000000

Damit sind ungefähr 5 Millionen Dead Tuples vorhanden.

Physische Datei ermitteln

SELECT pg_relation_filepath('pgbench_accounts');

Ergebnis:

base/16858/16874

Auf Betriebssystemebene:

du -sh $PGDATA/base/16858/16874

Ergebnis:

1.1G    /opt/postgres/ASPICON/PGDATA/base/16858/16874

Auch auf Dateisystemebene wurde also noch kein Speicherplatz zurückgegeben.

Normales VACUUM

Nun wird ein normales VACUUM mit ANALYZE ausgeführt:

VACUUM (VERBOSE, ANALYZE) pgbench_accounts;

Auszug aus der Ausgabe:

INFO:  vacuuming "repacktest.public.pgbench_accounts"

pages:
0 removed,
163935 remain,
7892 scanned (4.81% of total)

tuples:
44859 removed,
4999913 remain,
0 are dead but not yet removable

index scan bypassed:
1499 pages from table (0.91% of total)
have 45991 dead item identifiers

avg read rate: 126.089 MB/s
avg write rate: 25.898 MB/s

WAL usage:
1500 records,
1452 full page images,
6256905 bytes

elapsed: 0.44 s

Anschließend wurde noch ANALYZE ausgeführt:

INFO:  analyzing "public.pgbench_accounts"

"pgbench_accounts":
scanned 30000 of 163935 pages,
containing 915067 live rows and 8777 dead rows

5000384 estimated total rows

elapsed: 0.36 s

Größe nach VACUUM

Es wird das Statement von oben ausgeführt.

Ergebnis:

table_size | index_size | total_size
------------+------------+------------
 1281 MB    | 214 MB     | 1495 MB

Die physische Größe bleibt unverändert.

Dead Tuples nach VACUUM

SELECT
    relname,
    n_live_tup,
    n_dead_tup
FROM pg_stat_user_tables
WHERE relname = 'pgbench_accounts';

Ergebnis:

     relname      | n_live_tup | n_dead_tup
------------------+------------+------------
 pgbench_accounts |    5000384 |      47962

Die Dead Tuples wurden damit von ungefähr 5.000.000 auf nur noch etwa 47.962 reduziert.

Dateisystem

du -sh $PGDATA/base/16858/16874

Ergebnis:

1.1G    /opt/postgres/ASPICON/PGDATA/base/16858/16874

Damit bestätigt sich das erwartete Verhalten:

Merkmal                 |  Vor VACUUM   |  Nach VACUUM
------------------------+---------------+----------------
Live Tuples             |  ~5 Mio.      |  ~5 Mio.
Dead Tuples             |  ~5 Mio.      |  ~48.000
Tabellengröße           |  1281 MB      |  1281 MB
Gesamtgröße             |  1495 MB      |  1495 MB
Datei im Filesystem     |  1.1 GB       |  1.1 GB

VACUUM macht den freigewordenen Platz innerhalb der Relation wiederverwendbar, gibt ihn aber normalerweise nicht an das Betriebssystem zurück.

Klassisches REPACK

Anschließend wird die Tabelle mit dem neuen PostgreSQL-19-Befehl vollständig neu geschrieben:

REPACK (VERBOSE, ANALYZE) pgbench_accounts;

Ausgabe:

INFO:  repacking "public.pgbench_accounts" in physical order

INFO:  "public.pgbench_accounts":
found 0 removable,
5000000 nonremovable row versions
in 163935 pages

DETAIL:
0 dead row versions cannot be removed yet.

CPU:
user: 14.04 s,
system: 17.55 s,
elapsed: 56.52 s

Anschließend:

INFO:  analyzing "public.pgbench_accounts"

"pgbench_accounts":
scanned 30000 of 81968 pages,
containing 1829952 live rows
and 0 dead rows

4999917 estimated total rows

Auffällig ist bereits hier die Anzahl der Seiten:

vor REPACK: 163935 pages
nach REPACK: 81968 pages

Die Anzahl der Heap-Seiten wurde damit praktisch halbiert.

Größe nach REPACK

Es wird das Statement von oben ausgeführt.

Ergebnis:

 table_size | index_size | total_size
------------+------------+------------
 640 MB     | 107 MB     | 748 MB

Damit ergibt sich:

Kennzahl  |  Vor REPACK  |  Nach REPACK  |  Veränderung
----------+--------------+---------------+--------------
Tabelle   |  1281 MB     |  640 MB       |  ca. -50 %
Indizes   |  214 MB      |  107 MB       |  ca. -50 %
Gesamt    |  1495 MB     |  748 MB       |  ca. -50 %

Das entspricht sehr genau der zuvor halbierten Datenmenge.

Dead Tuples nach REPACK

SELECT
    relname,
    n_live_tup,
    n_dead_tup
FROM pg_stat_user_tables
WHERE relname = 'pgbench_accounts';

Ergebnis:

     relname      | n_live_tup | n_dead_tup
------------------+------------+------------
 pgbench_accounts |    4999917 |          0

Nach dem Rewrite befinden sich damit keine Dead Tuples mehr in der neuen Relation.

Physischer Austausch der Relation

Besonders interessant ist die Änderung des Relation-Pfades.

Vor dem REPACK:

base/16858/16874

Nach dem REPACK:

SELECT pg_relation_filepath('pgbench_accounts');

Ergebnis:

base/16858/16884

PostgreSQL verwendet nach dem Rewrite also eine neue physische Relation.

Die alte Datei:

du -sh $PGDATA/base/16858/16874

Ergebnis:

0    /opt/postgres/ASPICON/PGDATA/base/16858/16874

Die neue Datei:

du -sh $PGDATA/base/16858/16884

Ergebnis:

641M    /opt/postgres/ASPICON/PGDATA/base/16858/16884

Ergebnis des Tests

Der Test zeigt sehr deutlich den Unterschied zwischen VACUUM und REPACK.

Ausgangszustand

10.000.000 Rows

Table:   1281 MB
Indexes:  214 MB
Total:   1495 MB

Nach dem Löschen von 50 % der Daten:

5.000.000 Live Tuples
5.000.000 Dead Tuples

Table:   1281 MB
Indexes:  214 MB
Total:   1495 MB

Die physische Größe bleibt unverändert.

Nach VACUUM

~5.000.000 Live Tuples
~48.000 Dead Tuples

Table:   1281 MB
Indexes:  214 MB
Total:   1495 MB

Der Platz ist intern wiederverwendbar, wird aber nicht an das Betriebssystem zurückgegeben.

Nach REPACK

~5.000.000 Live Tuples
0 Dead Tuples

Table:   640 MB
Indexes: 107 MB
Total:   748 MB

Damit wurden ungefähr 50 % des Speicherplatzes tatsächlich zurückgewonnen.

Zusammenfassung

Zustand        |  Live Tuples  |  Dead Tuples  |  Tabelle  |  Indizes  |  Gesamt
---------------+---------------+---------------+-----------+-----------+----------
Initial        |  10 Mio.      |  ~0           |  1281 MB  |  214 MB   |  1495 MB
nach DELETE    |  5 Mio.       |  5 Mio.       |  1281 MB  |  214 MB   |  1495 MB
nach VACUUM    |  ~5 Mio.      |  ~48 Tsd.     |  1281 MB  |  214 MB   |  1495 MB
nach REPACK    |  ~5 Mio.      |  0            |  640 MB   |  107 MB   |  748 MB

Das praktische Ergebnis lässt sich daher sehr einfach zusammenfassen:

DELETE
   ↓
Dead Tuples entstehen
   ↓
VACUUM
   ↓
Platz innerhalb PostgreSQL wiederverwendbar
   ↓
Relation bleibt physisch groß


REPACK
   ↓
kompletter Rewrite
   ↓
neue Heap-Datei
   ↓
neue Indexdateien
   ↓
physischer Platz wird zurückgewonnen

REPACK (CONCURRENTLY)

Der nächste Schritt besteht darin, denselben Test unter laufendem Workload durchzuführen.

Beispielsweise:

pgbench -c 20 -j 4 -P 5 -T 300 repacktest

Parallel dazu:

REPACK (CONCURRENTLY, VERBOSE, ANALYZE) pgbench_accounts;

Während ein normales REPACK die Tabelle durch einen ACCESS EXCLUSIVE Lock blockiert, wird dieser Lock bei CONCURRENTLY im Wesentlichen erst für den abschließenden Austausch benötigt.

Änderungen während des Neuaufbaus werden über Logical Decoding erfasst und auf die neue Relation übertragen.

Der Ablauf lässt sich vereinfacht folgendermaßen darstellen:

                  laufender Workload
                         |
                  INSERT / UPDATE / DELETE
                         |
                         v
Originalrelation --------------------------+
       |                                   |
       | bestehende Daten                  |
       v                                   |
Neue Relation                              |
       ^                                   |
       |                                   |
       +---------- Logical Decoding -------+
                         |
                         v
                  Änderungen nachziehen
                         |
                         v
                ACCESS EXCLUSIVE
                   kurzer Swap
                         |
                         v
                  neue Relation

Damit eignet sich REPACK (CONCURRENTLY) insbesondere für große Tabellen, bei denen ein vollständiger blockierender Rewrite betrieblich problematisch wäre.

Wichtige Einschränkung: nicht MVCC-safe

Die PostgreSQL-Dokumentation weist ausdrücklich darauf hin, dass REPACK (CONCURRENTLY) nicht vollständig MVCC-safe ist (MVCC = Multi-Version Concurrency Control). Das ist insbesondere für bereits laufende Transaktionen mit älteren Snapshots relevant.

Beispiel:

-- Session 1

BEGIN ISOLATION LEVEL REPEATABLE READ;

SELECT *
FROM andere_tabelle;

Damit existiert ein Snapshot, der vor dem Repack entstanden ist. Die Tabelle pgbench_accounts wurde innerhalb dieser Transaktion bislang noch nicht verwendet.

Parallel:

-- Session 2

REPACK (CONCURRENTLY) pgbench_accounts;

Nach Abschluss des Rewrite greift Session 1 erstmals auf die Tabelle zu:

SELECT count(*)
FROM pgbench_accounts;

Da die physische Relation zwischenzeitlich ausgetauscht wurde, kann die alte Snapshot-Sicht nicht in jedem Fall korrekt auf die neue Relation übertragen werden. In bestimmten Situationen kann die Tabelle für eine solche Transaktion sogar leer erscheinen.

Besonders beachten sollte man dies bei:

langen REPEATABLE READ-Transaktionen
SERIALIZABLE-Transaktionen
Reporting-Jobs
ETL-Prozessen
konsistenten Exporten
langen Batch-Prozessen

Vor einem REPACK (CONCURRENTLY) sollte daher geprüft werden, ob alte bzw. lang laufende Transaktionen vorhanden sind:

SELECT
    pid,
    usename,
    application_name,
    state,
    xact_start,
    now() - xact_start AS transaction_age
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_start;

Damit ist REPACK (CONCURRENTLY) zwar weitgehend online, aber nicht vollständig transparent gegenüber allen bestehenden MVCC-Snapshots.

Abgrenzung zu pg_repack

Der PostgreSQL-19-Befehl REPACK ist funktional sehr ähnlich zur bekannten Extension pg_repack, stellt aber keine einfache Übernahme der Extension in den PostgreSQL-Core dar. pg_repack bleibt ein eigenständiges Projekt.

Der wesentliche Unterschied liegt insbesondere in der technischen Umsetzung der parallelen Änderungen.

Die folgende Tabelle vergleicht die Eigenschaften von pg_repack und PostgreSQL-19 miteinander:

Eigenschaft	pg_repack	PostgreSQL 19
Bestandteil	externe Extension	PostgreSQL Core
Installation	zusätzlich notwendig	nicht notwendig
Bloat beseitigen	ja	ja
Tabelle neu schreiben	ja	ja
Online-Variante	ja	REPACK (CONCURRENTLY)
parallele DML erfassen	Trigger + Log-Tabelle	Logical Decoding
finaler exklusiver Lock	ja	ja
physische Relation wird ersetzt	ja	ja
Core Progress View	nein	pg_stat_progress_repack

Unsere Einordnung

Der Praxistest zeigt ziemlich deutlich, welchen Mehrwert REPACK für den PostgreSQL-Betrieb bringen kann. Nach dem Löschen von 50 Prozent der Datensätze blieb die physische Größe der getesteten Relation zunächst unverändert. Auch ein normales VACUUM reduzierte den belegten Speicher nicht. Erst REPACK schrieb die Relation vollständig neu und verringerte die Gesamtgröße im Test von rund 1.495 MB auf 748 MB – also nahezu entsprechend der zuvor halbierten Datenmenge.

Für DBAs und IT-Administratoren bedeutet das: Bloat lässt sich mit PostgreSQL 19 künftig mit einem nativen Core-Befehl nicht nur logisch bereinigen, sondern physisch aus der Datenbank entfernen. Besonders bei großen, über längere Zeit gewachsenen Tabellen kann das einen spürbaren Unterschied machen.

Und der Effekt endet nicht an der Datenbankgrenze. Wenn unnötig belegter Speicher tatsächlich an das Betriebssystem zurückgegeben wird, kann – je nach Anwendungsfall – auch der physische Storage-Bedarf der Datenbank sinken. In größeren Umgebungen kann das unter Umständen vorhandene Speicherkapazitäten besser ausnutzen und den Storage-Bedarf optimieren.

Mit REPACK (CONCURRENTLY) liefert PostgreSQL 19 außerdem eine weitgehend online nutzbare Variante für Systeme, bei denen ein länger blockierender Rewrite betrieblich kaum möglich ist. Allerdings sollten DBAs dabei die beschriebenen Einschränkungen bei langen beziehungsweise alten MVCC-Snapshots im Blick behalten.

Unterm Strich wird REPACK damit zu einem spannenden neuen Werkzeug für alle, die PostgreSQL-Datenbanken nicht nur logisch sauber, sondern auch beim tatsächlichen Ressourcenverbrauch effizient betreiben wollen.

Bitte beachte, dass REPACK Bestandteil der » PostgreSQL Version 19 ist, welche aktuell nur in der Beta 3 verfügbar ist. Wir informieren dich, sobald die Version 19 final veröffentlicht wurde.

Hier findest du weitere Infos aus der Welt von PostgreSQL aus unserem News & Insights Bereich.

Share this article

Der Beitrag PostgreSQL 19 Beta 3 im Praxistest: Bloat mit dem neuen REPACK-Befehl beseitigen erschien zuerst auf ASPICON.

DBA-Tipp: So kannst du Oracle AI Database 26ai On-Prem bereits jetzt für SE2 nutzen

Alexander Glöckner — Thu, 10 Sep 2026 12:46:20 +0000

Home → Datenbank

DBA-Tipp: So kannst du Oracle AI Database 26ai On-Prem bereits jetzt für SE2 nutzen

Verfasst von Alexander Glöckner
10 September 2026
14:46
Datenbank, Oracle, Oracle Datenbank 23ai, Oracle Datenbank 26ai

Seit Januar diesen Jahres steht die Oracle AI Database 26ai On-Premise in der Enterprise Edition für Linux x86_64 zum Download bereit. Standard Edition 2 (SE2) Kunden müssen sich laut offizieller Doku noch bis Oktober 2026 gedulden (Stand: August 2026). Aber das Image hat schon seinen Weg in den Installer gefunden.

Mit der Veröffentlichung des Juli 2026 Release Updates (RU) steht Oracle AI Database 26ai nämlich erstmals auch als Standard Edition 2 für die lokale Installation zur Verfügung. Damit können nun auch Kunden ohne Enterprise-Edition-Lizenz auf die neue Oracle-AI-Datenbankgeneration wechseln. Aktuell gilt dies allerdings nur für Linux x86_64.

Die SE2 ist Bestandteil des RU 23.26.3.0.0. Unterstützt werden unter anderem Oracle Linux und Red Hat Enterprise Linux 8, 9 und 10.

Download über My Oracle Support

Auf der regulären Oracle-Downloadseite findet man weiterhin das ursprüngliche 26ai-Installationsimage LINUX.X64_2326100_db_home.zip. Dieses Image stammt aus der ersten On-Premises-Veröffentlichung und bot bei der Installation noch keine Auswahl der Standard Edition 2.

Für SE2 führt der Weg daher aktuell über das Juli 2026 Critical Patch Update in My Oracle Support:

» Oracle Critical Patch Update (CPU) Jul 2026 for Oracle Database Products [CPU199]

Dort stehen die aktuellen Images bereit:

23.26.3.0.0 DB RU Gold Image – Patch 39581612
23.26.3.0.0 GI RU Gold Image – Patch 39581618
23.26.3.0.0 DB Client Gold Image – Patch 39599083

Das DB Gold Image enthält bereits ein vollständiges Oracle Home inklusive Release Update 23.26.3. Es handelt sich also nicht nur um einen Patch, der zunächst auf ein vorhandenes Base Release angewendet werden muss.

Installation

Das Gold Image wird direkt in das zukünftige Oracle Home entpackt:

mkdir -p /u01/app/oracle/product/26.0.0/dbhome_1
cd /u01/app/oracle/product/26.0.0/dbhome_1
unzip p39581612_230000_Linux-x86-64.zip
./runInstaller

Im Installer steht anschließend unter Select Database Edition auch Standard Edition 2 zur Auswahl.

Das neue Home kann anschließend entweder für eine neue Datenbank verwendet oder als Ziel eines Out-of-Place-Upgrades beziehungsweise der Migration einer bestehenden Datenbank genutzt werden.

SQL*Plus: Release 23.26.3.0.0 - Production on Thu Sep 10 12:07:42 2026
Version 23.26.3.0.0

Copyright (c) 1982, 2026, Oracle. All rights reserved.

Connected to:
Oracle AI Database 26ai Standard Edition 2 Release 23.26.3.0.0 - Production Version 23.26.3.0.0

SQL>

Fazit

Damit steht Oracle AI Database 26ai nun auch SE2-Kunden für klassische On-Premises-Installationen zur Verfügung – aktuell allerdings etwas versteckt über die Release-Update-Gold-Images in My Oracle Support.

Der Weg ist damit frei, deine Anwendungen auf Basis der neuen Oracle-AI-Datenbankgeneration zu entwickeln und bestehende Systeme auf 26ai zu migrieren.

Du hast Fragen oder benötigst Unterstützung?

Kontakt

Du hast Fragen oder benötigst Unterstützung?

Kontakt

Hier findest du weitere Features und Infos rund um » Oracle AI Database 26ai aus unserem News & Insights Bereich.

Share this article

Der Beitrag DBA-Tipp: So kannst du Oracle AI Database 26ai On-Prem bereits jetzt für SE2 nutzen erschien zuerst auf ASPICON.

Patch Update und Release Info PostgreSQL

Uli Lorenz — Fri, 14 Aug 2026 05:34:04 +0000

Home → Datenbank

Patch Update und Release Info PostgreSQL

Verfasst von Uli Lorenz
14 August 2026
07:34
Datenbank, PostgreSQL

PostgreSQL Patch Update: 28 Sicherheitslücken und über 110 Fehler behoben

Die PostgreSQL Community hat ein neues Update für alle unterstützten Versionen veröffentlicht: PostgreSQL 18.6, 17.11, 16.15, 15.19 und 14.24. Gleichzeitig steht mit PostgreSQL 19 Beta 3 eine neue Testversion bereit.

Das aktuelle Release behebt 28 Sicherheitslücken sowie mehr als 110 Fehler, die in den vergangenen Monaten gemeldet wurden. Darunter befinden sich mehrere Schwachstellen mit einem CVSS Base Score von bis zu 8.8, die unter anderem die Ausführung beliebigen Codes, SQL-Injection oder unzulässige Speicherzugriffe ermöglichen können.

Neben den Security Fixes bringt das Update zahlreiche Fehlerbehebungen und Verbesserungen für den Datenbankbetrieb. Dazu gehören unter anderem Korrekturen bei Partitionierung, Query Planner, Autovacuum, WAL, logischer Replikation sowie pg_dump und pg_restore.

Alle Infos zum Patch Update, den Bug Fixes und Verbesserungen findest du » hier.

Nach dem Update: Diese Punkte solltest du prüfen

Bei einigen Konfigurationen können nach dem Einspielen zusätzliche Schritte notwendig sein:

GIN-Indizes: Tabellen mit GIN-Indizes sollten auf fehlerhafte reltuples-Werte geprüft und gegebenenfalls mit ANALYZE korrigiert werden.
btree_gist: Bestimmte Indizes auf float-, bit- oder bit varying-Spalten sollten nach dem Update neu aufgebaut werden.
ltree: Bei B‑Tree-Indizes auf sehr großen ltree-Werten kann ebenfalls ein REINDEX erforderlich sein.

Ein Dump/Reload oder pg_upgrade ist für die Minor Updates grundsätzlich nicht notwendig. Die PostgreSQL Update Releases sind kumulativ und können durch Aktualisierung der PostgreSQL-Binaries eingespielt werden.

PostgreSQL 14: Support endet im November

Noch eine wichtige Info in dem Zusammenhang: PostgreSQL 14 geht am 12. November 2026 aus dem Support. Das bedeutet, dass keine Sicherheitsupdates oder Fehlerbehebungen mehr von der PostgreSQL Community zur Verfügung gestellt werden.

Für dich als IT-Administrator oder IT-Leiter ist das ein wichtiger Zeitpunkt, um aktiv zu werden. Ein veraltetes Datenbanksystem kann Sicherheitsrisiken erhöhen, die Systemstabilität beeinträchtigen und Compliance-Anforderungen erschweren.

Unsere Empfehlungen:

Prüfe bestehende PostgreSQL-14-Installationen in deinen Systemen.
Plane ein Upgrade auf eine unterstützte Version (aktuell PostgreSQL 15 oder höher).
Teste Anwendungen und Schnittstellen frühzeitig auf Kompatibilität, um Ausfallzeiten zu vermeiden.

Ein rechtzeitiges Upgrade schützt deine Daten, sorgt für Stabilität und stellt sicher, dass du weiterhin von Sicherheitsupdates profitierst.

Eine Übersicht aller Supportlaufzeiten der PostgreSQL Versionen findest du » hier.

Du hast Fragen zum Update oder benötigst Unterstützung?
Komm gern auf uns zu!

Kontakt

Hier findest du weitere Infos aus der Welt von PostgreSQL aus unserem News & Insights Bereich.

Share this article

Der Beitrag Patch Update und Release Info PostgreSQL erschien zuerst auf ASPICON.

Release Info: Oracle Database Appliance Version 19.31 veröffentlicht

Sebastian Naumann — Wed, 17 Jun 2026 06:56:26 +0000

Home → Datenbank

Release Info: Oracle Database Appliance Version 19.31 veröffentlicht

Verfasst von Sebastian Naumann
17 Juni 2026
08:56
Datenbank, Oracle

Mit der Oracle Database Appliance Version 19.31 stellt Oracle erneut zahlreiche Erweiterungen für ODA-Systeme der Generationen X8 bis X11 bereit. Neben neuen Funktionen für Oracle Data Guard und das Management der Infrastruktur stehen vor allem Verbesserungen bei Administration, Flexibilität und Speicherverwaltung im Fokus.

Die wichtigsten Änderungen haben wir hier für dich zusammengefasst. Alle Infos zum Release findest du im » Oracle Help Center oder im » Oracle Blog.

Das bringt das neue Oracle Database Appliance Release unter anderem mit:

Oracle Data Guard jetzt mit Multi-Domain-Unterstützung:

Ab Release 19.31 unterstützt Oracle Database Appliance die Konfiguration von Oracle Data Guard über mehrere Domains hinweg. Dadurch lassen sich Disaster-Recovery-Szenarien flexibler gestalten und komplexere Netzwerkstrukturen einfacher abbilden.

Alte Grid-Infrastructure-Homes einfach entfernen:

Nicht mehr benötigte Oracle Grid Infrastructure Homes früherer Releases können jetzt direkt über die Browser User Interface (BUI) oder per ODACLI gelöscht werden. Das schafft zusätzlichen Speicherplatz auf System- und Boot-Laufwerken und vereinfacht die Pflege der Umgebung.

Erweiterungen in der Browser User Interface (BUI):

Die Benutzeroberfläche wurde um mehrere praktische Funktionen ergänzt:

Erweiterung des verfügbaren /u01 ‑Speicherplatzes in DB-Systemen
Anpassung der CPU-Kernanzahl eines DB-Systems ohne Änderung des Shapes
Detailliertere Infrastrukturinformationen direkt in der Oberfläche

Diese Erweiterungen erleichtern die Administration und erhöhen die Transparenz im laufenden Betrieb.

Unterstützung für Oracle Enterprise Manager Cloud Control:

Oracle erweitert mit Release 19.31 die Unterstützung des Oracle Enterprise Manager Plug-ins für Oracle Database Appliance. In Verbindung mit Oracle Enterprise Manager Cloud Control 13c Release 5 (13.5) können ODA-Systeme ab der Hardwaregeneration X8‑2 zentral überwacht und verwaltet werden. Dies ermöglicht eine einheitliche Sicht auf die gesamte Oracle-Infrastruktur und vereinfacht das Monitoring sowie das Kapazitäts- und Performance-Management der Appliance-Umgebung.

Energieverbrauch auf ODA X11 optimieren:

Für AMD-EPYC-basierte Oracle Database Appliance X11-Systeme bietet Oracle erstmals Funktionen zur Steuerung des Energieverbrauchs. Dadurch können Unternehmen Stromkosten reduzieren und ihre Nachhaltigkeitsziele unterstützen.

Integrierte Datenbank-Updates und unterstützte Plattformen

ODA 19.31 enthält bereits die Oracle Database Release Updates vom April 2026 sowie die aktuellen Clone-Dateien für Oracle Database 19c und Oracle AI Database 26ai. Darüber hinaus können sowohl 19c- als auch 26ai-Datenbanken auf DB Systems bereitgestellt werden.

Oracle Database Appliance 19.31 unterstützt weiterhin Bare-Metal- und KVM-Deployments auf den Plattformen:

Oracle Database Appliance X8
Oracle Database Appliance X9
Oracle Database Appliance X10
Oracle Database Appliance X11

Fazit

Mit Release 19.31 setzt Oracle den Fokus auf eine vereinfachte Administration und höhere Flexibilität im Betrieb von Oracle Database Appliances. Besonders die Unterstützung von Multi-Domain Data Guard, die Unterstützung für Cloud Control sowie die Bereinigung älterer Grid-Infrastructure-Installationen bieten Mehrwert für Administratoren und Betreiber produktiver ODA-Umgebungen. Gleichzeitig sorgen aktuelle Datenbank-Updates und die Unterstützung von Oracle AI Database 26ai dafür, dass die Plattform technisch auf dem neuesten Stand bleibt.

Unser Tipp: Plane das Update frühzeitig ein – idealerweise außerhalb produktiver Zeiten. Bei der Gelegenheit lohnt es sich, bestehende Update‑, Backup- und Security-Konzepte im Zuge des Upgrades zu überprüfen und gegebenenfalls anzupassen.

Du hast Fragen zum Update oder benötigst Unterstützung?
Melde dich gern bei uns.

Kontakt

Marcel
Senior Account Manager bei ASPICON

Hier findest du weitere Infos rund um Oracle aus unserem News & Insights Bereich.

Share this article

Der Beitrag Release Info: Oracle Database Appliance Version 19.31 veröffentlicht erschien zuerst auf ASPICON.

Oracle AutoUpgrade in Oracle Database 26ai: Datenbank-Upgrades automatisieren und vereinfachen

Sebastian Naumann — Wed, 27 May 2026 10:17:19 +0000

Home → Datenbank

Oracle AutoUpgrade in Oracle Database 26ai: Datenbank-Upgrades automatisieren und vereinfachen

Verfasst von Sebastian Naumann
27 Mai 2026
12:17
Datenbank, Oracle Database, Oracle Datenbank 26ai

Mit Oracle Database 26ai entwickelt Oracle das bewährte AutoUpgrade-Framework konsequent weiter. Für DBAs und IT-Administratoren bedeutet das vor allem eines: weniger manuelle Upgrade-Schritte, mehr Automatisierung und höhere Transparenz bei komplexen Datenbankmigrationen.

Gerade in modernen Multitenant-Umgebungen mit CDBs und PDBs zeigt AutoUpgrade seine Stärken – insbesondere bei Migrationen von Oracle 19c auf 26ai.

Wir haben verschiedene Upgrade-Szenarien unter die Lupe genommen. Im folgenden Beitrag erfährst du, welche neue Möglichkeiten dir in Oracle 26ai zur Verfügung stehen, wo die Unterschiede zu klassischen Upgrade-Methoden liegen und was für dich als DBA besonders interessant sein dürfte.

Was ist Oracle AutoUpgrade?

AutoUpgrade ist ein von Oracle bereitgestelltes Kommandozeilen-Tool zur automatisierten Durchführung von Datenbank-Upgrades und Migrationen. Es orchestriert dabei sämtliche Upgrade-Phasen:

Prechecks und Analysen
automatische Fixups
Datenbank-Upgrade
Post-Upgrade-Tasks
Kompilierung invalider Objekte
SQL-Patching
Timezone-Upgrades

Die einzelnen Modi wie ANALYZE, FIXUPS, UPGRADE und DEPLOY ermöglichen eine granulare Steuerung des gesamten Upgrade-Prozesses.

Besonders hilfreich:
Bereits die Analyze-Phase führt umfangreiche Prüfungen durch, ohne Änderungen an der Quelldatenbank vorzunehmen.

Neue Möglichkeiten in Oracle 26ai

In Oracle 26ai wird AutoUpgrade insbesondere für Multitenant- und Cross-Version-Upgrades interessant. Unterstützt werden unter anderem:

19c CDB → 26ai CDB
19c NONCDB → 26ai PDB
Replay Upgrades für PDBs
automatische NONCDB-zu-PDB-Konvertierung

Replay Upgrade ersetzt das klassische Parallel-Upgrade-Verfahren, entbindet aber nicht von den vorbereitenden und nachgelagerten Upgrade-Schritten. Die in der Oracle-Dokumentation beschriebenen Preupgrade- und Postupgrade-Aufgaben müssen weiterhin durchgeführt werden.

Wichtig ist dabei die Abgrenzung zu AutoUpgrade:
Replay Upgrade ist ein Upgrade-Verfahren bzw. eine Upgrade-Engine, die das bisherige Parallel Upgrade ablöst. AutoUpgrade hingegen ist das übergeordnete Automatisierungswerkzeug, das den gesamten Upgrade-Ablauf unterstützt und dabei unter anderem Prechecks, Fixups, das eigentliche Upgrade sowie Postupgrade-Schritte orchestrieren kann.

Unterschied zu klassischen Upgrade-Methoden

Im Vergleich zu traditionellen manuellen Upgrades oder älteren „Parallel Upgrade“-Ansätzen bietet AutoUpgrade deutliche Vorteile:

Klassisches Upgrade	AutoUpgrade 26ai
Viele manuelle Schritte	Vollautomatisierte Workflows
Separate Skripte für Pre-/Posttasks	Integrierte Analyse- und Fixup-Phasen
Hohes Fehlerrisiko, bedingt durch manuelle Arbeiten	Konsistente, reproduzierbare automatisierte Abläufe
Manuelles Patchen und Kompilieren	Automatische Postfixups inklusive datapatch
Komplex bei Multitenant	Native Unterstützung für CDB/PDB-Szenarien

Insbesondere der DEPLOY-Modus hebt sich hervor:
Dieser kombiniert sämtliche Upgrade-Schritte in einem einzigen orchestrierten Prozess – inklusive Wechsel des Oracle Homes, Datenbankstart im Ziel-Home sowie optionaler Clusterware-Anpassungen.

Interessant für DBAs: Transparenz und Statuskontrolle

Ein großer Vorteil im täglichen Betrieb ist die hohe Transparenz während des Upgrades. AutoUpgrade liefert detaillierte Statusinformationen zu einzelnen Stages wie:

DBUPGRADE
POSTCHECKS
POSTFIXUPS
NONCDBTOPDB

Auch Fortschritte pro PDB lassen sich direkt überwachen.

Darüber hinaus können die folgenden Tools bei der technischen Validierung nach dem Upgrade unterstützen:

PDB_PLUG_IN_VIOLATIONS
utlusts
AutoUpgrade-Statusreports

Fazit

Oracle AutoUpgrade in Version 26ai ist deutlich mehr als ein simples Upgrade-Skript. Das Framework entwickelt sich zunehmend zu einer vollständigen Automatisierungsplattform für Datenbankmigrationen im Oracle-Umfeld.

Gerade für Oracle-Administratoren mit großen 19c-Landschaften, Multitenant-Architekturen oder geplanten NONCDB-Migrationen bietet AutoUpgrade:

weniger manuellen Aufwand,
standardisierte Abläufe,
reduzierte Downtimes
und eine deutlich höhere Betriebssicherheit.

Für viele Upgrade-Szenarien dürfte AutoUpgrade in 26ai künftig der bevorzugte Standardweg sein.

Du hast Fragen zum Feature oder benötigst Unterstützung?
Komm gern auf uns zu!

Kontakt

Du hast Fragen zum Feature oder benötigst Unterstützung?
Komm gern auf uns zu!

Kontakt

Hier findest du weitere Infos aus der Welt von Oracle aus unserem News & Insights Bereich.

Share this article

Der Beitrag Oracle AutoUpgrade in Oracle Database 26ai: Datenbank-Upgrades automatisieren und vereinfachen erschien zuerst auf ASPICON.

Preisanpassung Oracle ab 1. Mai 2026

Marcel Heinrich — Mon, 04 May 2026 13:20:44 +0000

Home → Datenbank

Preisanpassung Oracle ab 1. Mai 2026

Verfasst von Marcel Heinrich
04 Mai 2026
15:20
Datenbank, Oracle

Zum 1. Mai 2026 hat Oracle Preisanpassungen für ihre Engineered Systems vorgenommen. Betroffen sind unter anderem folgende Lösungen:

Exadata Database Machine
Oracle Database Appliance
Zero Data Loss Recovery Appliance

Desweiteren fällt die Exadata Cloud@Customer unter die Preisanpassung.

Auf Systemebene liegen die Preiserhöhungen je nach Konfiguration zwischen 42% und 57%. Diese Anpassungen betreffen insbesondere die Hardware-Komponenten und sind laut Oracle auf deutlich gestiegene Materialkosten bei Zulieferern zurückzuführen, die branchenweit zu beobachten sind.

Die aktuellen Preisanpassungen unterstreichen die Dynamik im Infrastrukturmarkt und den Einfluss externer Kostenfaktoren. Eine fundierte Bewertung der eigenen Oracle-Landschaft ist jetzt wichtiger denn je.

Wir helfen dir gern dabei, deine Verfügbarkeitskonzepte unter die Lupe zu nehmen
und auf mögliche Konsolidierungspotentiale zu prüfen.

Kontakt

Wir helfen dir gern dabei, deine Verfügbarkeitskonzepte unter die Lupe zu nehmen und auf mögliche Konsolidierungspotentiale zu prüfen.

Kontakt

Hier findest du weitere Infos rund um Oracle aus unserem News & Insights Bereich.

Share this article

Der Beitrag Preisanpassung Oracle ab 1. Mai 2026 erschien zuerst auf ASPICON.

“Automatisierung: Zwischen magischer Effizienz und bitterer Realität” – Unser Vortrag auf den Chemnitzer Linux-Tagen 2026

Isabel Dahl — Mon, 30 Mar 2026 08:04:56 +0000

Home → Datenbank

“Automatisierung: Zwischen magischer Effizienz und bitterer Realität” – Unser Vortrag auf den Chemnitzer Linux-Tagen 2026

Verfasst von Isabel Dahl
30 März 2026
10:04
Automatisierung, Datenbank, Linux

“Souveräne Digitalität” ist das Motto der diesjährigen Chemnitzer Linux Tage (CLT). Wie schaffen wir robuste, offene und kompatible Systeme, die Abhängigkeiten reduzieren und digitale Ökosysteme verbinden? Wie fördern wir Akzeptanz und Nutzung offener Lösungen in Verwaltung, Bildung und Zivilgesellschaft? Und wie stärken Open Source und Linux die Wettbewerbsfähigkeit von Unternehmen und öffentlichen Einrichtungen?

An letztere Fragestellung knüpft unser Vortrag zum Thema “Automatisierung: Zwischen magischer Effizienz und bitterer Realität” an. Denn während Marketingfolien bereits von vollständig autonomen Systemen mit vielversprechendem ROI schwärmen, sieht die Realität oft ganz anders aus.

Das erwartet dich in unserem Automatisierungs-Vortrag

Zwischen einfachen Shell-Skripten, umfangreichen Ansible-Playbooks und Event Driven Automation als vermeintlicher Königsklasse eröffnet sich ein breites Spektrum an Ansätzen. Darin verbergen sich oft auch typische Stolpersteine und so manche kuriose Situationen. Genau dieses Spannungsfeld wollen wir beleuchten. Unser Vortrag wirft einen Blick auf typische Szenarien aus dem IT-Alltag, in denen Automatisierung gleichermaßen Begeisterung, Kopfschütteln und gelegentlich pure Verzweiflung ausgelöst hat.

Anhand praxisnaher Beispiele zeigen wir auf, wie Open-Source-Lösungen – etwa die Ansible Automation Platform – dazu beitragen können, Innovationspotenziale zu heben und die Wettbewerbsfähigkeit von Unternehmen und öffentlichen Institutionen zu stärken. Gleichzeitig hinterfragen wir kritisch, wann der Einsatz solcher Werkzeuge tatsächlich sinnvoll ist. Denn nicht jede Aufgabe erfordert ein komplexes Framework. Oft ist eine schlanke, einfache Lösung die bessere Wahl. Unser Ziel ist es, den richtigen Mittelweg zwischen übertriebener Automatisierung und effizientem Einsatz von Ressourcen auszuloten. Wo schafft Automatisierung echten Nutzen – und wo führt sie lediglich zu zusätzlicher Komplexität?

Was du am Ende mitnehmen wirst

Unser Vortrag richtet sich an alle, die schon einmal „nur schnell“ etwas automatisieren wollten – und sich Wochen oder Monate später in einem Ökosystem aus Workarounds, Cronjobs und kryptischen Fehlermeldungen wiederfanden. Gleichermaßen soll er aber auch diejenigen abholen, die genau davor Angst haben und sich vielleicht noch gar nicht an Automatisierung herangewagt haben.

Mit einem Augenzwinkern, praxisnahen Beispielen und ein paar ehrlichen Zahlen aus der Realität vermitteln wir Erkenntnisse, die sowohl zum Lachen als auch zum Nachdenken anregen. Am Ende bleibt die wichtigste Botschaft: Automatisierung ist mächtig. Aber gesunder Menschenverstand ist und bleibt die wertvollste Ressource und ein wichtiger Baustein, um souveräne Digitalität zu erreichen.

Wann?

Wo?

Thema

Speaker

29. März 2026
10:00 Uhr

Technische Universität Chemnitz
Raum V5
Reichenhainer Straße 90
09126 Chemnitz

Automatisierung: Zwischen magischer Effizienz und bitterer Realität

Michael Decker

Wann?

29. März 2026
10:00 Uhr

Wo?

Technische Universität Chemnitz
Raum V5
Reichenhainer Straße 90
09126 Chemnitz

Thema

Automatisierung: Zwischen magischer Effizienz und bitterer Realität

Speaker

Michael Decker

Chemnitzer Linux-Tage: Ein Highlight für Open-Source-Enthusiasten

Seit ihrer Gründung im Jahr 1999 sind die Chemnitzer Linux-Tage zu einer festen Größe innerhalb der Open-Source-Szene geworden. Jedes Jahr reisen zahlreiche Linux-Interessierte aus dem gesamten deutschsprachigen Raum nach Chemnitz. Die Veranstaltung zählt mittlerweile zu den bedeutendsten Events dieser Art. Ein abwechslungsreiches Angebot aus Vorträgen, praxisnahen Workshops und einer begleitenden Ausstellung macht die CLT besonders attraktiv für alle, die sich mit freier Software und Open-Source-Lösungen beschäftigen. Für Interessierte, die nicht persönlich teilnehmen können, werden die Inhalte zudem per Livestream zugänglich gemacht. Die Aufzeichnungen werden im Nachgang veröffentlicht.

ASPICON engagiert sich bereits seit mehreren Jahren als Sponsor der CLT. Darüber hinaus ergänzen wir das Programm regelmäßig mit Fachvorträgen zu Themen wie » Sicherheit in PostgreSQL, » Mit Ansible Collections & Workflows gegen das Playbook-Chaos oder » Ansible Automatisierung in hybriden Umgebungen. Auch wenn wir als Managed Service Provider vor allem im Enterprise-Umfeld tätig sind, haben Open-Source-Technologien für uns eine zentrale Bedeutung – sowohl in unseren internen Prozessen als auch in Kundenprojekten. Viele grundlegende Technologien moderner IT-Infrastrukturen und Datenbanksysteme entstehen innerhalb dieser Community durch gemeinschaftliche Entwicklung, Wissensaustausch und offene Zusammenarbeit. Genau diese Prinzipien spiegeln sich auch in unserer Arbeit bei ASPICON wider. Daher ist es für uns selbstverständlich, die Veranstaltung zu fördern und dazu beizutragen, dass die Community weiterhin ein Ort für Austausch, Weiterbildung und Innovation bleibt.

Das waren die Chemnitzer Linux Tage 2026

Aufzeichnung des Vortrags

» Hier kannst du dir die Aufzeichnung des Vortrags anschauen

Weitere interessante Posts zum Thema Linux aus unserem News und Insights Bereich.

Share this article

Der Beitrag “Automatisierung: Zwischen magischer Effizienz und bitterer Realität” – Unser Vortrag auf den Chemnitzer Linux-Tagen 2026 erschien zuerst auf ASPICON.

Oracle Database 26ai: Echter Mehrwert oder steigende Komplexität?

Sebastian Naumann — Thu, 26 Feb 2026 14:28:59 +0000

Home → Datenbank

Oracle Database 26ai: Echter Mehrwert oder steigende Komplexität?

Verfasst von Sebastian Naumann
26 Februar 2026
15:28
Datenbank, Oracle, Oracle Datenbank 23ai, Oracle Datenbank 26ai

Mit Oracle Database 26ai hat Oracle die nächste Generation seiner Datenbankplattform an den Start gebracht, die seit Januar nun auch On-Premises für ausgewählte Plattformen verfügbar ist. Dabei liegt der Fokus der 26ai klar auf Automatisierung, KI-gestützten Funktionen sowie einer weiteren Konsolidierung von Betriebsmodellen.

Doch jenseits des „ai“-Labels stellt sich für IT-Verantwortliche und Datenbankadministratoren eine deutlich praxisnähere Frage: Welche technischen Änderungen wirken sich tatsächlich auf Architektur, Betrieb und Sicherheitskonzepte aus – und welche davon sind im konkreten Alltag wirklich relevant? Zudem ist entscheidend, in welchen Editionen diese Funktionen überhaupt zur Verfügung stehen und somit strategisch eingeplant werden können.

Dieser Beitrag beleuchtet die wichtigsten Neuerungen von Oracle 26ai aus operativer Sicht und ordnet sie zugleich in den praktischen Betriebsalltag ein. Im Fokus stehen dabei Funktionen wie Vector Search, JSON Duality und die Multitenant-Architektur, ebenso wie sicherheitsrelevante Aspekte rund um Verschlüsselung sowie die kryptografische Zukunftsfähigkeit.

Ziel ist dabei eine realistische Einordnung: Wo entsteht tatsächlich ein Mehrwert für den Betrieb, und unter welchen Voraussetzungen lässt sich dieser effizient nutzen? Und an welchen Stellen steigt hingegen die Komplexität für DBAs, etwa durch zusätzliche Anforderungen an Architektur, Administration oder Sicherheitskonzepte?

Einordnung: Was bedeutet „26ai“?

Mit dem Suffix ai signalisiert Oracle, dass KI‑Funktionen nicht mehr nur Add‑ons sind, sondern tief in die Datenbank integriert werden. Wichtig dabei: Oracle Database 26ai bleibt eine klassische relationale Oracle Database, erweitert um native KI‑ und Automatisierungsfunktionen.

Für den Betrieb bedeutet das:

Keine neue Produktlinie, sondern ein reguläres Major Release
Weiterhin vollständige Abwärtskompatibilität innerhalb der unterstützten Upgrade‑Pfade
AI‑Funktionen sind Bestandteil der Datenbank, nicht zwingend der Anwendung

Technische Neuerungen mit Relevanz für den Betrieb

1) Vector Search (Vektorbasierte Suche)

Mit 26ai integriert Oracle Vektor-Datentypen und semantische Suchmechanismen nativ in die Datenbank. Damit können Embeddings (beispielsweise aus Large Language Models) direkt in Tabellen gespeichert und über spezialisierte Indexstrukturen performant durchsucht werden.

Typische Einsatzszenarien sind beispielsweise:

Ähnlichkeitssuche auf Dokumenten oder Texten
Retrieval-Augmented Generation (RAG)
KI-gestützte Empfehlungssysteme

Praxisrelevanz:

Für Datenbankadministratoren gehen damit neue Herausforderungen einher: neue Datentypen und Indexarten müssen verstanden und sauber dimensioniert werden. Darüber hinaus ändert sich der Speicherbedarf und I/O‑Profile deutlich. Backup-/Recovery-Strategien müssen große Embedding-Strukturen berücksichtigen und Performance-Tests sind zwingend erforderlich, da Vektorindizes andere Lastmuster erzeugen als klassische B‑Tree-Indizes. Für klassische OLTP-Systeme ohne KI-Anwendungsfälle ist die Relevanz gering. In datengetriebenen Projekten kann Vector Search jedoch strategisch entscheidend sein.

Hinweis zur Edition:

Grundsätzlich kann das Feature auch bereits in der Standard Edition genutzt werden. Dort ist hingegen die native Erzeugung von Embeddings in der Datenbank eingeschränkt oder nicht verfügbar – das heißt, du musst die Vektoren extern erzeugen (wie etwa mit Python, AI-Frameworks wie LangChain, OpenAI-APIs oder anderen Tools) und dann erst in die Datenbank importieren. In der Enterprise Edition kann Oracle diese Embeddings nativ in der Datenbank erzeugen, indem du Modelle im ONNX-Format importierst und direkt über SQL/PL-SQL Funktionen nutzt. So läuft der „Embedding-Workflow“ komplett innerhalb der Datenbank ab.

2) JSON Duality (Dokument-Relational-Dualität)

Oracle entwickelt das Konzept der JSON-Relational Duality weiter (häufig als „JSON Duality“ bezeichnet). Dabei können Daten gleichzeitig relational und als JSON-Dokument modelliert und konsistent gehalten werden.

Das bedeutet:

Eine Tabelle kann als JSON-Dokument „gespiegelt“ werden
Anwendungen greifen dokumentenorientiert zu
Die Daten bleiben relational strukturiert

Praxisrelevanz:

Für Datenbankadministratoren könnte das weniger Druck bedeuten, zusätzliche NoSQL-Systeme einzuführen. Außerdem bleibt die Datenintegrität durch relationale Constraints gesichert. Dafür kommen neue Anforderungen an Index-Strategien und Zugriffsmuster hinzu und die Datenmodellierung wird hybrider und damit anspruchsvoller. Für Organisationen mit Microservices-Architekturen oder API-zentrierten Anwendungen ist dies hoch relevant.

Hinweis zur Edition:

Grundlegende JSON-Funktionalität ist auch in der Standard Edition verfügbar. Erweiterte Performance-Features und spezielle Optimierungen sind typischerweise an die Enterprise Edition gebunden.

3) Weiterentwicklung der Multitenant‑Architektur

Die Multitenant‑Architektur bleibt das zentrale Betriebsmodell.

Oracle 26ai bringt hier unter anderem:

Verbesserte Ressourcenisolierung zwischen PDBs
Feinere Steuerung von CPU, I/O und Memory
Vereinfachtes Lifecycle‑Management großer CDB‑Landschaften

Praxisrelevanz:

Gerade für Konsolidierungsprojekte entsteht mehr Planbarkeit. Für DBAs bedeutet das allerdings auch: Ressourcenmanagement (Resource Manager), Monitoring pro PDB und Kapazitätsplanung werden noch relevanter. Wichtig zu wissen: Single-Tenant-Setups sind strategisch kein Zielpfad mehr, denn „Non-CDB“ ist de facto tot.

Hinweis zur Edition:

Multitenant ist grundsätzlich auch in der Standard Edition nutzbar, allerdings mit funktionalen Einschränkungen. Erweiterte Ressourcensteuerung und größere PDB-Skalierung sind klar auf die Enterprise Edition ausgerichtet.

4) True Cache

True Cache erweitert das Caching-Modell der Datenbank, indem häufig genutzte Daten intelligent und konsistent näher an der Verarbeitung gehalten werden – auch in verteilten oder hybriden Architekturen.

Ziele, die damit verfolgt werden, sind:

Reduzierung von Latenzen
Entlastung zentraler Datenbankknoten
Stabilisierung von Workloads bei Lastspitzen

Praxisrelevanz:

Mit True Cache gewinnt Architekturplanung hinsichtlich Platzierung, Synchronisation und Failover-Strategien an Bedeutung. Das Monitoring muss Cache-Hit-Rates und Konsistenzmetriken einbeziehen und die Fehleranalyse wird komplexer, da Performanceprobleme nicht mehr nur auf Datenbankebene entstehen. True Cache ist insbesondere für verteilte Unternehmensarchitekturen relevant – weniger für kleine Einzelinstanzen.

Hinweis zur Edition:

Typischerweise Enterprise Edition, da es sich um eine skalierungs- und architekturbezogene Erweiterung handelt.

Ausgewählte Features der Oracle Database 26ai – wie etwa True Cache – werden wir uns in Kürze noch genauer anschauen und weiterführende Beiträge dazu veröffentlichen.

Sicherheit in Oracle Database 26ai

Sicherheit bleibt ein zentrales Thema – insbesondere im On-Prem-Betrieb. Die folgende Tabelle zeigt die Möglichkeiten in der Oracle Database 26ai, erklärt die Relevanz und nennt die Edition.

Sicherheit durch	Inhalt	Relevanz	Edition
Verschlüsselung ruhender Daten (Data at Rest)	Transparent Data Encryption (TDE) bleibt der Standardmechanismus Tablespaces, Datenfiles, Redologs und Backups können verschlüsselt werden Integration mit Hardware Security Modules (HSM) und zentralem Key Management bleibt möglich	Für produktive Systeme faktisch Best Practice In vielen regulatorischen Umfeldern verpflichtend	TDE ist klassisch ein Enterprise Edition Feature
Verschlüsselung bei Übertragung (Data in Transit)	Native Unterstützung moderner TLS-Versionen Verbesserte Standardkonfigurationen für sichere Listener- und Client-Kommunikation Vereinfachte Zertifikatsverwaltung	Für hybride Architekturen, Replikation, Data Guard und Anwendungszugriffe essenziell DBAs sollten Default-Konfigurationen prüfen und explizit härten	Grundlegende Netzwerkverschlüsselung ist auch in der Standard Edition verfügbar
Vorbereitung auf quantenresistente Kryptografie	Oracle adressiert zunehmend das Thema Post-Quantum Cryptography (PQC): Unterstützung bzw. Vorbereitung für quantenresistente Algorithmen in kryptografischen Bibliotheke Hybrid-Ansätze (klassische + PQ-Algorithmen) in TLS-Kontexten	Kurzfristig gering, strategisch hoch relevant Besonders wichtig für Organisationen mit langen Datenaufbewahrungsfristen (z. B. Finanz- oder Gesundheitswesen) Schlüsselmanagement und Zertifikatsstrategien müssen langfristig geplant werden	Primär im Enterprise-Umfeld relevant, da PQC vor allem in sicherheitskritischen Umgebungen implementiert wird

Gesamtbewertung und Fazit

Aus unserer Sicht ergeben sich für Datenbankadministratoren drei zentrale Trends aus den Neuerungen:

Mehr Automatisierung, weniger manuelles Tuning:
Die Rolle des DBAs verschiebt sich in Richtung Governance, Qualitätssicherung und Architektur.
Hybride Datenmodelle und KI-Integration:
DBAs müssen sich stärker mit Embeddings, JSON-Modellen und Data-Lake-Integrationen auseinandersetzen.
Sicherheit als Daueraufgabe:
Verschlüsselung ist kein optionales Feature mehr, sondern eine Standardanforderung. Langfristige Kryptostrategien gewinnen an Bedeutung.

In kleineren Umgebungen mit Standard Edition bleibt der Mehrwert aktuell eher selektiv. Für Enterprise-Umgebungen mit Konsolidierungs‑, KI- oder Data-Platform-Strategie ist 26ai jedoch ein klar strategisches Release.

Diese Beiträge könnten dich auch interessieren:

» Supportlaufzeiten der Oracle Datenbanken
» Oracle Database 26ai On-Prem: Was ist aktuell verfügbar?

Hier findest du weitere Features und Infos aus der Welt von Oracle aus unserem News & Insights Bereich.

Share this article

Der Beitrag Oracle Database 26ai: Echter Mehrwert oder steigende Komplexität? erschien zuerst auf ASPICON.

Datenbank · ASPICON Newsarchiv

PostgreSQL 19 Beta 3 im Praxistest: Bloat mit dem neuen REPACK-Befehl beseitigen

PostgreSQL 19 Beta 3 im Praxistest: Bloat mit dem neuen REPACK-Befehl beseitigen

Inhaltsverzeichnis

Testdatenbank vorbereiten

Ausgangsgröße

Bloat erzeugen

Physische Größe prüfen

Dead Tuples prüfen

Physische Datei ermitteln

Normales VACUUM

Größe nach VACUUM

Dead Tuples nach VACUUM

Dateisystem

Klassisches REPACK

Größe nach REPACK

Dead Tuples nach REPACK

Physischer Austausch der Relation

Ergebnis des Tests

Ausgangszustand

Nach VACUUM

Nach REPACK

Zusammenfassung

REPACK (CONCURRENTLY)

Wichtige Einschränkung: nicht MVCC-safe

Abgrenzung zu pg_repack

Unsere Einordnung

DBA-Tipp: So kannst du Oracle AI Database 26ai On-Prem bereits jetzt für SE2 nutzen

DBA-Tipp: So kannst du Oracle AI Database 26ai On-Prem bereits jetzt für SE2 nutzen

Download über My Oracle Support

Installation

Fazit

Patch Update und Release Info PostgreSQL

Patch Update und Release Info PostgreSQL

PostgreSQL Patch Update: 28 Sicherheitslücken und über 110 Fehler behoben

Nach dem Update: Diese Punkte solltest du prüfen

PostgreSQL 14: Support endet im November

Release Info: Oracle Database Appliance Version 19.31 veröffentlicht

Release Info: Oracle Database Appliance Version 19.31 veröffentlicht

Das bringt das neue Oracle Database Appliance Release unter anderem mit:

Integrierte Datenbank-Updates und unterstützte Plattformen

Fazit

Oracle AutoUpgrade in Oracle Database 26ai: Datenbank-Upgrades automatisieren und vereinfachen

Oracle AutoUpgrade in Oracle Database 26ai: Datenbank-Upgrades automatisieren und vereinfachen

Was ist Oracle AutoUpgrade?

Neue Möglichkeiten in Oracle 26ai

Unterschied zu klassischen Upgrade-Methoden

Interessant für DBAs: Transparenz und Statuskontrolle

Fazit

Preisanpassung Oracle ab 1. Mai 2026

Preisanpassung Oracle ab 1. Mai 2026

“Automatisierung: Zwischen magischer Effizienz und bitterer Realität” – Unser Vortrag auf den Chemnitzer Linux-Tagen 2026

“Automatisierung: Zwischen magischer Effizienz und bitterer Realität” – Unser Vortrag auf den Chemnitzer Linux-Tagen 2026

Das erwartet dich in unserem Automatisierungs-Vortrag

Was du am Ende mitnehmen wirst

Chemnitzer Linux-Tage: Ein Highlight für Open-Source-Enthusiasten

Das waren die Chemnitzer Linux Tage 2026

Aufzeichnung des Vortrags

Oracle Database 26ai: Echter Mehrwert oder steigende Komplexität?

Oracle Database 26ai: Echter Mehrwert oder steigende Komplexität?

Inhaltsverzeichnis

Einordnung: Was bedeutet „26ai“?

Technische Neuerungen mit Relevanz für den Betrieb

1) Vector Search (Vektorbasierte Suche)

2) JSON Duality (Dokument-Relational-Dualität)

3) Weiterentwicklung der Multitenant‑Architektur

4) True Cache

Sicherheit in Oracle Database 26ai

Gesamtbewertung und Fazit