ASPICON https://www.aspicon.de/ Database Technology and Service Wed, 21 Oct 2026 12:23:54 +0000 de hourly 1 https://wordpress.org/?v=7.1.3 https://www.aspicon.de/wp-content/uploads/2023/12/favicon_white_verlauf_2-50x50.png ASPICON https://www.aspicon.de/ 32 32 Oracle Critical Patch Update Oktober 2026 veröffentlicht – Jetzt handeln! https://www.aspicon.de/news/oracle-critical-patch-update-oktober-2026-veroeffentlicht-jetzt-handeln/ Wed, 21 Oct 2026 12:23:52 +0000 https://www.aspicon.de/?p=27264 1.295 Lücken geschlossen: Das Oktober-CPU zeigt wieder deutlich, wie breit die Sicherheitsanforderungen in gewachsenen Oracle-Landschaften sind.

Der Beitrag Oracle Critical Patch Update Oktober 2026 veröffentlicht – Jetzt handeln! erschien zuerst auf ASPICON.

]]>

Oracle Critical Patch Update Oktober 2026 veröffentlicht – Jetzt handeln!

Am 20. Oktober 2026 hat Oracle das vierte Critical Patch Update des Jahres veröffentlicht. Das Paket umfasst insgesamt » 1.295 neue Sicherheitspatches über alle Produktfamilien hinweg. Die Lücken betreffen sowohl den eigenen Code von Oracle als auch eingebundene Drittanbieter-Komponenten, und ein Teil davon wirkt sich produktübergreifend aus.

Wer seine Oracle-Systeme zeitnah absichern will, sollte die Updates nicht auf die lange Bank schieben. Oracle weist ausdrücklich darauf hin, dass Angreifer bereits veröffentlichte Lücken gezielt ausnutzen, und zwar genau dort, wo verfügbare Patches nicht eingespielt wurden. Je länger ein System ungepatcht bleibt, desto größer wird das Risiko für Datenabfluss, Systemausfälle und Compliance-Verstöße.

Wir haben die für unsere Kunden wichtigsten Produktbereiche herausgegriffen und die Angaben direkt aus dem Oracle-Advisory übernommen. Die Base Scores stammen aus den jeweiligen Risk Matrices.

Oracle - blk

Oracle Fusion Middleware (WebLogic Server)

Für Oracle Fusion Middleware liefert das Oktober-CPU » 206 neue Sicherheitspatches. Davon sind 134 über das Netzwerk ohne Authentifizierung ausnutzbar. Das betrifft typische Middleware- und Integrationskomponenten wie WebLogic Server, Oracle HTTP Server, SOA Suite, Service Bus oder Identity Manager. Der höchste Base Score in diesem Bereich liegt bei 10.0.

Oracle MySQL Server

Im Bereich MySQL schließt das Update » 98 Sicherheitslücken. 29 davon sind remote und ohne Authentifizierung angreifbar. Der höchste Base Score beträgt 9.8. Betroffen sind unter anderem die Linien MySQL Server 8.4, 9.7 und 26.7 sowie MySQL Cluster, MySQL Router und MySQL Enterprise Backup. Gerade Datenbankserver mit Netzwerkzugriff sollten hier priorisiert werden.

Oracle Java SE

Für Oracle Java SE nennt Oracle » 55 neue Sicherheitspatches. 49 davon sind remote ohne Authentifizierung ausnutzbar, der höchste CVSS-Wert liegt bei 7.5. Betroffen sind unter anderem die Java-SE-Versionen 8u503, 11.0.32.1, 17.0.20.1, 21.0.12.1, 25.0.4.1, 26.0.2 und 27 sowie JavaFX und GraalVM. Wo Java-Runtimes aktiv genutzt werden, lohnt sich eine Bestandsaufnahme, welche Versionen tatsächlich im Einsatz sind.

Oracle Database Server

Beim Oracle Database Server umfasst das Oktober-CPU » 14 neue Sicherheitspatches. Vier davon lassen sich remote ohne Authentifizierung ausnutzen. Zwei Patches betreffen zusätzlich Client-only-Installationen, also Systeme ohne installierten Database Server. Der höchste Base Score liegt bei 9.8 und betrifft eine Schwachstelle in der OpenSSL-Komponente der RDBMS (CVE-2026–75803). Betroffen sind die Versionen 19.3 bis 19.32, 21.3 bis 21.23 und 23.4.0 bis 23.26.3.

Oracle Enterprise Manager (Cloud Control)

Für den Oracle Enterprise Manager enthält das Advisory » 12 neue Sicherheitspatches. Zwei davon sind remote ohne Authentifizierung ausnutzbar. Der höchste Base Score liegt bei 9.9. Betroffen sind unter anderem Enterprise Manager Base Platform, Enterprise Manager for Oracle Database, for Siebel und for Virtualization in den Versionen 13.5 und 24.1.

Die folgende Übersicht fasst die wichtigsten Daten noch einmal kompakt zusammen – inklusive des jeweils höchsten CVSS-Basiswerts pro Produktbereich.

Betroffenes Produkt
Anzahl Patches
Remote ausnutzbar?
Höchster Base Score
Oracle Fusion Middleware (WebLogic Server)
206
ja (134)
10.0
Oracle MySQL Server
98
ja (29)
9.8
Oracle Java SE
55
ja (49)
7.5
Oracle Database Server
14
ja (4)
9.8
Enterprise Manager (Cloud Control)
12
ja (2)
9.9

