Servicewelten · ASPICON Newsarchiv

DBA-Praxistest: Parallelisierung von Autovacuum in PostgreSQL 19

Sebastian Naumann — Fri, 30 Oct 2026 14:46:58 +0000

Home → Servicewelten

DBA-Praxistest: Parallelisierung von Autovacuum in PostgreSQL 19

Verfasst von Sebastian Naumann
30 Oktober 2026
15:46
Datenbank, PostgreSQL

Bereinigt Autovacuum große Tabellen schneller, wenn zusätzliche Worker die Indexarbeit übernehmen? Wir haben die Parallelisierung in PostgreSQL 19 untersucht. Das Ergebnis: Die parallelen Worker wurden zuverlässig gestartet – ein reproduzierbarer Geschwindigkeitsvorteil blieb unter den gewählten Laborbedingungen jedoch aus.

Autovacuum gehört zur laufenden Wartung einer PostgreSQL-Datenbank. Es sorgt unter anderem dafür, dass Speicherplatz nicht mehr benötigter Zeilenversionen wiederverwendet werden kann. Solche sogenannten Dead Tuples entstehen beispielsweise durch Updates und Löschungen.

In PostgreSQL 19 ist es mit Autovacuum möglich, bestimmte Arbeiten an Indizes parallel auszuführen. Ob zusätzliche Worker auch die gesamte Bereinigung beschleunigen, hängt jedoch von der Tabelle, ihren Indizes und den verfügbaren Systemressourcen ab.

Was wird bei Autovacuum parallelisiert?

Die Parallelisierung betrifft die Index-Vacuum- und Index-Cleanup-Phasen. Sie verteilt nicht sämtliche Arbeiten eines Autovacuum-Durchlaufs auf mehrere Prozesse.

Dabei sind zwei Einstellungen zu unterscheiden:

autovacuum_max_workers begrenzt die gleichzeitig laufenden regulären Autovacuum-Worker, die unterschiedliche Tabellen bearbeiten können.
autovacuum_max_parallel_workers begrenzt die zusätzlichen parallelen Worker, die ein einzelner Autovacuum-Worker für die Indexbearbeitung einsetzen kann. Der dokumentierte Standardwert ist 0; damit ist diese Parallelisierung deaktiviert.

Über den Tabellenparameter autovacuum_parallel_workers lässt sich die Parallelität zusätzlich pro Tabelle begrenzen. Wie viele Worker tatsächlich zum Einsatz kommen, hängt unter anderem von geeigneten Indizes und verfügbaren Worker-Kapazitäten ab. Eine konfigurierte Obergrenze garantiert daher keine entsprechende Anzahl gestarteter Prozesse.

Unser Testaufbau: drei Tabellenklassen und drei Parallelitätsstufen

Die Versuche liefen auf einer einzelnen PostgreSQL-19beta3-Instanz in einer virtuellen Maschine mit 16 vCPUs und 64 GB RAM. Untersucht wurden drei Tabellenklassen:

Tabellenklasse	Zeilen vor dem Löschen	Indexstruktur	Gelöschte Zeilen (Dead Tuples)
Kleine Tabellen	10.000 je Tabelle	Vier Indizes mit jeweils ca. 600 kB	Ca. 1.428 je Tabelle
Große Tabelle mit großen Indizes	10 Millionen	Vier vollständige Indizes mit jeweils ca. 563 MB	1.428.571
Große Tabelle mit kleinen Indizes	10 Millionen	Vier partielle Indizes mit jeweils ca. 5,7 MB	1.428.571

Die partiellen Indizes erfassten nur jede hundertste Zeile. Die Löschmenge wurde jeweils über das Muster id % 7 = 0 erzeugt.

Getestet wurden drei Einstellungen:

P0: keine parallelen Worker
P2: maximal zwei parallele Worker
P4: maximal vier parallele Worker

Bei den großen Tabellen wurde nach einem vorbereitenden `VACUUM (FREEZE, ANALYZE)` die definierte Löschmenge erzeugt. Anschließend bereinigte Autovacuum die entstandenen Dead Tuples. Die Laufzeiten stammen aus den PostgreSQL-Abschlusslogs. Ergänzend wurden CPU- und I/O‑Daten mit `vmstat` und `iostat` erfasst.

