Viele Anwendungen benötigen eine Suche über unterschiedliche Datenquellen: Kunden, Aufträge, Dokumente oder JSON-Daten liegen oft in getrennten Tabellen und Views. Oracle AI Database 26ai führt mit dem Paket DBMS_SEARCH einen zentralen Ubiquitous-Search-Index ein. Damit können mehrere Quellen in einem Index verwaltet und per Volltext- oder Bereichssuche abgefragt werden.
1. Mehrere Quellen in einem Suchmodell
Ein DBMS_SEARCH-Index kann Tabellen, Views und – je nach Szenario – JSON Duality Views als Datenquellen aufnehmen. Die Quellen müssen nicht vorher in einer Materialized View zusammengeführt werden. Das reduziert Integrationscode und vermeidet zusätzliche Synchronisationslogik, die bei klassischen Multi-Column- oder User-Data-Store-Ansätzen häufig nötig war.
Vor der Anlage sollte trotzdem ein einheitliches Suchmodell festgelegt werden. Welche Felder werden als Titel, Status, Zeitstempel oder Identifier ausgegeben? Welche Quellen dürfen gemeinsam durchsucht werden? Eine technische Zusammenführung ohne fachliche Metadaten führt schnell zu Treffern, die zwar korrekt indiziert, aber für Nutzer schwer einzuordnen sind.
2. Berechtigungen minimal halten
Der Index-Owner benötigt Zugriff auf die eingebundenen Datenquellen. Für Quellen aus anderen Schemas müssen SELECT- und je nach Betrieb erforderliche DML-Rechte bewusst vergeben werden. Zusätzlich verlangt die aktuelle DBMS_SEARCH-Funktionalität bestimmte Systemprivilegien wie CREATE SEQUENCE, CREATE TRIGGER und CREATE JOB.
Diese Rechte sollten nicht pauschal an Anwendungsschemas verteilt werden. Besser ist ein separater Index-Owner mit dokumentierter Rolle, klarer Quellenliste und einem kontrollierten Prozess für ADD_SOURCE, REMOVE_SOURCE und DROP_INDEX. So bleibt nachvollziehbar, welche Daten in der zentralen Suche sichtbar sind.
3. Hintergrundpflege und Datenaktualität überwachen
DBMS_SEARCH-Indizes werden im Hintergrund synchronisiert und optimiert. Dadurch entfallen normalerweise manuelle SYNC_INDEX- und OPTIMIZE_INDEX-Aufrufe. Für den Betrieb bedeutet das aber nicht, dass der Index sich selbst erklärt: Jobs, Fehler, Laufzeiten und die Aktualität der Treffer gehören ins Monitoring.
Definieren Sie eine fachliche Datenfrische, zum Beispiel „Suchtreffer höchstens wenige Minuten alt“. Prüfen Sie diese Zusage mit Testdaten und einem kontrollierten Aktualisierungsfall. Bei großen Quellen sollten außerdem Indexwachstum, I/O, Hintergrundjobs und Auswirkungen auf DML beobachtet werden.
4. Schemaänderungen als Betriebsrisiko behandeln
Wenn eine Tabelle oder View gelöscht oder umbenannt wird, entfernt das den zugehörigen Datenquelleneintrag nicht automatisch aus dem Suchindex. Bereits indizierte Daten können daher im Index verbleiben. Schemaänderungen müssen deshalb mit einem DBMS_SEARCH-Change verknüpft werden: Quelle entfernen, Indexzustand prüfen und gegebenenfalls die Quelle neu hinzufügen.
Das gilt besonders bei Deployments, bei denen Tabellen durch neue Versionen ersetzt werden. Ein kurzer Post-Deployment-Test sollte kontrollieren, ob neue und entfernte Quellen, Suchfilter und Berechtigungen noch zum Release passen.
5. Praktische DBA-Checkliste
- Suchdomäne, Quellen, Owner und fachliche Metadaten definieren.
- SELECT-, DML- und erforderliche Systemprivilegien minimal vergeben.
- Indexanlage, Quellenänderung und Entfernung in einem Runbook dokumentieren.
- Hintergrundjobs, Fehler, Indexgröße und Datenfrische überwachen.
- Volltext-, Range- und JSON-Suchfälle mit realistischen Daten testen.
- Schema-Deployments immer mit
ADD_SOURCEoderREMOVE_SOURCEabgleichen.
Fazit
DBMS_SEARCH in Oracle AI Database 26ai kann Volltext- und Bereichssuche über mehrere Datenquellen deutlich vereinfachen. Der Nutzen entsteht aber erst mit einem klaren Suchmodell, minimalen Rechten, überwachten Hintergrundjobs und einem sauberen Umgang mit Schemaänderungen. So bleibt die zentrale Suche leistungsfähig und kontrollierbar.
Weiterführend: Oracles Überblick zu Ubiquitous Search, die DBMS_SEARCH-Referenz und die Neuerungen in Oracle AI Database 26ai.