Weitere Details, Patch-Verfügbarkeit und Installationshinweise findest du in den » Oracle Security Alerts.

Zur optimalen Planung hat Oracle die nächsten Termine für kommende Patch-Veröffentlichungen bereits angekündigt. Sicherheitspatches erscheinen jeweils am dritten Dienstag des Monats:

  • 19. Januar 2027
  • 20. April 2027
  • 20. Juli 2027
  • 19. Oktober 2027

Fazit und Empfehlung

Das Oktober-CPU zeigt wieder deutlich, wie breit die Sicherheitsanforderungen in gewachsenen Oracle-Landschaften sind. Besonders kritisch ist, dass ein großer Teil der Lücken über das Netzwerk ausnutzbar ist, teils sogar in der großen Mehrzahl der Fälle. Exponierte Systeme sollten daher zuerst betrachtet werden.

Praktisch empfiehlt es sich, zunächst eine vollständige Übersicht aller eingesetzten Oracle-Produkte inklusive Abhängigkeiten zu erstellen. Anschließend lassen sich die Updates nach Erreichbarkeit, CVSS-Bewertung und geschäftlicher Relevanz priorisieren. Client-Installationen und Management-Komponenten gehören dabei ausdrücklich dazu.

Kennst du schon unseren ASPICON Patch-Management-Service?

Als unser Kunde profitierst du von unserem Patch-Management-Service. Das heißt:

  • Wir informieren dich rechtzeitig über neue Patches und deren Relevanz für deine Systemlandschaft.
  • Gemeinsam mit dir finden wir einen Weg, deine Systeme regelmäßig auf den neuesten Stand zu bringen – selbstverständlich unter Berücksichtigung deiner individuellen Rahmenbedingungen und mit möglichst geringer Downtime.


Ruf uns gern an, um dich auf unserer Patchliste eintragen zu lassen und deine Systeme optimal zu schützen: +49.371.909515–100

Marcel Heinrich - Account Manager ASPICON

Marcel
Senior Account Manager bei ASPICON

Tel: +49.371.909515–100

Hier findest du Infos zu den vergangenen » Patch Updates und weitere nützliche Hinweise zum Thema Patchen im Allgemeinen aus unserem News und Insights Bereich.

icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook
Twitter
LinkedIn
XING
WhatsApp
Email

Der Beitrag Oracle Critical Patch Update Oktober 2026 veröffentlicht – Jetzt handeln! erschien zuerst auf ASPICON.

]]> Oracle Database 19c für Oracle Linux 10 und Red Hat Enterprise Linux 10 zertifiziert https://www.aspicon.de/news/oracle-database-19c-fuer-oracle-linux-10-und-red-hat-enterprise-linux-10-zertifiziert/ Tue, 29 Sep 2026 06:56:02 +0000 https://www.aspicon.de/?p=27228 Oracle hat das Datenbankrelease 19c ab Release Update 19.32 für Oracle Linux 10 und Red Hat Enterprise Linux 10 freigegeben.

Der Beitrag Oracle Database 19c für Oracle Linux 10 und Red Hat Enterprise Linux 10 zertifiziert erschien zuerst auf ASPICON.

]]>

Oracle Database 19c für Oracle Linux 10 und Red Hat Enterprise Linux 10 zertifiziert

Oracle hat das Datenbankrelease 19c ab Release Update 19.32 für Oracle Linux 10 und Red Hat Enterprise Linux 10 auf x86-64 freigegeben.

Folgende Betriebssystem- und Kernelkombinationen werden unterstützt:

  • Oracle Linux 10 mit Unbreakable Enterprise Kernel 8 (UEK8):
    6.12.0–104.43.4.2.el10uek.x86_64 oder neuer

  • Oracle Linux 10 mit Red Hat Compatible Kernel (RHCK):
    6.12.0–55.40.1.0.1.el10_0.x86_64 oder neuer

  • Red Hat Enterprise Linux 10:
    6.12.0–55.40.1.0.1.el10_0.x86_64 oder neuer.


Wichtig für die Installation: Für den Patchstand 19.32 sind zusätzlich zum Release Update mehrere One-off-Patches erforderlich. Die jeweiligen Voraussetzungen für Single Instance, Oracle RAC und Grid Infrastructure beschreibt Oracle » in den Installationshinweisen für OL10 und RHEL10.

Gern unterstützen wir dich bei der Prüfung deiner Umgebung
sowie bei der Migrationsplanung und Umsetzung.
Kontakt
icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook
Twitter
LinkedIn
XING
WhatsApp
Email

Der Beitrag Oracle Database 19c für Oracle Linux 10 und Red Hat Enterprise Linux 10 zertifiziert erschien zuerst auf ASPICON.

]]> PostgreSQL 19 Beta 3 im Praxistest: Bloat mit dem neuen REPACK-Befehl beseitigen https://www.aspicon.de/news/postgresql-19-beta-3-im-praxistest-bloat-mit-dem-neuen-repack-befehl-beseitigen/ https://www.aspicon.de/news/postgresql-19-beta-3-im-praxistest-bloat-mit-dem-neuen-repack-befehl-beseitigen/#respond Thu, 17 Sep 2026 06:19:45 +0000 https://www.aspicon.de/?p=27140 PostgreSQL 19 Beta 3 bringt eine spannende neue Möglichkeit mit, Bloat auch physisch aus der Datenbank zu entfernen! Wir haben den neuen Core-Befehl getestet.

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

]]>

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

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.