Die Ergebnisse: Keine Variante war durchgehend schneller

Testszenario	P0	P2	P4
Kleine Tabellen	Median 0,11 s	Median 0,06 s	Ca. 0,07 s je Tabelle
Große Tabelle mit großen Indizes	Median 974,30 s	Median 1.140,31 s	Median 1.027,73 s
Große Tabelle mit kleinen, partiellen Indizes	Median 979,28 s	Median 1.005,33 s	Median 1.033,17 s

Bei den kleinen Tabellen waren die Vacuum-Laufzeiten sehr kurz. Dadurch hatten WAL-Aufkommen, Checkpoints, Cache-Zustand und die Messauflösung einen relativ großen Einfluss. Die P4-Reihe wurde mit vier kleinen Tabellen durchgeführt und ist deshalb nur eingeschränkt mit den Einzeltabellenläufen vergleichbar.

Bei den großen Tabellen zeigten die `vmstat`- und `iostat`-Daten deutliche Schwankungen bei I/O‑Wartezeit, Schreiblatenz und Geräteauslastung. Diese Unterschiede traten auch innerhalb derselben Konfiguration auf und waren teilweise größer als der erwartete Effekt der Parallelisierung. Bei der großen Tabelle mit partiellen Indizes lagen beispielsweise bereits die P0-Laufzeiten zwischen 816,40 und 1.477,53 Sekunden.

Wurden die parallelen Worker tatsächlich eingesetzt?

Die PostgreSQL-Abschlusslogs bestätigen, dass die parallelen Worker tatsächlich eingesetzt wurden. Bei P2 wurden jeweils zwei Worker gestartet. Bei P4 wurden trotz der Einstellung von maximal vier Worker jeweils nur drei geplant und gestartet (bedingt durch die Konfiguration oder Anzahl der verfügbaren Indizes).

Nächster Schritt: Test unter Anwendungslast

In einer zweiten Testphase – welche wir zu gegebener Zeit ebenfalls hier veröffentlichen werden – wollen wir die Parallelisierung unter realistischeren Betriebsbedingungen untersuchen. Geplant sind dedizierte oder stark isolierte Systeme und ein paralleler OLTP-Workload mit INSERT-, UPDATE-, DELETE- und SELECT-Operationen. Dabei sollen mehrere Tabellen mit unterschiedlichen Änderungsraten und Indexstrukturen gleichzeitig betrachtet werden.

Die Varianten P0, P2 und P4 sollen automatisiert, in wechselnder Reihenfolge und mit mehreren Wiederholungen getestet werden. Neben der Dauer des Autovacuum-Laufs wollen wir auch den Einfluss auf die Anwendung messen: etwa Transaktionsdurchsatz, Antwortzeiten sowie p95- und p99-Latenzen. Ergänzend erfassen wir PostgreSQL-interne Werte, WAL-Aufkommen, Checkpoints und Systemmetriken wie CPU-Auslastung, I/O‑Wartezeiten und Storage-Latenzen.

So soll eine belastbare Entscheidungshilfe entstehen: Unter welchen Ressourcen- und Lastbedingungen lohnt sich die Parallelisierung – und wann konkurrieren die zusätzlichen Worker vor allem um dieselben Ressourcen?

Unsere Einordnung und Fazit des Tests

Der Test bestätigt, dass PostgreSQL 19 parallele Worker für die Index-Vacuum-Arbeiten einsetzt. Einen reproduzierbaren Zeitgewinn konnten wir in diesem Laboraufbau jedoch nicht messen. Bei den sehr kurzen Läufen mit kleinen Tabellen war der Effekt kaum isolierbar. Bei den großen Tabellen lagen die Mediane nahe beieinander. Stellenweise führten parallele Worker aufgrund von I/O‑Konkurrenz (*Resource Contention*) sogar zu leichten Laufzeitverlängerungen.

