Oracle Scheduler nach PostgreSQL migrieren

Nicht nur den Zeitplan übertragen

Ein täglicher Job kann fachlich an einen Import, einen Monatsabschluss oder die Verfügbarkeit eines Fremdsystems gebunden sein. Deshalb beginnt die Migration bei Auslöser, Wirkung und Verantwortlichkeit – nicht bei der Übersetzung eines Zeitplanausdrucks.

Klären Sie, ob ein Job SQL, PL/SQL oder externe Programme aufruft. Berücksichtigen Sie auch deaktivierte Jobs: Sie können für Jahresabschlüsse oder seltene Wiederanläufe weiterhin relevant sein.

Eine erste Oracle-Inventur

Die folgende lesende Abfrage betrachtet Scheduler-Jobs des angemeldeten Oracle-Benutzers. Sie ist keine vollständige systemweite Bestandsaufnahme und erfasst keine separaten Altbestände aus DBMS_JOB.

SELECT job_name,
       job_type,
       job_action,
       repeat_interval,
       enabled,
       state
FROM user_scheduler_jobs
ORDER BY job_name;

• Job-Definition um Laufzeit, letzte Fehler, Zielsystem und fachlichen Besitzer ergänzen.
• Job Chains, Kalender, Programme und Credentials getrennt aufnehmen.
• Zusätzliche Schemas und DBMS_JOB-Bestände mit passendem Zugriff prüfen.
• Betriebshandbücher und Anwendungsteams einbeziehen: Nicht jede Abhängigkeit steht im Datenbankkatalog.

Den Zielmechanismus auswählen

Für wiederkehrende SQL-Aufgaben kann pg_cron eine Option sein, sofern die Erweiterung im gewählten Betrieb verfügbar und eingerichtet ist. Für komplexere Abhängigkeiten, externe Prozesse und zentrale Wiederanlaufsteuerung ist eine externe Orchestrierung zu prüfen. Fachliche Prozesse können auch in der Anwendung organisiert werden.

Bewerten Sie Auswahl und Betrieb gemeinsam: Wer bemerkt einen ausgefallenen Lauf? Wer darf einen Job erneut starten? Wie werden Ausführungsprotokolle aufbewahrt? Wo liegen Zugangsdaten und wie werden sie erneuert?

Ein begrenztes pg_cron-Beispiel

Bei bereits installierter und betriebsbereit konfigurierter Erweiterung lässt sich ein harmloser Demonstrationsjob anlegen. Er führt nur eine Abfrage aus. Die Zeitzone folgt der jeweiligen pg_cron-Konfiguration; der Ausdruck allein legt sie nicht fest.

SELECT cron.schedule(
  'gcon-demo-heartbeat',
  '15 2 * * *',
  $$SELECT 1$$
);

-- Nach dem Test denselben Demo-Job entfernen:
SELECT cron.unschedule('gcon-demo-heartbeat');

Das Beispiel ersetzt weder Überwachung noch eine vollständige Retry-Strategie. Ob ein fachlicher Job wiederholt werden darf, hängt vor allem davon ab, welche Ergebnisse oder Nebenwirkungen er bereits erzeugt hat.

Fehlerfälle vor der Umstellung testen

• Zielsystem ist zum Startzeitpunkt nicht erreichbar.
• Ein Lauf dauert länger als das geplante Intervall.
• Die Verarbeitung bricht nach einem Teilergebnis ab.
• Ein Wiederanlauf darf dieselben Geschäftsdaten nicht doppelt verarbeiten.
• Zeitzonenwechsel, Wartungsfenster und Datenbank-Failover beeinflussen den Ausführungszeitpunkt.

Halten Sie für jeden produktiven Job Auslöser, Zielmechanismus, Erfolgsnachweis, Wiederanlauf und Verantwortlichkeit fest. Diese Liste ist die Grundlage der Betriebsabnahme.