PostgreSQL

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.

Inhaltsverzeichnis

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.

icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook
Twitter
LinkedIn
XING
WhatsApp
Email

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

]]> https://www.aspicon.de/news/postgresql-19-beta-3-im-praxistest-bloat-mit-dem-neuen-repack-befehl-beseitigen/feed/ 0 DBA-Tipp: So kannst du Oracle AI Database 26ai On-Prem bereits jetzt für SE2 nutzen https://www.aspicon.de/news/dba-tipp-so-kannst-du-oracle-ai-database-26ai-on-prem-bereits-jetzt-fuer-se2-nutzen/ Thu, 10 Sep 2026 12:46:20 +0000 https://www.aspicon.de/?p=27087 Mit der Veröffentlichung des Juli 2026 Release Updates steht Oracle AI Database 26ai On-Prem auch für Standard Edition 2 zur Verfügung.

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

]]>

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

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.

Logo Oracle Database

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.

Screenshot Oracle AI Database 26ai Installer

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.

icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook
Twitter
LinkedIn
XING
WhatsApp
Email

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

]]> Bash Cheat Sheet: Vergleichsoperatoren & Tests https://www.aspicon.de/news/bash-cheat-sheet-vergleichsoperatoren-tests/ Fri, 04 Sep 2026 12:00:40 +0000 https://www.aspicon.de/?p=26989 Tipps aus dem Admin-Alltag: praxisnah, ohne Buzzwords und mit dem Fokus auf Dinge, die sich im täglichen Betrieb bewährt haben. Heute: Vergleichsoperatoren und Tests in Bash.

Der Beitrag Bash Cheat Sheet: Vergleichsoperatoren & Tests erschien zuerst auf ASPICON.

]]>

Bash Cheat Sheet: Vergleichsoperatoren & Tests

Headergrafik Cheat Sheet Bash - Vergleiche, Tests

Kennt ihr das? Ihr benötigt Befehle, Operatoren und kleine Helfer für eure tägliche Arbeit als DBA oder Infrastruktur-Administrator gerade oft genug, um zu wissen, dass es sie gibt. Die genaue Syntax habt ihr aber bis zum nächsten Einsatz schon wieder vergessen.

Mir geht es zumindest regelmäßig so. Gerade bei Bash sind es oft die kleinen Details: Wie prüfe ich nochmal, ob eine Datei existiert und nicht leer ist? Und kann ich eigentlich prüfen, ob eine Datei ein Hardlink ist?

Genau dafür habe ich mir ein kleines Bash Cheat Sheet zusammengestellt. Daraus möchte ich heute einen kleinen Auszug zum Thema Vergleichsoperatoren und Tests mit euch teilen. Kein Bash-Grundkurs, sondern eine schnelle Gedächtnisstütze für den nächsten „Wie war das nochmal?”-Moment.

Profilbild Michael
Michael Decker
Infrastruktur Administrator
ASPICON

Kennt ihr das? Ihr benötigt Befehle, Operatoren und kleine Helfer für eure tägliche Arbeit als DBA oder Infrastruktur-Administrator gerade oft genug, um zu wissen, dass es sie gibt. Die genaue Syntax habt ihr aber bis zum nächsten Einsatz schon wieder vergessen.

Mir geht es zumindest regelmäßig so. Gerade bei Bash sind es oft die kleinen Details: Wie prüfe ich nochmal, ob eine Datei existiert und nicht leer ist? Und kann ich eigentlich prüfen, ob eine Datei ein Hardlink ist?

Genau dafür habe ich mir ein kleines Bash Cheat Sheet zusammengestellt. Daraus möchte ich heute einen kleinen Auszug zum Thema Vergleichsoperatoren und Tests mit euch teilen. Kein Bash-Grundkurs, sondern eine schnelle Gedächtnisstütze für den nächsten „Wie war das nochmal?”-Moment.

Profilbild Michael
Michael Decker
Infrastruktur Administrator
ASPICON

Vergleich von Strings

STRING1 = STRING2   : Wahr, wenn beide Strings identisch sind. Verwendung mit dem Test-Kommando [ ... ]
STRING1 == STRING2  : Wahr, wenn beide Strings übereinstimmen. Innerhalb von [[ ... ]]

STRING1 =~ STRING2  : Wahr, wenn STRING1 zum angegebenen regulären Ausdruck (REGEX) passt
STRING1 != STRING2  : Wahr, wenn beide Strings nicht identisch sind

Beispiel: String mit regulärem Ausdruck prüfen

In dem nachfolgenden Beispiel wird der vollständige Hostname des Systems mit ‘hostname ‑f‘ ermittelt und anschließend gegen ein fest definiertes Namensschema geprüft. Erwartet wird ein Hostname nach dem Muster ‘<hostbezeichnung>-<NN>.<domain>.<tld>‘, zum Beispiel ‘postgres-01.example.com‘. Entspricht der ermittelte Hostname diesem Aufbau, wird die Prüfung erfolgreich abgeschlossen; andernfalls bricht das Skript mit einem Fehler ab.