Das ist kein Beleg dafür, dass paralleles Autovacuum grundsätzlich keinen Vorteil bringt. Die Ergebnisse gelten für eine einzelne virtuelle Maschine, einen isolierten Test ohne Anwendungslast und die hier verwendeten Tabellen und Indizes. Sie lassen sich daher nicht ohne Weiteres auf produktive PostgreSQL-Systeme übertragen. Auch Parameter wie maintenance_work_mem und der verfügbare Speicherdurchsatz können beeinflussen, ob zusätzliche Worker ihre Arbeit tatsächlich schneller erledigen.

Nachtrag: PostgreSQL 19 RC1 – Bugfixes für paralleles Autovacuum

Nach unserem Redaktionsschluss wurde PostgreSQL 19 RC1 veröffentlicht. Der Release Candidate enthält mehrere Fehlerkorrekturen für das neue Feature Parallel Autovacuum (autovacuum_max_parallel_workers).

Die wichtigsten Verbesserungen im Überblick:

Stabilität:
Behebung eines möglichen Absturzes, wenn für parallele Worker kein Dynamic Shared Memory bereitgestellt werden konnte.
Ressourcensteuerung:
Änderungen an den VACUUM-Cost-Parametern werden nun auch während laufender paralleler Verarbeitung zuverlässig an die Worker weitergegeben.
Monitoring:
Korrektur der Wartezeitenerfassung (pg_stat_progress_vacuum.delay_time) sowie der I/O‑Zeitmessung in den Autovacuum-Logs.
GIN-Indizes:
Korrektur der Bereinigung der GIN Pending List, um unnötig lange Verarbeitung bei gleichzeitig laufenden Inserts zu vermeiden.

Fazit:
Die Korrekturen verbessern insbesondere die Stabilität, Ressourcensteuerung und Beobachtbarkeit des parallelen Autovacuums.

Hinweis:
Eine Änderung von autovacuum_max_parallel_workers beeinflusst weiterhin nur neu gestartete VACUUM-Vorgänge, nicht bereits laufende Worker.

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

Share this article

Der Beitrag DBA-Praxistest: Parallelisierung von Autovacuum in PostgreSQL 19 erschien zuerst auf ASPICON.

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

Marcel Heinrich — Wed, 21 Oct 2026 12:23:52 +0000

Home → Servicewelten

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

Verfasst von Marcel Heinrich
21 Oktober 2026
14:23
Critical Patch Update, Fusion Middleware, Java, MySQL, Oracle, Oracle Database, Oracle Datenbank 12c /18c /19c /21c, Oracle Enterprise Manager, Oracle WebLogic Server, Security

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 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
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.

Share this article

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

DBA-Praxistest: PostgreSQL 19 pg_plan_advice im Labortest

Sebastian Naumann — Fri, 16 Oct 2026 13:02:58 +0000

Home → Servicewelten

DBA-Praxistest: PostgreSQL 19 pg_plan_advice im Labortest

Verfasst von Sebastian Naumann
16 Oktober 2026
15:02
Datenbank, PostgreSQL

Mit pg_plan_advice Ausführungspläne gezielt beeinflussen und Vorgaben mit pg_stash_advice speichern: Wir haben untersucht, was das für die Abfrageperformance bedeutet – und wo die Grenzen liegen.

Index Scan oder Seq Scan? Hash Join oder Nested Loop? Normalerweise entscheidet der PostgreSQL-Planner, welcher Ausführungsplan voraussichtlich am günstigsten ist. Doch was tun, wenn eine Abfrage auffällig langsam läuft und ein anderer Plan bessere Ergebnisse verspricht?

pg_plan_advice und pg_stash_advice im DBA-Test

Genau hier kommen pg_plan_advice und pg_stash_advice ins Spiel: Mit pg_plan_advice lassen sich bestimmte Planner-Entscheidungen gezielt beeinflussen – etwa die Zugriffsmethode, Join-Reihenfolge oder das Join-Verfahren. Das Modul schränkt dabei die Auswahl des Planners ein. pg_stash_advice ergänzt die Möglichkeit, solche Vorgaben einer Query-ID zuzuordnen und bei der Planung passender Abfragen automatisch anzuwenden.

