Bei asynchronem Data-Guard-Transport kann hohe Redo-Erzeugung auf dem Primary dazu führen, dass die Übertragung zur physischen Standby-Datenbank dem konfigurierten Lag-Ziel nicht mehr folgt. Oracle AI Database 26ai ergänzt dafür eine transport-lag-basierte Redo-Priorisierung: Nähert sich der Transport-Lag dem gesetzten Schwellwert, kann Resource Manager redo-intensive Batch- oder Wartungssessions vorübergehend bremsen. OLTP-Sessions behalten dabei ihre normale Priorität.
Schwellwert am ASYNC-Ziel konfigurieren
Die Funktion wird am Primary pro asynchronem physischem Standby-Ziel über LOG_ARCHIVE_DEST_n aktiviert. Ein positiver Wert gibt den Ziel-Lag in Sekunden an; 0 (Standard) deaktiviert die Priorisierung. Beispiel mit einem bewusst kleinen Testwert:
ALTER SYSTEM SET LOG_ARCHIVE_DEST_3 =
'SERVICE=standby1 ASYNC NOAFFIRM
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=standby1
REDO_PRIORITIZATION_WHEN_TRANSPORT_LAGS_BY_SEC=20';Der Parameter gilt ausschließlich für ASYNC-Redo-Transport zu einer physischen Standby-Datenbank. Er ist nicht mit SYNC oder einem LOCATION-Ziel kombinierbar. Oracle AI Database 26ai unterstützt das Attribut ab Release Update 23.26.3; prüfen Sie daher vor dem Rollout den RU-Stand von Primary und Betriebsumgebung.
Was die Funktion tut – und was nicht
Die Datenbank reagiert auf den gemeldeten Transport-Lag, indem sie Sessions mit hoher Redo-Erzeugung temporär verzögert; Batch-Verarbeitung läuft also langsamer, statt OLTP unnötig auszubremsen. Sobald die Drucksituation nachlässt, können die betroffenen Sessions wieder normal weiterarbeiten.
Das ersetzt weder Netzwerk- und Standby-Kapazitätsplanung noch ändert es den Data-Guard-Schutzmodus: Ein ASYNC-Ziel wird dadurch nicht zu SYNC, und ein konfigurierter Schwellenwert ist keine Garantie, dass der Lag nie darüber steigt. Überwachen Sie weiterhin Transport- und Apply-Lag, Zielzustand und Redo-Rate. Setzen Sie den Wert anhand des gewünschten RPO und realistischer Lasttests, nicht als pauschalen Default.
Einführung mit kontrolliertem Test
- Version und RU prüfen: Die Funktion ist erst ab 26ai RU 23.26.3 verfügbar.
- Das korrekte
LOG_ARCHIVE_DEST_nfür das physische ASYNC-Ziel identifizieren. - Den Lag-Schwellwert mit dem fachlichen RPO- und Alarmkonzept abstimmen.
- In einer Testumgebung redo-intensive Batch-Last erzeugen und OLTP-Latenz sowie Transport-Lag beobachten.
- Nachweisen, dass die Batch-Rate bei Lag-Druck sinkt und sich nach Entlastung erholt.
Fazit
Transport-Lag-basierte Redo-Priorisierung hilft, bei konkurrierender OLTP- und Batch-Last die Standby-Aktualität und interaktive Antwortzeiten auszubalancieren. Ihr Nutzen hängt von einer passenden ASYNC-Konfiguration, einem sinnvoll gewählten Lag-Ziel und sauberem Monitoring ab – sie ist eine Ergänzung der Data-Guard-Architektur, kein Ersatz dafür.
Weiterführend: Oracles Dokumentation zu REDO_PRIORITIZATION_WHEN_TRANSPORT_LAGS_BY_SEC, zur automatischen Redo-Priorisierung im Resource Manager und zu den Neuerungen in RU 23.26.3.