# Vollständigen Hostnamen ermitteln
HOSTNAME="$(hostname -f)"

# Prüfen, ob der Hostname dem Schema "-.." entspricht
if [[ "${HOSTNAME}" =~ ^[[:alnum:]-]+-[0-9]{2}\.[[:alnum:]-]+\.[[:alpha:]]+$ ]]; then
    echo "Hostname entspricht dem erwarteten Namensschema: ${HOSTNAME}"
else
    echo "Hostname entspricht nicht dem erwarteten Namensschema: ${HOSTNAME}"
    exit 1
fi

Aufschlüsselung des Regex:

^                  # Anfang des Strings
[[:alnum:]-]+      # String aus Buchstaben, Ziffern und "-"
-                  # Trennzeichen vor der Nummer
[0-9]{2}           # Genau zwei Ziffern
\.                 # Punkt
[[:alnum:]-]+      # Domain
\.                 # Punkt
[[:alpha:]]+       # TLD aus Buchstaben
$                  # Ende des Strings

Vergleich von Zahlen

-eq :    =
-ne :    !=
-gt :    >
-ge :    >=
-lt :    <
-le :    <=

Beispiel: Numerischer Vergleich – „größer oder gleich“

Vor dem Start eines Backups wird geprüft, ob auf dem Ziel-Dateisystem noch ausreichend freier Speicherplatz vorhanden ist. Der aktuell verfügbare Speicherplatz wird mit df ermittelt und anschließend mit einem definierten Mindestwert verglichen. Nur wenn der verfügbare Speicherplatz größer oder gleich dem Mindestwert ist, wird die Verarbeitung fortgesetzt.

BACKUP_DIR="/backup"
MIN_FREE_SPACE_GB=20

# Verfügbaren Speicherplatz des Backup-Dateisystems in GiB ermitteln
FREE_SPACE_GB="$(df --output=avail -BG "${BACKUP_DIR}" | tail -n 1 | tr -dc '0-9')"

# Prüfen, ob mindestens der benötigte Speicherplatz verfügbar ist
if [[ "${FREE_SPACE_GB}" -ge "${MIN_FREE_SPACE_GB}" ]]; then
    echo "Ausreichend Speicherplatz vorhanden."
else
    echo "Nicht ausreichend Speicherplatz vorhanden."
    exit 1
fi

Der eigentliche Vergleich ist:

[[ "${FREE_SPACE_GB}" -ge "${MIN_FREE_SPACE_GB}" ]]

Dabei steht ‑ge für greater than or equal, also: <verfügbarer Speicherplatz> >= <Mindestanforderung>.

Dateien, Verzeichnisse & Co. testen

Manchmal muss ein Skript herausfinden, womit es überhaupt arbeitet. Gibt es das Backup-Verzeichnis? Existiert die Konfigurationsdatei? Ist ein Pfad ein symbolischer Link? Ist ein Socket vorhanden?

Dafür bringt Bash eine ganze Reihe fertiger Tests mit:

-d FILE        # FILE ist ein Verzeichnis
-b FILE        # FILE ist ein Blockgerät
-c FILE        # FILE ist ein Zeichengerät
-p FILE        # FILE ist eine Pipe
-h FILE        # FILE ist ein symbolischer Link
-L FILE        # FILE ist ein symbolischer Link
-S FILE        # FILE ist ein Socket
-t DESCRIPTOR  # File-Descriptor ist mit einem Terminal verbunden

Für reguläre Dateien und deren Eigenschaften sind vor allem diese Kandidaten praktisch:

-e FILE        # FILE existiert
-f FILE        # FILE ist eine reguläre Datei
-r FILE        # FILE ist lesbar
-s FILE        # FILE existiert und ist nicht leer
-w FILE        # FILE ist beschreibbar
-x FILE        # FILE ist ausführbar

Rechte und Besitzer prüfen

Auch einige speziellere Dateieigenschaften lassen sich direkt abfragen:

-g FILE        # Set-GID-Bit (SGID) ist gesetzt
-u FILE        # Set-UID-Bit (SUID) ist gesetzt
-k FILE        # Sticky-Bit ist gesetzt

-O FILE        # FILE gehört dem aktuellen Benutzer
-G FILE        # FILE gehört zur effektiven Gruppe
-N FILE        # FILE wurde seit dem letzten Lesen verändert

Gerade wenn Skripte mit unterschiedlichen Benutzern oder Berechtigungen laufen, können solche Checks helfen, Voraussetzungen frühzeitig zu überprüfen, statt erst beim eigentlichen Befehl in einen Fehler zu laufen.

Leere Strings erkennen

Eine weitere kleine, aber nicht ganz triviale Prüfung, um beispielsweise einen fehlenden Datenbanknamen abzufangen:

-z STRING      # STRING ist leer
-n STRING      # STRING ist nicht leer

Gerade bei Skripten, die Werte über Parameter oder Umgebungsvariablen erhalten, ist das schnell eingebaut und verhindert, dass mit unvollständigen Angaben weitergearbeitet wird.

Welche Datei ist neuer?

Auch Dateien lassen sich direkt anhand ihres Änderungszeitpunkts vergleichen:

FILE1 -nt FILE2     # FILE1 ist neuer als FILE2
FILE1 -ot FILE2     # FILE1 ist älter als FILE2

So lässt sich ohne zusätzlichen stat-Aufruf entscheiden, ob ein weiterer Verarbeitungsschritt notwendig ist.