Wir haben beide Werkzeuge mit PostgreSQL 19beta3 im Labor getestet. Die wichtigste Erkenntnis: Mehr Kontrolle über den Ausführungsplan bedeutet nicht automatisch mehr Performance.

Unser Testaufbau mit PostgreSQL 19beta3

Getestet wurde auf einer einzelnen VMware-Instanz mit 16 virtuellen CPUs und 64 GB RAM. PostgreSQL war mit 128 MiB shared_buffers und bis zu zwei parallelen Workern pro Abfrage konfiguriert.

Die künstliche Datenbasis bestand aus 500.000 Verkaufsdatensätzen sowie Kunden‑, Produkt- und Datumstabellen. Wir verglichen die freie Plannerwahl mit gezielten Vorgaben für Zugriffsmethoden und Joins. Hinzu kamen Tests mit geänderter Datenverteilung und gespeicherten Vorgaben.

Die vollständigen Vergleichsserien enthielten jeweils zwei Aufwärmläufe und zehn Messungen pro Variante. Insgesamt entstanden 471 verwertbare Messungen. Zusätzlich prüften wir, ob die Abfragen weiterhin dieselben Ergebnisse lieferten.

Welche Auswirkungen hatten die Planvorgaben?

Index Scan oder Seq Scan: Die Treffermenge zählt

Bei einer Abfrage mit hoher Selektiviät benötigte ein erzwungener vollständiger Tabellenscan rund 33 statt 0,14 Millisekunden. Mehrere vorgegebene Join-Verfahren machten die untersuchten Abfragen ebenfalls langsamer.

Die praktische Konsequenz: Dass eine Vorgabe angewendet wird, sagt noch nichts über ihren Nutzen aus. Entscheidend ist der gemessene Vergleich mit der freien Plannerwahl.

Ein passender Index brachte einen deutlichen Vorteil

Beim Produktfilter sank die Laufzeit mit einem passenden Index von etwa 48 auf 1,26 Millisekunden, jeweils als Median gemessen.

Die Werte stammen aus getrennten Messserien. Zusätzlicher Speicherbedarf und Schreibaufwand durch den Index wurden nicht untersucht. Trotzdem unterstreicht das Ergebnis: Zur PostgreSQL-Query-Optimierung gehört zunächst die Prüfung von Statistiken, Abfragestruktur und vorhandenen Indizes.

Worauf solltest du bei pg_stash_advice achten?

Gleiche Query-ID bedeutet nicht gleicher optimaler Plan

Abfragen mit unterschiedlichen Suchwerten können dieselbe Query-ID besitzen, obwohl verschiedene Ausführungspläne sinnvoll wären. Ein Filter auf ein seltenes Produkt kann beispielsweise von einem anderen Zugriff profitieren als ein Filter auf einen häufig vorkommenden Wert.

Eine gespeicherte Planvorgabe sollte deshalb mit repräsentativen Suchwerten geprüft werden. Nach Änderungen der Datenverteilung ist erneut zu bewerten, ob sie weiterhin einen Vorteil bringt.

Gelöschte Vorgaben können über zwischengespeicherte Pläne nachwirken

Im Labor zeigte sich: Nach dem Entfernen einer gespeicherten Vorgabe kann ein bereits zwischengespeicherter Ausführungsplan weiterverwendet werden.

Zum Rücknahmeweg gehört daher die Kontrolle, welcher Plan anschließend tatsächlich ausgeführt wird. Ein gelöschter Advice-Eintrag allein belegt noch nicht, dass wieder ein unbeeinflusster Plan zum Einsatz kommt.

Unser Tipp zur PostgreSQL-Query-Optimierung

Bevor du eine Planvorgabe dauerhaft einsetzt, empfiehlt sich dieses Vorgehen:

Ausgangslage prüfen:
Statistiken, Indizes und Abfragestruktur untersuchen.
Gezielt eingreifen:
Nur die Planner-Entscheidungen beeinflussen, für die es einen begründeten Anlass gibt.
Wiederholt vergleichen:
Die Variante gegen die freie Plannerwahl messen und unterschiedliche Suchwerte berücksichtigen.
Ergebnisse kontrollieren:
Neben der Laufzeit auch die Ergebnisgleichheit prüfen.
Wirkung nachverfolgen:
Nach Datenänderungen erneut testen und bei einer Rücknahme auch zwischengespeicherte Pläne kontrollieren.

