Problembehandlung von Aufgaben¶

In diesem Abschnitt wird ein methodischer Ansatz zur Problembehandlung bei Aufgaben beschrieben, die nicht wie erwartet ausgeführt werden.

Unter diesem Thema:

Task wurde nicht ausgeführt¶

Schritt 1: Überprüfen, ob Aufgabe ausgeführt wurde¶

Fragen Sie die Tabellenfunktion TASK_HISTORY ab, um zu überprüfen, ob die Aufgabe ausgeführt wurde oder nicht. Möglicherweise wurde die Aufgabe erfolgreich ausgeführt, aber die SQL-Anweisung in der Aufgabendefinition ist fehlgeschlagen. Notieren Sie sich insbesondere die Planungs- und die Beendigungszeiten sowie alle Fehlercodes und Meldungen.

Wenn die Aufgabe eine Vorgängeraufgabe hat (in einem Task-Graphen), überprüfen Sie, ob die Vorgängeraufgabe erfolgreich abgeschlossen wurde.

Schritt 2: Überprüfen, ob Aufgabe fortgesetzt wurde¶

Überprüfen Sie, ob der Status der Aufgabe (oder jeder Aufgabe im Task-Graph) den Status RESUMED hat (mit DESCRIBE TASK oder SHOW TASKS).

Um eine einzelne Aufgabe fortzusetzen, führen Sie ALTER TASK … RESUME aus. Um alle abhängigen Aufgaben, die an eine Stammaufgabe gebunden sind, rekursiv zu aktivieren, fragen Sie die Funktion SYSTEM$TASK_DEPENDENTS_ENABLE ab, anstatt jede Aufgabe einzeln zu aktivieren.

Überprüfen Sie auch den Cron-Ausdruck, wenn für die Aufgabe ein Zeitplan vorhanden ist. Stellen Sie sicher, dass von den geplanten Zeiten mindestens eine verstrichen ist.

Schritt 3: Berechtigungen des Aufgabeneigentümers überprüfen¶

Überprüfen Sie, ob der Aufgabeneigentümer (d. h. die Rolle mit der Berechtigung OWNERSHIP für die Aufgabe) über die folgenden Berechtigungen verfügt, die für die Ausführung der Aufgabe erforderlich sind:

Objekt	Berechtigung	Anmerkungen
Konto	EXECUTE TASK	Erforderlich, um jegliche Aufgaben auszuführen, die der Rolle gehören. Durch das Widerrufen der Berechtigung EXECUTE TASK für eine Rolle wird verhindert, dass alle nachfolgenden Aufgaben unter dieser Rolle gestartet werden.
Datenbank	USAGE
Schema	USAGE
Aufgabe	OWNERSHIP
Warehouse	USAGE

Überprüfen Sie mit SHOW GRANTS TO ROLE role_name die der Rolle erteilten Berechtigungen.

Schritt 4: Zustand überprüfen¶

Wenn die Aufgabe eine WHEN-Klausel mit einer SYSTEM$STREAM_HAS_DATA-Bedingung enthält, stellen Sie sicher, dass bei der letzten geplante Ausführung der Aufgabe der angegebene Stream Datensätze zur Änderungsdatenerfassung (CDC) enthielt. Historische Daten für einen Stream können mithilfe einer AT | BEFORE-Klausel abgefragt werden.

Zeitüberschreitung oder Überschreitung des Zeitplanfensters der Aufgabe¶

Derzeit gibt es eine Beschränkung von 60 Minuten für eine einzelne Ausführung einer Aufgabe. Diese Beschränkung wurde als Schutz gegen nicht abschließende Aufgaben implementiert. Fragen Sie die Tabellenfunktion TASK_HISTORY ab. Wenn die Aufgabe abgebrochen wurde oder das für die Aufgabe geplante Zeitfenster überschritten wurde, ist die Ursache häufig ein Warehouse mit zu geringer Größe. Überprüfen Sie die Warehousegröße, und erhöhen Sie diese, damit das Zeitplanfenster oder das Ein-Stunden-Limit eingehalten wird.

Alternativ können Sie den Timeoutwert für die Aufgabe erhöhen, indem Sie ALTER TASK … SET USER_TASK_TIMEOUT_MS = <Zahl> ausführen. Um festzustellen, ob der Parameter USER_TASK_TIMEOUT_MS für eine bestimmte Aufgabe festgelegt wurde, führen Sie die folgende Anweisung aus:

SHOW PARAMETERS LIKE 'USER_TASK_TIMEOUT_MS' IN TASK <task_name>;

Copy

Dabei ist <Aufgabenname> der Name der Aufgabe, deren Timeoutwert angepasst werden soll. Wenn die Anweisung keinen Datensatz zurückgibt, hat die Aufgabe derzeit den Standard-Timeoutwert von 3600000 Millisekunden (60 Minuten).

Beachten Sie, dass Probleme mit der Parallelisierung von Abfragen möglicherweise weder durch die Vergrößerung des Warehouses noch durch die Erhöhung des Timeoutwerts gelöst werden. Überlegen Sie, wie Sie die von der Aufgabe ausgeführte SQL-Anweisung anders formulieren können.