Code für Resilienz

Automatisierte Bereinigungsprozeduren definieren

Die Definition von automatisierten Bereinigungsverfahren hilft bei der Resilienz des Codes.

Während Sie Ihren Code entwickeln und Ihre Tests ausführen, müssen Sie Ihre Umgebung wiederholt zurücksetzen, während Sie Bugs beheben, die Performance verbessern und Ladestrategien optimieren. Mit dem vorzeitigen Erstellen von Bereinigungsverfahren können Sie diese Prozeduren bei der Entwicklung des Codes zu dem Punkt verbessern, an dem sie flexibel genug sein sollten, damit Sie Ihre Umgebung auf einen beliebigen gewünschten Status zurücksetzen können:

Alle zurücksetzen, keine Daten im Zielsystem
Setzen Sie die Umgebung auf den Status zurück, den sie vor dem letzten Ladevorgang hatte (dies umfasst Variablen, Status- oder Audittabellen usw.).
Setzen Sie die Umgebung zurück, sodass die Daten aus einem bestimmten Ladevorgang (oder batch_id oder run_id) in der gesamten Umgebung zurückgesetzt werden, ohne dass sich dies auf andere Daten auswirkt

Durch die Automatisierung des Bereinigungsprozesses wird in der Regel der Prozess effizienter ausgeführt. (Eine Liste der Tabellen, die zurückgesetzt werden müssen, oder SQL-Abfragen müssen nicht gefunden werden.) Durch die Automatisierung wird auch das Risiko deutlich reduziert, dass jemand den falschen Teil der Umgebung zurücksetzt. Dies ist insbesondere dann der Fall, wenn das Debugging eingeschleuchten wird und dass Personen gezwungen werden.

Da diese Cleanup-Verfahren feiner granuliert werden, können sie in die Integrationsprozesse aufgenommen werden. Es gibt zwei Möglichkeiten, die folgenden Vorteile zu nutzen:

Führen Sie vor dem Laden von Daten immer eine präemptive Bereinigung aus. Wenn Sie Daten laden, die einfach (mit einer Batch-ID oder einem bestimmten Datum) identifiziert werden können, können Sie vorherige Ladevorgänge mit demselben Dataset, das ausgefallen wäre, einfach überschreiben
Verwenden Sie diese Cleanup-Prozeduren bei Workflows im Falle eines Fehlers. Sie möchten den gesamten Ladevorgang nicht abbrechen, weil Sie für einen kurzen Zeitraum die Verbindung zur Quell- oder Zielumgebung unterbrochen haben. Angenommen, Sie laden Hunderte von Dateien und führen komplexe Transformationen für diese Dateien aus. Möchten Sie alles abbrechen, weil für eine geteilte Sekunde beim Zugriff auf nur eine der Dateien ein Problem aufgetreten ist, oder möchten Sie alles abschließen, diese Datei so bald wie möglich wiederholen und mehr drastische Kennzahlen ergreifen, wenn diese Datei noch nicht geladen werden kann? Je nach Stabilität der Umgebung, für die Sie sich gerade ausführen, können Sie mehrere Male versuchen, bevor Sie die entsprechenden Personen benachrichtigen. Ebenso können Sie basierend auf dem Ausfalltyp in Ihrer Umgebung eine Unterbrechung erzwingen, bevor Sie den Versuch wiederholen.

Sie sollten verschiedene Arten von Recovery-Prozeduren berücksichtigen. Für einfache Aufgaben ist es häufig ausreichend, nur den Vorgang zu wiederholen, der ohne andere Bereinigungs- oder Zurücksetzvorgänge nicht erfolgreich war. Wenn sich Code jedoch weiter entwickeln und komplexer wird, werden auch die aufgetretenen Fehler erhöht. Nachdem Sie Ladefehler behoben haben (der Ladevorgang selbst funktioniert nicht), können Sie in Geschäftsfehler ausführen (die Daten werden geladen, laden aber die falschen Daten, oder einige Berechnungen sind fehlerhaft). Sie sollten sorgfältig prüfen, wie Sie diese Arten von Korrekturen adressieren möchten. In frühen Phasen kann es gültig sein, alle zurückzusetzen, wenn Businessfehler auftreten. Sie möchten jedoch mehr feiner granulieren, wenn sich der Code weiterentwickelt hat, sodass Sie in Ihren Korrekturen noch verbreitern können.

Schleifen können in Oracle Data Integrator definiert werden, um Cleanup-Verfahren und Inkrementzähler einzubeziehen, die die Anzahl der Versuche verfolgen. Für eine bessere Verfolgbarkeit von Ausfällen nehmen Best Practices eine Aufzeichnung der aufgetretenen Fehler auf, sodass geeignete Aktionen ausgeführt werden können, wenn Fehler häufiger auftreten: Sie möchten keine Resilienz mehr aufbauen, um mehr Probleme zu verbergen. Sie können die in Fehler aus nicht erfolgreichen Schritten abrufen beschriebene Lösung verwenden.