Ausblick: KI-gestützte Abfrageoptimierung

Ein möglicher Folgeversuch wäre ein kontrollierter, KI-gestützter Optimierungskreislauf. Dabei würde KI auffällig langsame Abfragen anhand ihrer Laufzeitdaten erkennen, Ausgangspläne analysieren und wenige begründete Alternativen mit pg_plan_advice testen.

Nur eine wiederholt bessere Vorgabe würde nach Prüfung verschiedener Suchwerte und der Ergebnisgleichheit über pg_stash_advice für einen begrenzten Testbetrieb hinterlegt. Anschließend müsste sie regelmäßig mit der freien Plannerwahl verglichen und bei Verschlechterungen zurückgenommen werden.

Dieser Kreislauf war nicht Bestandteil des beschriebenen Labortests. Ziel eines Folgeversuchs wäre eine überprüfbare Optimierung, die auch erkennt, wann ihre eigene Empfehlung nicht mehr sinnvoll ist.

Fazit: Plan Advice gezielt einsetzen und regelmäßig prüfen

pg_plan_advice und pg_stash_advice bieten zusätzliche Möglichkeiten, PostgreSQL-Ausführungspläne zu beeinflussen und nachgewiesene Planungsprobleme zu bearbeiten. Gute Statistiken, passende Indizes und belastbare Vergleichsmessungen bleiben dabei entscheidend.

Unsere Ergebnisse beziehen sich auf den beschriebenen PostgreSQL-19beta3-Laboraufbau. Sie lassen sich nicht pauschal auf andere Versionen oder produktive Umgebungen übertragen.

Du möchtest langsame PostgreSQL-Abfragen analysieren oder das Optimierungspotenzial deiner Ausführungspläne bewerten lassen? Unsere PostgreSQL-DBAs unterstützen dich dabei, Ursachen einzugrenzen und geeignete Maßnahmen für deine Umgebung zu prüfen.

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

Share this article

Der Beitrag DBA-Praxistest: PostgreSQL 19 pg_plan_advice im Labortest erschien zuerst auf ASPICON.

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

Marcel Heinrich — Tue, 29 Sep 2026 06:56:02 +0000

Home → Servicewelten

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

Verfasst von Marcel Heinrich
29 September 2026
08:56
Datenbank, Linux, Oracle Database, Oracle Datenbank 12c /18c /19c /21c, Oracle Linux, Red Hat, Red Hat Enterprise Linux / RHEL

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

Share this article

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

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

Home → Servicewelten

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.

Patch Update und Release Info PostgreSQL

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

Home → Servicewelten

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.

Oracle Critical Patch Update Juli 2026: 1.449 Sicherheitsupdates veröffentlicht

Marcel Heinrich — Tue, 28 Jul 2026 09:34:55 +0000

Home → Servicewelten

Oracle Critical Patch Update Juli 2026: 1.449 Sicherheitsupdates veröffentlicht

Verfasst von Marcel Heinrich
28 Juli 2026
11:34
Critical Patch Update, Fusion Middleware, Java, MySQL, Oracle, Oracle Database, Oracle Datenbank 12c /18c /19c /21c, Oracle Enterprise Manager, Oracle WebLogic Server, Security

Oracle hat am 21. Juli 2026 das dritte Critical Patch Update des Jahres veröffentlicht. Besonders betroffen ist diesmal erneut die Oracle Fusion Middleware mit 355 Sicherheitsupdates – darunter mehrere Schwachstellen mit dem maximalen CVSS-Score von 10.0. Insgesamt enthält das Juli-CPU » 1.449 Sicherheitsupdates.

Wie bei jedem Critical Patch Update empfiehlt Oracle, die bereitgestellten Updates zeitnah einzuspielen. Viele der behobenen Schwachstellen können über das Netzwerk ausgenutzt werden – teilweise sogar ohne vorherige Authentifizierung.

