Warum DB Links problematisch sind
Oracle DB Links ermöglichen direkte Abfragen auf entfernte Datenbanken. Das ist bequem, erzeugt aber enge Laufzeitabhängigkeiten zwischen Systemen. Bei Cloud- und PostgreSQL-Migrationen werden diese Abhängigkeiten schnell zum Blocker.
Was geprüft werden muss
| Verwendete Links | Welche Schemas, Views, Packages oder Jobs nutzen DB Links? |
| Richtung | Liest Oracle nur Daten oder schreibt es auch in entfernte Systeme? |
| Volumen | Geht es um kleine Referenzdaten oder große operative Datenmengen? |
| Transaktionen | Gibt es fachliche Erwartungen an verteilte Transaktionen? |
| Synonyme | Verbergen Synonyme die eigentliche Remote-Abhängigkeit? |
Mögliche Zielmuster
- Daten replizieren: lokale Kopien für Lesezugriffe und Reporting.
- API statt DB Link: fachlich kontrollierte Schnittstellen.
- Eventing: Änderungen als Ereignisse verteilen.
- ETL/ELT: kontrollierte Ladeprozesse statt Live-Abfragen.
- Hybridphase: DB Links temporär dokumentiert weiter betreiben, aber mit Ablöseplan.
Risikobewertung
Ein read-only DB Link auf kleine Referenzdaten ist meist beherrschbar. Schreibende Links, verteilte Abfragen in Packages oder DB Links in Batch-Jobs sind deutlich kritischer. Besonders riskant sind versteckte Zugriffe über Synonyme.
Assessment-Empfehlung
GCON-DB analysiert DB Links, Synonyme, Dependencies und betroffene SQL-/PLSQL-Objekte. Ziel ist ein Entkopplungsplan, bevor PostgreSQL oder Aurora als Zielplattform entschieden wird.
FAQ
Kann PostgreSQL Oracle DB Links ersetzen?
Nicht 1:1. Es gibt Foreign Data Wrapper und andere Integrationsmuster, aber die Architektur sollte nicht blind kopiert werden.
Sind DB Links bei AWS Lift & Shift erlaubt?
Technisch oft möglich, aber Netzwerk, Sicherheit, Latenz und Betrieb müssen geprüft werden.
Warum sind Synonyme wichtig?
Weil Synonyme Remote-Zugriffe verstecken können. Ein SQL sieht lokal aus, greift aber tatsächlich über einen DB Link auf ein anderes System zu.