Für den nächsten „Wie war das nochmal?“-Moment

Natürlich ist das nur ein Ausschnitt dessen, was sich mit Bash abbilden lässt. Aber genau diese Vergleiche und Tests tauchen im Admin-Alltag eben ab und zu mal wieder auf: Werte vergleichen, Schwellwerte prüfen, Dateien und Verzeichnisse validieren oder sicherstellen, dass die Voraussetzungen für den nächsten Schritt stimmen.

Die Herausforderung ist dabei oft gar nicht, wie sich eine bestimmte Prüfung umsetzen lässt. Vielmehr muss man erst einmal wissen – oder sich daran erinnern –, was Bash bereits von Haus aus mitbringt. Bevor man also selbst einen umständlichen Test baut, lohnt sich manchmal ein kurzer Blick auf die vorhandenen Operatoren. Genau dafür ist dieses Cheat Sheet gedacht: nicht zum Bash-Lernen von null an, sondern als Gedächtnisstütze, wenn die Lösung eigentlich bekannt ist – nur die verdammte Syntax gerade nicht mehr.

Im nächsten Teil geht es dann um String-Manipulation und Variablen – also unter anderem darum, Dateinamen und Pfade direkt mit Bash-Bordmitteln auseinanderzunehmen, Default-Werte zu setzen und mit Bash-Sondervariablen zu arbeiten.

Hier findest du weitere » Cheat Sheets die dir das Leben als Linux-Admin leichter machen.

icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook
Twitter
LinkedIn
XING
WhatsApp
Email

Der Beitrag Bash Cheat Sheet: Vergleichsoperatoren & Tests erschien zuerst auf ASPICON.

]]> Mut zur Lücke? Mit Dbvisit Zero Data Loss nicht nötig https://www.aspicon.de/news/mut-zur-lucke-mit-dbvisit-zero-data-loss-nicht-notig/ Tue, 01 Sep 2026 06:24:32 +0000 https://www.aspicon.de/?p=26873 Ab heute offiziell verfügbar - auch für Oracle Database Standard Edition 2. Zeit, Disaster Recovery neu zu denken.

Der Beitrag Mut zur Lücke? Mit Dbvisit Zero Data Loss nicht nötig erschien zuerst auf ASPICON.

]]>

Mut zur Lücke? Mit Dbvisit Zero Data Loss nicht nötig

Headergrafik Dbvisit Zero Data Loss

Was, wenn du dich in puncto Disaster Recovery nicht mehr zwischen einem langen Rücksprungfenster und einer möglichst kleinen Datenlücke entscheiden müsstest? Genau das verspricht Dbvisit mit “Zero Data Loss” – ab heute offiziell verfügbar, auch für Oracle Database Standard Edition 2. Das neue Feature lässt sich nahtlos in ein bestehendes Disaster-Recovery-Konzept integrieren und bringt den RPO* deiner Oracle Database nahe an null. Kein Kompromiss mehr zwischen Sicherheit und Aktualität.

Als Dbvisit Platinum Partner konnten wir uns bereits vor dem offiziellen Launch intensiv mit dem neuen Feature auseinandersetzen. Pünktlich zur heutigen Veröffentlichung ordnen wir die Lösung für dich ein: Was sich gegenüber den bisherigen Möglichkeiten ändert, welche Vorteile das Tool konkret bringt – und wann ein RPO nahe null überhaupt sinnvoll ist.

___

*RPO (Recovery Point Objective) = Daten (Wie viel Datenverlust ist tolerierbar?)
  RTO (Recovery Time Objective) = Zeit (Wie lange darf die Ausfallzeit dauern?)

Dbvisit Platinum Reseller - Logo

Dein Sicherheitsnetz hat Lücken

Machen wir einen kurzen Ausflug in die Praxis: Der Auftrag ist bestätigt, wichtige Informationen erfasst, die Zahlung verbucht, der Warenbestand aktualisiert – zumindest sollte es so sein. Doch dann fällt die Datenbank aus. Nach dem Wechsel auf das Standby-System fehlen plötzlich die letzten Minuten.

Was zunächst nach einer überschaubaren Datenlücke klingt, kann schnell zum geschäftskritischen Problem werden: Welche Aufträge sind betroffen? Welche Informationen fehlen? Welche Buchungen wurden noch verarbeitet? Stimmen Warenbestand und Systembestand überein? Und wie lassen sich die fehlenden Informationen überhaupt vollständig rekonstruieren und fehlerfrei zurückspielen?

Aus wenigen Minuten Datenverlust können so Stunden manueller Recherche entstehen – inklusive Betriebsunterbrechungen, unzufriedener Kunden, regulatorischer Herausforderungen und Kosten, die sich nur schwer beziffern lassen.

Genau hier liegt die Schwachstelle klassischer Standby-Lösungen. Eine Standby-Datenbank ist zweifellos eine wichtige Absicherung für geschäftskritische Oracle-Systeme. Ein bewusst konfigurierter Zeitversatz kann sogar sinnvoll sein – etwa um bei logischen Datenbankfehlern oder versehentlichen Änderungen ein zusätzliches Rücksprungfenster zu schaffen.

Der Haken:

Bei einem ungeplanten Ausfall kann zwischen Produktiv- und Standby-System eine Datenlücke von mehreren Minuten entstehen. Und genau diese Lücke wird bei geschäftskritischen und transaktionsintensiven Anwendungen schnell unangenehm – und teuer.

Weniger Datenlücke? Bisher nur mit Kompromissen

Wer diese Datenlücke bei seiner Oracle Datenbank möglichst klein halten wollte, musste bislang abwägen.

Option 1: Datenverlust im Minutenbereich akzeptieren.

Die klassische StandbyMP-Absicherung über archivierte Redo Logs ist bewährt und zuverlässig. Zwischen dem letzten verfügbaren Datenstand auf dem Standby und dem Zeitpunkt eines ungeplanten Ausfalls kann aber eine Datenlücke von mehreren Minuten entstehen. Die Krux an der Sache: Auch ein Ausfall von nur wenigen Minuten kann einen Arbeitsaufwand von mehreren Stunden nach sich ziehen zur Wiederherstellung der Daten. Denn nach einem Ausfall geht es nicht nur darum, wie schnell Datenbank und Anwendungen wieder verfügbar sind. Das Identifizieren, Abgleichen und gegebenenfalls Rekonstruieren fehlender Daten kann deutlich länger dauern, als die technische Wiederherstellung selbst.

Option 2: Eine individuelle Lösung aufbauen

Beispielsweise über zusätzliche Storage- oder andere Replikationsmechanismen. Das kann funktionieren, bedeutet aber zusätzliche Komplexität, Wartungsaufwand, Know-how und Eigenverantwortung für die IT.

Option 3: Auf Enterprise-Technologien setzen

Wer mit Oracle-Bordmitteln einen sehr niedrigen RPO erreichen wollte, landete früher schnell bei der Oracle Enterprise Edition. Und damit bei entsprechend höheren Lizenzkosten.

Option 2: Eine individuelle Lösung aufbauen

Beispielsweise über zusätzliche Storage- oder andere Replikationsmechanismen. Das kann funktionieren, bedeutet aber zusätzliche Komplexität, Wartungsaufwand, Know-how und Eigenverantwortung für die IT.

Option 3: Auf Enterprise-Technologien setzen

Wer mit Oracle-Bordmitteln einen sehr niedrigen RPO erreichen wollte, landete früher schnell bei der Oracle Enterprise Edition – und damit bei entsprechend höheren Lizenzkosten.

Kurz gesagt waren deine Möglichkeiten bisher:

Datenverlust akzeptieren, Komplexität akzeptieren oder höhere Kosten akzeptieren.

Von 90 auf 100 in unter einer Sekunde

Genau hier macht Dbvisit jetzt Schluss mit “entweder…oder”. Statt das bewährte StandbyMP-Verfahren zu ersetzen, ergänzt die neue Funktion einen zweiten Übertragungsweg: Während archivierte Redo Logs weiterhin regelmäßig an das Standby-System übertragen und dort angewendet werden, überträgt Zero Data Loss die laufenden Änderungen aus den Online Redo Logs kontinuierlich und nahezu in Echtzeit. In geeigneten Umgebungen sinkt der RPO dadurch von mehreren Minuten auf unter eine Sekunde.

Beide Übertragungswege arbeiten dabei unabhängig voneinander. Wird die kontinuierliche Verbindung unterbrochen, bleibt die bestehende Übertragung der archivierten Redo Logs als zusätzliche Absicherung erhalten. Auch am grundsätzlichen StandbyMP-Betrieb ändert sich nichts: Switchover, Failover, DR-Tests und Resynchronisation funktionieren weiterhin nach dem bekannten Prinzip.

Für bestehende StandbyMP-Umgebungen bedeutet das: Die Datenlücke wird drastisch kleiner, ohne das Disaster-Recovery-Konzept grundsätzlich neu aufzubauen. Im Idealfall heißt das für dich: Nach einem Ausfall musst du nicht erst minutenlange Datenlücken rekonstruieren, sondern kannst deutlich näher am tatsächlichen letzten Datenstand weiterarbeiten.

Grafik: Wie Zero Data Loss funktioniert
Quelle: Dbvisit

Braucht wirklich jede Datenbank Zero Data Loss?

Jetzt kommen wir zum eigentlichen Knackpunkt. So begeistert wir von der neuen Möglichkeit sind: Die Frage, ob deine Datenbank Zero Data Loss braucht, kannst du nur selbst für dich beantworten. Denn entscheidend ist nicht, was technisch möglich ist, sondern was dein Geschäftsprozess verkraftet oder eben auch nicht verkraftet.

Bei einem internen System können einige Minuten Datenverlust möglicherweise akzeptabel sein. Anders sieht es aus, wenn kontinuierlich geschäftskritische Transaktionen entstehen:
Im Finanz- und Versicherungswesen können fehlende Transaktionen fachliche und regulatorische Konsequenzen haben. Im E‑Commerce und Handel können Bestellungen oder Zahlungen betroffen sein. In Logistik und Just-in-Time- oder Just-in-Sequence-Produktion können digitale Bestände und tatsächliche Waren- oder Materialbewegungen auseinanderlaufen. Und im Gesundheitswesen können fehlende oder veraltete Informationen unmittelbare Auswirkungen auf die Versorgung und Behandlung haben.

Die wichtigste Frage, die du dir deshalb stellen musst lautet:

Wie viel Datenverlust können deine Geschäftsprozesse tatsächlich verkraften? Denn der eigentliche Mehrwert der Lösung liegt nicht in der Zahl „RPO unter 1 Sekunde“. Er liegt in dem, was dadurch möglicherweise nicht mehr verloren geht, wie wichtig diese Informationen für dein Geschäft sind und welchen Wiederherstellungsaufwand du dir sparst.

Weniger Datenlücke, mehr Sicherheit im Betrieb

Zusammengefasst lässt sich sagen: Das neue Dbvisit Tool sorgt dafür, dass geschäftskritische Daten, die unmittelbar vor einer Störung entstanden sind, mit deutlich höherer Aktualität auf dem Standby-System zur Verfügung stehen.

Das sorgt für:

  • Weniger verlorene Transaktionen
    Je kleiner die Datenlücke zwischen Primär- und Standby-System ist, desto weniger geschäftskritische Vorgänge können bei einem Ausfall verloren gehen und desto geringer sind die Auswirkungen auf die Datenintegrität.

  • Weniger Aufwand nach einem Ausfall
    Je kleiner die Datenlücke, desto weniger muss anschließend gesucht, abgeglichen oder manuell rekonstruiert werden.

  • Weniger Komplexität für die IT
    Statt eine individuelle Replikationslösung aufzubauen und dauerhaft selbst zu betreiben, wird die bestehende StandbyMP-Umgebung um eine standardisierte und supportete Funktion erweitert.

  • Oracle Database Standard Edition 2 bleibt eine echte Option
    Für einen RPO nahe null muss nicht allein deshalb auf die Enterprise Edition gewechselt werden. Dbvisit positioniert StandbyMP ausdrücklich als Enterprise-Class-DR für Oracle Database SE 2 und stellt dem die deutlich höheren Oracle-Lizenzkosten gegenüber.
Screenshot Zero Data Loss

Unsere Einordnung

Zero Data Loss schließt aus unserer Sicht eine bisherige Lücke für Oracle Database Standard Edition 2. Wer den RPO bisher vom Minutenbereich in Richtung null bringen wollte, musste dafür meist komplexere oder kostenintensivere Alternativen in Kauf nehmen.

Die Kombination aus RPO unter einer Sekunde, einfacher Integration in das bestehende StandbyMP-Konzept und einer standardisierten, supporteten Lösung macht die Erweiterung insbesondere für kritische Oracle-SE2-Umgebungen interessant.

Als Dbvisit Platinum Partner beschäftigen wir uns bei ASPICON seit vielen Jahren mit StandbyMP und Disaster-Recovery-Konzepten für Oracle-Datenbanken. Mit dem Launch von Zero Data Loss verändert sich die Ausgangslage für Oracle Database Standard Edition 2 jetzt drastisch. Wenn du einen RPO im Minutenbereich bislang als unvermeidbaren Kompromiss akzeptiert hast, solltest du diese Annahme jetzt neu bewerten.

Es ist Zeit, Disaster Recovery für Oracle Database Standard Edition 2 neu zu denken.
Wir helfen dir gern dabei.
Kontakt
Es ist Zeit, Disaster Recovery für Oracle Database Standard Edition 2 neu zu denken.
Wir helfen dir gern dabei.
Kontakt

Hier findest du weitere Infos rund um » Dbvisit StandbyMP von deinem
Dbvisit Platinum Partner.

|

Dbvisit und ASPICON: » Partnerschaft mit Substanz – seit 2008

Distinguished Partner Award Dbvisit
icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook
Twitter
LinkedIn
XING
WhatsApp
Email

Der Beitrag Mut zur Lücke? Mit Dbvisit Zero Data Loss nicht nötig erschien zuerst auf ASPICON.

]]> Patch Update und Release Info PostgreSQL https://www.aspicon.de/news/patch-update-und-release-info-postgresql/ https://www.aspicon.de/news/patch-update-und-release-info-postgresql/#respond Fri, 14 Aug 2026 05:34:04 +0000 https://www.aspicon.de/?p=25244 Das aktuelle Release behebt 28 Sicherheitslücken sowie mehr als 110 Fehler, die in den vergangenen Monaten gemeldet wurden - für alle unterstützten Versionen.

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

]]>

Patch Update und Release Info 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.

PostgreSQL

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.

icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook
Twitter
LinkedIn
XING
WhatsApp
Email

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

]]> https://www.aspicon.de/news/patch-update-und-release-info-postgresql/feed/ 0 Cheat Sheet: OpenSSL für Zertifikate https://www.aspicon.de/news/cheat-sheet-openssl-fuer-zertifikate/ Tue, 04 Aug 2026 11:57:53 +0000 https://www.aspicon.de/?p=26457 Tipps aus dem Admin-Alltag: praxisnah, ohne Buzzwords und mit dem Fokus auf Dinge, die sich im täglichen Betrieb bewährt haben

Der Beitrag Cheat Sheet: OpenSSL für Zertifikate erschien zuerst auf ASPICON.

]]>

Cheat Sheet: OpenSSL für Zertifikate

Headergrafik Cheat Sheet openssl

Ab und zu spült mir der Algorithmus verschiedene “Cheat Sheets” in die Timeline. Viele davon enthalten mehr oder weniger vollständige Sammlungen von grundlegenden Befehlen z.B. für Podman, Docker und Kubernetes oder auch Ansible, Terraform und unzählige weitere Tools.