Wenn Sie wissen, dass ein bestimmter Schritt in Ihren Prozessen auch Fehler anfällt (Beispiel: ein Remote-System, das regelmäßig offline geht, ohne einen bestimmten Zeitpunkt für den Ausfall festzulegen), können Sie die integrierte Oracle Data Integrator-Funktion nutzen, um einen Schritt in Ihren Packages zu wiederholen. Unter Automatisierte Wiederholungsversuche verwenden wird beschrieben, wie die automatische Wiederholung für einen Schritt festgelegt wird.

Bei der Verwendung dieser Lösung sollten Sie zwei Aspekte beachten:

Oracle Data Integrator benachrichtigt Sie nicht, dass der Prozess nicht erfolgreich war, wenn er auf "Wiederholen" gesetzt ist. Wenn einer der weiteren Versuche erfolgreich war, wird der Schritt in den Oracle Data Integrator-Logs als erfolgreich protokolliert (Sie können diese Versuche aber dennoch in Ihren eigenen Audittabellen verfolgen).
Erhöht und wartet die Dauer der Ausführung dieses Schrittes. Beachten Sie, dass Sie die Performance der Integrationsprozesse prüfen sollten.

Performanceabweichung identifizieren

Performance dehnt oft im Laufe der Zeit ab. Es ist wichtig, die Performance zu überwachen und zu gewährleisten, dass Sie für dasselbe Datenvolumen, das verarbeitet wird, noch die ursprüngliche Performance erhalten.Wenn mehr Daten verarbeitet werden sollen, ist dies sinnvoll. Wenn Sie mehr Zeit für die Verarbeitung derselben Datenmenge benötigen, kann es sich um ein Warnzeichen handeln.

Sie möchten wissen, wo die Verzögerungen sind und was zu diesen Verzögerungen führt. Dies kann sich auf eine erhöhte Netzwerkaktivität beziehen, die die verfügbare Bandbreite, veraltete Statistiken in Ihren Datenbanken reduziert, die sich negativ auf die Ausführung des SQL-Codes auswirken, oder auf eine Profuskation von Dateien auf einem Server, auf dem Sie nur einige ausgewählte Dateien interessieren.

In Oracle Data Integrator empfiehlt es sich, die Logs (und Szenarioberichte) so oft wie möglich zu löschen, um die Performance zu verbessern. Auf diese Weise ist es sehr nützlich, die Logs zu archivieren oder relevante Performance-Informationen zu kopieren, damit Sie die Performance im Laufe der Zeit überwachen können.

Während Sie die Leistungsabnahme untersuchen, prüfen Sie die einzelnen Schritte in Oracle Data Integrator (stoppen Sie nicht die Gesamtleistung): Dies ist die beste Methode, mit der Sie die Verzögerungen beginnen können. Stellen Sie außerdem sicher, dass Sie einen automatisierten Prozess zum Löschen der Oracle Data Integrator-Logs haben. Sie können einen Oracle Data Integrator-Job erstellen, der diese Befehle ausführt, einschließlich Szenarioberichten. Weitere Informationen finden Sie unter Logs mit OdiPurgeLog bereinigen.

Da Oracle Data Integrator nur zur Bereinigung von Szenarioberichten bereitstellt, die mit den Sessions im Operator verknüpft sind, müssen beim Löschen von Szenarioberichten, nachdem Sessions bereinigt wurden, Hilfe von Oracle Support angefordert werden. Wenn Sie die Szenarioberichte vor dem Löschen von Sessions vergessen haben, wenden Sie sich an den Oracle-Support. Oracle kann Sie durch die entsprechende Vorgehensweise führen.

Bei der langen Ausführung ist es entscheidend, die Performance kontinuierlich zu überwachen. Eine Performanceverringerung ist häufig ein Warnungszeichen einer Verringerung der Umgebung. Oracle empfiehlt insbesondere die Kontrolle von Ausführungsplänen mit SQL Plan Management (SPM). Änderungen des Ausführungsplans in der Produktion könnten zu Fehlern führen, und Tabellenladevorgänge können zu Änderungsrisiken bei Ausführungsplänen führen.

Logs mit OdiPurgeLog leeren

Wenn Sie das Slide-in-Menü Utilitys Ihrer Oracle Data Integrator-Packages anzeigen, sehen Sie ein Tool namens OdiPurgeLog. Sie können dieses Szenario in einem Szenario verwenden, das für das Leeren der Oracle Data Integrator-Logs entwickelt wurde, und dieses Szenario für eine regelmäßige Ausführung planen, um sicherzustellen, dass Sie so wenig Logs wie möglich beibehalten haben.

Best Practices umfassen:

Sie sollten die Berichte immer ebenfalls löschen. Es ist schwieriger, die Logs selbst zu entfernen, als sie beim Löschen der Logs sind.
Sie können eine gewisse Latenzebene beim Löschvorgang festlegen: Sie können Variablen verwenden, um eine vorherige oder ein früheres Datum zu speichern, vor dem alle Daten gelöscht werden sollen (sie würden mit dem Parameter End Date verwendet).
Sie können wahlweise Szenariologs (und Berichte) löschen oder sowohl Szenarios als auch Ladeplanlogs löschen.