Welche Oracle-Produkte sind besonders betroffen und wo besteht der größte Handlungsbedarf? Um dir die Einordnung zu erleichtern, haben wir die wichtigsten Informationen zu den relevanten Oracle-Lösungen kompakt zusammengefasst. Die anschließende Übersicht der CVSS Base Scores unterstützt dich dabei, die Kritikalität der Schwachstellen besser zu bewerten.

Oracle Fusion Middleware (WebLogic Server)

Mit » 355 Sicherheitsupdates weist die Oracle Fusion Middleware erneut die höchste Anzahl an behobenen Schwachstellen auf. Davon sind 219 Sicherheitslücken remote ohne Authentifizierung ausnutzbar. Besonders kritisch sind mehrere Schwachstellen mit dem maximalen CVSS-Score von 10.0, die zeitnah behoben werden sollten.

Oracle MySQL Server

Im Bereich Oracle MySQL werden » 54 Sicherheitslücken geschlossen. Neun davon sind remote und ohne Authentifizierung angreifbar. Der höchste Base Score liegt bei CVSS 8.5.

Enterprise Manager (Cloud Control)

Auch der Oracle Enterprise Manager erhält im Juli-CPU » 27 Sicherheitsupdates. 13 Schwachstellen gelten als remote ohne Authentifizierung ausnutzbar. Die höchste Risikobewertung liegt bei CVSS 9.8. Oracle weist außerdem darauf hin, dass Enterprise Manager zusätzlich von betroffenen Oracle Database- und Fusion Middleware-Komponenten abhängen kann.

Oracle Java SE

Für Oracle Java SE veröffentlicht Oracle » 19 Sicherheitsupdates. 17 Schwachstellen können ohne Authentifizierung über das Netzwerk ausgenutzt werden. Der höchste CVSS-Wert beträgt 7.8. Betroffen sind die unterstützten Versionen Java SE 8, 11, 17, 21, 25 und 26.

Oracle Database Server

Für den Oracle Database Server stellt Oracle » 15 Sicherheitsupdates bereit. Sechs Schwachstellen können über das Netzwerk ohne vorherige Authentifizierung ausgenutzt werden. Drei der Patches sind auch für Client-Only-Installationen relevant. Die kritischste Schwachstelle erreicht einen CVSS-Score von 9.9. Betroffen sind unter anderem Oracle Database 19c, 21c und 23ai.

Die folgende Übersicht stellt die wichtigsten Informationen noch einmal kompakt dar – inklusive des jeweils höchsten CVSS-Basiswerts pro Produktbereich.

Betroffenes Produkt	Anzahl Patches	Remote ausnutzbar?	Höchster Base Score
Oracle Fusion Middleware (WebLogic Server)	355	ja (219)	10.0
Oracle MySQL Server	54	ja (9)	8.5
Enterprise Manager (Cloud Control)	27	ja (13)	9.8
Oracle Java SE	19	ja (17)	7.8
Oracle Database Server	15	ja (6)	9.9

Detaillierte Informationen zum aktuellen Critical Patch Update sowie zu früheren Updates und Sicherheitswarnungen 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:

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

Fazit und Empfehlung

Mit 1.449 Sicherheitsupdates unterstreicht das Oracle Critical Patch Update Juli 2026 die Bedeutung eines konsequenten Patch-Managements. Insbesondere Unternehmen, die Oracle Fusion Middleware, Oracle Database, MySQL, Java SE oder den Enterprise Manager einsetzen, sollten die bereitgestellten Updates zeitnah bewerten und einspielen.

Du möchtest wissen, welche Patches für deine Oracle-Umgebung relevant sind oder benötigst Unterstützung bei Planung und Durchführung des Updates? Wir unterstützen dich gerne.

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
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.

Share this article

Der Beitrag Oracle Critical Patch Update Juli 2026: 1.449 Sicherheitsupdates veröffentlicht erschien zuerst auf ASPICON.

Dbvisit kündigt Preisanpassung für StandbyMP ab August 2026 an