Das ist durchaus interessant. Trotzdem frage ich mich häufig, ob ein Cheat Sheet mit den Basics von 200 verschiedenen Tools im Arbeitsalltag wirklich weiterhilft.

Deshalb teile ich hier künftig Tipps aus meinem Admin-Alltag – praxisnah, ohne Buzzwords und mit dem Fokus auf Dinge, die sich im täglichen Betrieb bewährt haben. Heute habe ich zwei einfache OpenSSL-Befehle für dich, die dir in typischen Alltagssituationen weiterhelfen werden.

Profilbild Michael
Michael Decker
Infrastruktur Administrator
ASPICON

Ab und zu spült mir der Algorithmus verschiedene “Cheat Sheets” in die Timeline. Viele davon enthalten mehr oder weniger vollständige Sammlungen von grundlegenden Befehlen z.B. für Podman, Docker und Kubernetes oder auch Ansible, Terraform und unzählige weitere Tools.

Das ist durchaus interessant. Trotzdem frage ich mich häufig, ob ein Cheat Sheet mit den Basics von 200 verschiedenen Tools im Arbeitsalltag wirklich weiterhilft.

Deshalb teile ich hier künftig Tipps aus meinem Admin-Alltag – praxisnah, ohne Buzzwords und mit dem Fokus auf Dinge, die sich im täglichen Betrieb bewährt haben. Heute habe ich zwei einfache OpenSSL-Befehle für dich, die dir in typischen Alltagssituationen weiterhelfen werden.

Profilbild Michael
Michael Decker
Infrastruktur Administrator
ASPICON

Stell dir vor, du bist ein “DevOps Engineer” – oder wie das früher mal hieß: “Linux Admin” – und möchtest nach einem Deployment oder einer Infrastrukturänderung schnell prüfen, ob ein Service wie erwartet erreichbar ist.

Typische Situationen sind beispielsweise:

  • Kontrolle nach Deployments
  • Untersuchung von Störungen
  • Netzwerk- und Infrastruktur-Changes
  • “Transparente” Proxies


In genau solchen Fällen gehören für mich netcat und openssl zu den Werkzeugen, auf die ich immer wieder zurückgreife.

1. Schnell prüfen, ob ein Service erreichbar ist

Mein erster Griff geht fast immer zu netcat (nc). Wenn ich herausfinden möchte, ob ein Dienst überhaupt auf dem erwarteten Host und Port lauscht, reicht oft schon ein einfacher TCP-Check:

nc -vz <HOSTNAME oder IP> <PORT>

Damit lässt sich in wenigen Sekunden feststellen, ob grundsätzlich eine TCP-Verbindung aufgebaut werden kann.

2. Wenn der Port offen ist – der Client aber trotzdem nicht funktioniert

Manchmal reicht ein offener Port allerdings nicht aus. Der Dienst ist erreichbar, der Client verbindet sich trotzdem nicht oder das Zertifikat scheint Probleme zu verursachen. Die entsprechenden Fehler- oder Logmeldungen sind nicht immer so eindeutig, wie man sich das wünscht.

In diesen Fällen ist folgender Befehl für mich einer der wertvollsten Helfer.

Instruiere OpenSSL doch bitte, als Client mit FQDN an Port PORT zu sprechen und zu fragen, wie das Zertifikat aussieht.

openssl s_client -showcerts -connect <HOSTNAME oder IP>:<PORT>

Beispiel:

openssl s_client -showcerts -connect foo.bar.lan:25

Der Befehl baut eine Verbindung zum Dienst auf und zeigt unter anderem das präsentierte Zertifikat an.

Noch übersichtlicher wird die Ausgabe mit:

openssl s_client -showcerts -connect <FQDN>:<PORT> </dev/null | openssl x509 -text
Damit erhältst du die Zertifikatsinformationen in einer deutlich besser lesbaren Form. Anschließend kannst du die Ausgabe nach Belieben weiter filtern – beispielsweise mit grep, um gezielt nach Informationen wie Issuer, Subject, Not Before oder Not After zu suchen.

SNI nicht vergessen

Gerade bei Load Balancern oder Webservern mit mehreren virtuellen Hosts kann es notwendig sein, zusätzlich den gewünschten Servernamen per SNI (Server Name Indication) mitzugeben. Andernfalls bekommst du möglicherweise das falsche Zertifikat präsentiert.

Das sieht dann beispielsweise so aus:

openssl s_client -showcerts \
-servername bar.foo.lan \
-connect bar.foo.lan:443 </dev/null | openssl x509 -text

Fazit

Natürlich kann OpenSSL deutlich mehr, als nur als Client auftreten. Zusammen mit Werkzeugen wie nc, curl, dig, ss oder netstat gehört es für mich zu den wichtigsten Helfern bei der täglichen Fehlersuche.

Wenn es darum geht, Services mit TLS-Zertifikaten schnell zu überprüfen, lassen sich mit den beiden vorgestellten Befehlen die Fehlerquellen schnell und zuverlässig eingrenzen.

Hier findest du weitere » Cheat Sheets die dir das Leben als Linux-Admin leichter machen.

icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook
Twitter
LinkedIn
XING
WhatsApp
Email

Der Beitrag Cheat Sheet: OpenSSL für Zertifikate erschien zuerst auf ASPICON.

]]>