Fehler aus nicht erfolgreichen Schritten abrufen

Die getPrevStepLog()-API wird im Allgemeinen in einer Oracle Data Integrator-Prozedur verwendet. Dies ist sehr praktisch, wenn ein Schritt nicht erfolgreich verläuft und Sie die in diesem Schritt gemeldeten Fehler abrufen möchten, bevor Sie versuchen, fehlerbehebende Maßnahmen vorzunehmen.

Diese API wird mit einem Eigenschaftsnamen aufgerufen, der die entsprechenden Informationen zurückgibt. Wenn Sie z. B. den Namen der Session, den Namen des fehlerhaften Schrittes und die zugehörige Fehlermeldung benötigen, könnten Sie den folgenden Code für das Abrufen des Fehlers für die Prozedur verwenden:

Session:
        <%=odiRef.getInfo("SESS_NAME")%> encountered the following
        error at step: <%=odiRef.getPrevStepLog("STEP_NAME")%>Error Message:
        <%odiRef.getPrevStepLog("MESSAGE")%>

Sie würden dieses Snippet in zusätzlichem Code umbrechen, der diese Informationen irgendwo speichert oder diese Informationen zur korrekten Verarbeitung sendet.

Automatisierte Wiederholungen verwenden

Automatische Wiederholungsversuche sparen, weil dem vollständigen Prozess die Möglichkeit gegeben wurde, wegen kurzer oder temporärer Flüsse abzuschließen und zu stornieren.

Wählen Sie in Ihrem Package den Schritt, für den Sie Wiederholungen zulassen möchten. Klicken Sie im Eigenschaftsfeld auf die Registerkarte "Erweitert". Im Bereich Verarbeitung nach Fehler:

Definieren Sie, wie oft Sie versuchen möchten, diesen Schritt zu wiederholen
Definieren Sie, wie lange zwischen jedem Wiederholungsversuch gewartet werden soll

Eindeutige oder dynamische Namen für Szenariosessions verwenden

Wenn dasselbe Szenario mehrmals ausgeführt wird, um verschiedene Datengruppen zu laden, ist die Oracle Data Integrator Operatoransicht nicht sehr hilfreich, wenn es sich um eine Liste mit vielen Instanzen desselben Szenarios handelt, die möglicherweise mit einem gelegentlichen Fehler ausgeführt werden.

Dies kann hilfreich sein, wenn Sie das Szenario aufrufen, indem Sie den Parameter Sessionname (SESS_NAME) nutzen. Wenn ein Szenario mehrmals ausgeführt wird, verfügen Sie wahrscheinlich bereits über einen Parameter, mit dem angegeben wird, welche Daten es verarbeiten soll (bestimmtes Datensegment, load_id, Datum usw.). Mit dieser Variablen können Sie einen eindeutigen Namen für jede Ausführung des Szenarios erstellen. Wenn der Sessionname im Aufruf des Szenarios festgelegt wird, führen zusätzliche Sessions eines Packages zu viel lesbaren Logs in dem Oracle Data Integrator-Operator. Dies erleichtert das Verständnis, welches Dataset problematisch ist, wenn ein Fehler auftritt.

Ereignisgesteuerte Tools verwenden

Oracle Data Integrator bietet eine Reihe von Tools, die in Ihren Packages verwendet werden können, um auf die Verfügbarkeit neuer Daten zu warten.

Mit diesen Tools können Sie die Polling-Rate sowie einen Timeoutzeitraum festlegen:

OdiFileWait wartet, bis die Datei in einem Verzeichnis verfügbar ist (beachten Sie, dass der Oracle Data Integrator-Agent dieses Verzeichnis sehen muss.)
OdiWaitForData wartet, bis neue Daten in einer Tabelle verfügbar sind, die auf einer von Ihnen angegebenen Abfrage basiert.
OdiWaitForTable wartet darauf, dass eine Tabelle in Ihrer Datenbank erstellt wird.

Agent-Blueprint-Cache-Timeout konfigurieren

Mit Oracle Data Integrator 12c wurde die Effizienz des Agent verbessert, indem die Definition der ausgeführten Szenarios im Cache gespeichert wird. Sie können kontrollieren, wie lange Szenarios in der Definition des physikalischen Agent in der Oracle Data Integrator-Topologie gecacht werden.

Das Caching des Szenarios im Agent ist für Echtzeitjobs nützlich, sodass der Agent die Informationen nicht für jede Ausführung im Repository abrufen muss. Das Zurückziehen ist, dass ein Deployment einer neuen Version eines Szenarios nicht sofort erfasst wird. Der Standardtimeout, bis eine neue Version eines gecachten Szenarios aufgenommen wird, beträgt 600 Sekunden (10 Minuten), und 100 Einträge werden standardmäßig gecacht.

Sie können diese Werte verwalten. Verwenden Sie in der Agent-Definition in der Registerkarte "Definition " den Abschnitt "Session-Blueprint-Cacheverwaltung ", um maximale Cacheeinträge und nicht verwendete Blueprint-Lebenszeit (Sek.) festzulegen.