Marcel Heinrich — Tue, 23 Jun 2026 11:53:52 +0000

Home → Servicewelten

Dbvisit kündigt Preisanpassung für StandbyMP ab August 2026 an

Verfasst von Marcel Heinrich
23 Juni 2026
13:53
Dbvisit Standby, Microsoft, Oracle, PostgreSQL, Standby Datenbank

Dbvisit hat eine Anpassung der Preise für seine Disaster-Recovery-Lösung StandbyMP angekündigt. Die neuen Listenpreise treten zum 1. August 2026 in Kraft.

Nach Angaben von Dbvisit handelt es sich um die erste wesentliche Preisanpassung seit rund fünf Jahren. Als Begründung nennt das Unternehmen unter anderem Investitionen in die Weiterentwicklung der Plattform sowie den Ausbau von Support- und Engineering-Ressourcen.

Anpassungen nach Produktlinie

Die Preisanpassungen betreffen die StandbyMP-Produkte in unterschiedlichem Umfang:

StandbyMP für Oracle: +12 %
StandbyMP für SQL Server: +8 %
StandbyMP für PostgreSQL: keine Preisänderung

Anpassungen bei Laufzeitlizenzen

Für die Verlängerung von Laufzeitlizenzen (Term Licenses) führt Dbvisit ab 1. September 2026 eine jährliche Preisanpassung von 3 % pro Vertragsjahr ein. Die Erhöhung ist dabei auf den jeweils aktuellen Listenpreis begrenzt.

Beispiele:

Verlängerung um 1 Jahr: +3 %
Verlängerung um 2 Jahre: +6 %
Verlängerung um 3 Jahre: +9 %

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

Kontakt

Marcel
Senior Account Manager bei ASPICON

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

Share this article

Der Beitrag Dbvisit kündigt Preisanpassung für StandbyMP ab August 2026 an erschien zuerst auf ASPICON.

Servicewelten · ASPICON Newsarchiv

DBA-Praxistest: Parallelisierung von Autovacuum in PostgreSQL 19

DBA-Praxistest: Parallelisierung von Autovacuum in PostgreSQL 19

Was wird bei Autovacuum parallelisiert?

Unser Testaufbau: drei Tabellenklassen und drei Parallelitätsstufen

Die Ergebnisse: Keine Variante war durchgehend schneller

Wurden die parallelen Worker tatsächlich eingesetzt?

Nächster Schritt: Test unter Anwendungslast

Unsere Einordnung und Fazit des Tests

Nachtrag: PostgreSQL 19 RC1 – Bugfixes für paralleles Autovacuum

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

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

Oracle Fusion Middleware (WebLogic Server)

Oracle MySQL Server

Oracle Java SE

Oracle Database Server

Oracle Enterprise Manager (Cloud Control)

Fazit und Empfehlung

DBA-Praxistest: PostgreSQL 19 pg_plan_advice im Labortest

DBA-Praxistest: PostgreSQL 19 pg_plan_advice im Labortest

pg_plan_advice und pg_stash_advice im DBA-Test

Unser Testaufbau mit PostgreSQL 19beta3

Welche Auswirkungen hatten die Planvorgaben?

Worauf solltest du bei pg_stash_advice achten?

Unser Tipp zur PostgreSQL-Query-Optimierung

Ausblick: KI-gestützte Abfrageoptimierung

Fazit: Plan Advice gezielt einsetzen und regelmäßig prüfen

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

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

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

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

Oracle Critical Patch Update Juli 2026: 1.449 Sicherheitsupdates veröffentlicht

Oracle Critical Patch Update Juli 2026: 1.449 Sicherheitsupdates veröffentlicht

Oracle Fusion Middleware (WebLogic Server)

Oracle MySQL Server

Enterprise Manager (Cloud Control)

Oracle Java SE

Oracle Database Server

Fazit und Empfehlung

Dbvisit kündigt Preisanpassung für StandbyMP ab August 2026 an

Dbvisit kündigt Preisanpassung für StandbyMP ab August 2026 an

Anpassungen nach Produktlinie

Anpassungen bei Laufzeitlizenzen