Auftragssystemtabellenreferenz

Dieser Artikel ist eine Referenz für die lakeflow-Systemtabellen, die die Auftragsaktivitäten in Ihrem Konto erfassen. Diese Tabellen enthalten Datensätze aus allen Arbeitsbereichen in Ihrem Konto, die in derselben Cloudregion bereitgestellt wurden. Um Datensätze aus einer anderen Region anzuzeigen, müssen Sie die Tabellen aus einem Arbeitsbereich anzeigen, der in dieser Region bereitgestellt wird.

Requirements

• Um auf diese Systemtabellen zuzugreifen, müssen Benutzer eine der folgenden Aktionen ausführen:
  • Seien Sie sowohl ein Metastore-Administrator als auch ein Kontoadministrator, oder ...
  • Verfügen Sie über USE- und SELECT-Berechtigungen für die Systemschemata. Siehe Gewähren des Zugriffs auf Systemtabellen.

Verfügbare Auftragstabellen

Alle auftragsbezogenen Systemtabellen befinden sich im system.lakeflow Schema. Derzeit hostet das Schema vier Tabellen:

Detaillierte Schemareferenz

In den folgenden Abschnitten werden Schemaverweise für jede der auftragsbezogenen Systemtabellen bereitgestellt.

Auftragstabellenschema

Die jobs Tabelle ist eine langsam ändernde Dimensionstabelle (SCD2). Wenn eine Zeile geändert wird, wird eine neue Zeile ausgegeben, die logisch die vorherige Zeile ersetzt.

Tabellenpfad: system.lakeflow.jobs

Beispielabfrage

-- Get the most recent version of a job
SELECT
  *,
  ROW_NUMBER() OVER(PARTITION BY workspace_id, job_id ORDER BY change_time DESC) as rn
FROM
  system.lakeflow.jobs QUALIFY rn=1

Auftragsaufgabentabellenschema

Die Auftragsaufgabentabelle ist eine langsam ändernde Dimensionstabelle (SCD2). Wenn eine Zeile geändert wird, wird eine neue Zeile ausgegeben, die logisch die vorherige Zeile ersetzt.

Tabellenpfad: system.lakeflow.job_tasks

Beispielabfrage

-- Get the most recent version of a job task
SELECT
  *,
  ROW_NUMBER() OVER(PARTITION BY workspace_id, job_id ORDER BY change_time DESC) as rn
FROM
  system.lakeflow.job_tasks QUALIFY rn=1

Zeitachsentabellenschema für Auftragsausführung

Die Tabelle mit der Auftragsausführungszeitachse ist unveränderlich und zum Zeitpunkt der Produktion vollständig.

Tabellenpfad: system.lakeflow.job_run_timeline

Beispielabfrage

-- This query gets the daily job count for a workspace for the last 7 days:
SELECT
  workspace_id,
  COUNT(DISTINCT run_id) as job_count,
  to_date(period_start_time) as date
FROM system.lakeflow.job_run_timeline
WHERE
  period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
GROUP BY ALL

-- This query returns the daily job count for a workspace for the last 7 days, distributed by the outcome of the job run.
SELECT
  workspace_id,
  COUNT(DISTINCT run_id) as job_count,
  result_state,
  to_date(period_start_time) as date
FROM system.lakeflow.job_run_timeline
WHERE
  period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
  AND result_state IS NOT NULL
GROUP BY ALL

-- This query returns the average time of job runs, measured in seconds. The records are organized by job. A top 90 and a 95 percentile column show the average lengths of the job's longest runs.
with job_run_duration as (
    SELECT
        workspace_id,
        job_id,
        run_id,
        CAST(SUM(period_end_time - period_start_time) AS LONG) as duration
    FROM
        system.lakeflow.job_run_timeline
    WHERE
      period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
    GROUP BY ALL
)
SELECT
    t1.workspace_id,
    t1.job_id,
    COUNT(DISTINCT t1.run_id) as runs,
    MEAN(t1.duration) as mean_seconds,
    AVG(t1.duration) as avg_seconds,
    PERCENTILE(t1.duration, 0.9) as p90_seconds,
    PERCENTILE(t1.duration, 0.95) as p95_seconds
FROM
    job_run_duration t1
GROUP BY ALL
ORDER BY mean_seconds DESC
LIMIT 100

-- This query provides a historical runtime for a specific job based on the `run_name` parameter. For the query to work, you must set the `run_name`.
SELECT
  workspace_id,
  run_id,
  SUM(period_end_time - period_start_time) as run_time
FROM system.lakeflow.job_run_timeline
WHERE
  run_type="SUBMIT_RUN"
  AND run_name = :run_name
  AND period_start_time > CURRENT_TIMESTAMP() - INTERVAL 60 DAYS
GROUP BY ALL

-- This query collects a list of retried job runs with the number of retries for each run.
with repaired_runs as (
    SELECT
    workspace_id, job_id, run_id, COUNT(*) - 1 as retries_count
    FROM system.lakeflow.job_run_timeline
    WHERE result_state IS NOT NULL
    GROUP BY ALL
    HAVING retries_count > 0
    )
SELECT
    *
FROM repaired_runs
ORDER BY retries_count DESC
    LIMIT 10;

Auftragsaufgabe: Zeitachsentabellenschema ausführen

Die Tabelle mit der Aufgabenausführungszeitachse ist unveränderlich und zum Zeitpunkt der Produktion vollständig.

Tabellenpfad: system.lakeflow.job_task_run_timeline

Pipelines-Tabellenschema

Die Pipelinetabelle ist eine langsam veränderliche Dimensionstabelle (SCD2). Wenn eine Zeile geändert wird, wird eine neue Zeile ausgegeben, die logisch die vorherige Zeile ersetzt.

Tabellenpfad: system.lakeflow.pipelines

Beispielabfrage

-- Get the most recent version of a pipeline
SELECT
  *,
  ROW_NUMBER() OVER(PARTITION BY workspace_id, pipeline_id ORDER BY change_time DESC) as rn
FROM
  system.lakeflow.pipelines QUALIFY rn=1

-- Enrich billing logs with pipeline metadata
with latest_pipelines AS (
  SELECT
    *,
    ROW_NUMBER() OVER(PARTITION BY workspace_id, pipeline_id ORDER BY change_time DESC) as rn
  FROM
    system.lakeflow.pipelines QUALIFY rn=1
)
SELECT
  usage.*,
  pipelines.*
FROM system.billing.usage
LEFT JOIN latest_pipelines
  ON (usage.workspace_id = pipelines.workspace_id
    AND usage.usage_metadata.dlt_pipeline_id = pipelines.pipeline_id)
WHERE
  usage.usage_metadata.dlt_pipeline_id IS NOT NULL

Zeitachsentabellenschema für Pipelineupdates

Die Zeitachsentabelle der Pipelineaktualisierung ist unveränderlich und zum Zeitpunkt ihrer Erstellung vollständig.

Tabellenpfad: system.lakeflow.pipeline_update_timeline

Beispielabfrage

-- This query gets the daily pipeline update count for a workspace for the last 7 days:
SELECT
    workspace_id,
    COUNT(DISTINCT update_id) as update_count,
    to_date(period_start_time) as date
FROM system.lakeflow.pipeline_update_timeline
WHERE
    period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
GROUP BY ALL

-- This query returns the daily pipeline update count for a workspace for the last 7 days, distributed by the outcome of the pipeline update.
SELECT
    workspace_id,
    COUNT(DISTINCT update_id) as update_count,
    result_state,
    to_date(period_start_time) as date
FROM system.lakeflow.pipeline_update_timeline
WHERE
    period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
  AND result_state IS NOT NULL
GROUP BY ALL

-- This query returns the average time of pipeline updates, measured in seconds. The records are organized by pipeline. A top 90 and a 95 percentile column show the average lengths of the pipeline's longest updates.
with pipeline_update_duration as (
    SELECT
      workspace_id,
      pipeline_id,
      update_id,
      CAST(SUM(period_end_time - period_start_time) AS LONG) as duration
    FROM
        system.lakeflow.pipeline_update_timeline
    WHERE
        period_start_time > CURRENT_TIMESTAMP() - INTERVAL 7 DAYS
    GROUP BY ALL
)
SELECT
    t1.workspace_id,
    t1.pipeline_id,
    COUNT(DISTINCT t1.update_id) as update_count,
    MEAN(t1.duration) as mean_seconds,
    AVG(t1.duration) as avg_seconds,
    PERCENTILE(t1.duration, 0.9) as p90_seconds,
    PERCENTILE(t1.duration, 0.95) as p95_seconds
FROM
    pipeline_update_duration t1
GROUP BY ALL
ORDER BY mean_seconds DESC
    LIMIT 100

Allgemeine Verknüpfungsmuster

In den folgenden Abschnitten werden Beispielabfragen bereitgestellt, die häufig verwendete Verknüpfungsmuster für Auftragssystemtabellen hervorheben.

Verknüpfen von Aufträgen und Zeitachsentabellen für Auftragsausführung

Anreichern einer Auftragsausführung mit einem Auftragsnamen

with jobs as (
    SELECT
        *,
        ROW_NUMBER() OVER (PARTITION BY workspace_id, job_id ORDER BY change_time DESC) as rn
    FROM system.lakeflow.jobs QUALIFY rn=1
)
SELECT
    job_run_timeline.*
    jobs.name
FROM system.lakeflow.job_run_timeline
    LEFT JOIN jobs USING (workspace_id, job_id)

Verknüpfen der Auftragsausführungszeitachsen- und Verbrauchstabellen

Anreichern jedes Abrechnungsprotokolls mit Auftragsausführungsmetadaten

Die folgende Abfrage erweitert Abrechnungsprotokolle mit Auftragsausführungsmetadaten aus klassischen und serverlosen Aufträgen:

with aggregated_job_runs AS (
  SELECT
    j.workspace_id,
    COALESCE(t.job_id, j.job_id) as origin_job_id,
    COALESCE(t.job_run_id, j.run_id) AS origin_job_run_id,
    j.job_id as billing_job_id,
    j.run_id as billing_run_id,
    CASE WHEN j.root_task_run_id IS NOT NULL THEN true ELSE false END AS is_workflow_run
  FROM
    system.lakeflow.job_run_timeline j
  LEFT JOIN
    system.lakeflow.job_task_run_timeline t
  ON
    j.workspace_id = t.workspace_id
    AND j.root_task_run_id = t.run_id
  WHERE j.period_start_time >= CURRENT_DATE() - INTERVAL 7 DAYS
  GROUP BY ALL
),
billing_logs_enriched AS (
  SELECT
      t2.origin_job_id,
      t2.origin_job_run_id,
      t1.*
  FROM system.billing.usage t1
      INNER JOIN aggregated_job_runs t2
          ON t1.workspace_id = t2.workspace_id
              AND t1.usage_metadata.job_id = t2.billing_job_id
              AND t1.usage_metadata.job_run_id = t2.billing_run_id
  WHERE
      billing_origin_product="JOBS" AND usage_date >= CURRENT_DATE() - INTERVAL 7 DAYS
)
SELECT
  workspace_id,
  origin_job_id AS job_id,
  origin_job_run_id AS run_id,
  sku_name,
  SUM(usage_quantity) as total_usage_quantity,
  SUM(CASE WHEN usage_metadata.job_run_id != origin_job_run_id THEN usage_quantity ELSE 0 END) AS workflow_run_usage_quantity,
  COUNT(DISTINCT usage_metadata.job_run_id) - 1 AS workflow_runs
FROM billing_logs_enriched
GROUP BY ALL

Berechnen der Kosten pro Auftragsausführung

Diese Abfrage wird mit der billing.usage Systemtabelle verknüpft, um die Kosten pro Auftragsausführung zu berechnen.

with jobs_usage AS (
  SELECT
    *,
    usage_metadata.job_id,
    usage_metadata.job_run_id as run_id,
    identity_metadata.run_as as run_as
  FROM system.billing.usage
  WHERE billing_origin_product="JOBS"
),
jobs_usage_with_usd AS (
  SELECT
    jobs_usage.*,
    usage_quantity * pricing.default as usage_usd
  FROM jobs_usage
    LEFT JOIN system.billing.list_prices pricing ON
      jobs_usage.sku_name = pricing.sku_name
      AND pricing.price_start_time <= jobs_usage.usage_start_time
      AND (pricing.price_end_time >= jobs_usage.usage_start_time OR pricing.price_end_time IS NULL)
      AND pricing.currency_code="USD"
),
jobs_usage_aggregated AS (
  SELECT
    workspace_id,
    job_id,
    run_id,
    FIRST(run_as, TRUE) as run_as,
    sku_name,
    SUM(usage_usd) as usage_usd,
    SUM(usage_quantity) as usage_quantity
  FROM jobs_usage_with_usd
  GROUP BY ALL
)
SELECT
  t1.*,
  MIN(period_start_time) as run_start_time,
  MAX(period_end_time) as run_end_time,
  FIRST(result_state, TRUE) as result_state
FROM jobs_usage_aggregated t1
  LEFT JOIN system.lakeflow.job_run_timeline t2 USING (workspace_id, job_id, run_id)
GROUP BY ALL
ORDER BY usage_usd DESC
LIMIT 100

Abrufen von Verbrauchsprotokollen für SUBMIT_RUN-Aufträge

SELECT
  *
FROM system.billing.usage
WHERE
  EXISTS (
      SELECT 1
      FROM system.lakeflow.job_run_timeline
      WHERE
        job_run_timeline.job_id = usage_metadata.job_id
        AND run_name = :run_name
        AND workspace_id = :workspace_id
  )

Verknüpfen von der Zeitachse der Auftragsaufgabenausführung und Clustertabellen

Aufgabenläufe mit Clustermetadaten anreichern

with clusters as (
    SELECT
        *,
        ROW_NUMBER() OVER (PARTITION BY workspace_id, cluster_id ORDER BY change_time DESC) as rn
    FROM system.compute.clusters QUALIFY rn=1
),
exploded_task_runs AS (
  SELECT
    *,
    EXPLODE(compute_ids) as cluster_id
  FROM system.lakeflow.job_task_run_timeline
  WHERE array_size(compute_ids) > 0
)
SELECT
  *
FROM exploded_task_runs t1
  LEFT JOIN clusters t2
    USING (workspace_id, cluster_id)

Suchen von Aufträgen, die auf All-Purpose Compute ausgeführt werden

Diese Abfrage wird mit der compute.clusters Systemtabelle verknüpft, um zuletzt ausgeführte Aufträge zurückzugeben, die auf All-Purpose Compute ausgeführt werden, anstatt auf Jobs Compute.

with clusters AS (
  SELECT
    *,
    ROW_NUMBER() OVER(PARTITION BY workspace_id, cluster_id ORDER BY change_time DESC) as rn
  FROM system.compute.clusters
  WHERE cluster_source="UI" OR cluster_source="API"
  QUALIFY rn=1
),
job_tasks_exploded AS (
  SELECT
    workspace_id,
    job_id,
    EXPLODE(compute_ids) as cluster_id
  FROM system.lakeflow.job_task_run_timeline
  WHERE period_start_time >= CURRENT_DATE() - INTERVAL 30 DAY
  GROUP BY ALL
),
all_purpose_cluster_jobs AS (
  SELECT
    t1.*,
    t2.cluster_name,
    t2.owned_by,
    t2.dbr_version
  FROM job_tasks_exploded t1
    INNER JOIN clusters t2 USING (workspace_id, cluster_id)
)
SELECT * FROM all_purpose_cluster_jobs LIMIT 10;

Suchen nach Aufträgen, die in den letzten 30 Tagen nicht ausgeführt werden

Diese Abfrage verknüpft die lakeflow.jobs Tabellen und lakeflow.job_run_timeline Systemtabellen, um Aufträge zurückzugeben, die in den letzten 30 Tagen nicht ausgeführt werden.

with latest_jobs AS (
    SELECT
        *,
        ROW_NUMBER() OVER (PARTITION BY workspace_id, job_id ORDER BY change_time DESC) as rn
    FROM system.lakeflow.jobs QUALIFY rn=1
),
latest_not_deleted_jobs AS (
    SELECT
        workspace_id,
        job_id,
        name,
        change_time,
        tags
    FROM latest_jobs WHERE delete_time IS NULL
),
last_seen_job_timestamp AS (
    SELECT
        workspace_id,
        job_id,
        MAX(period_start_time) as last_executed_at
    FROM system.lakeflow.job_run_timeline
    WHERE
        run_type="JOB_RUN"
    GROUP BY ALL
)
SELECT
    t1.workspace_id,
    t1.job_id,
    t1.name,
    t1.change_time as last_modified_at,
    t2.last_executed_at,
    t1.tags
FROM latest_not_deleted_jobs t1
    LEFT JOIN last_seen_job_timestamp t2
        USING (workspace_id, job_id)
WHERE
    (t2.last_executed_at <= CURRENT_DATE() - INTERVAL 30 DAYS) OR (t2.last_executed_at IS NULL)
ORDER BY last_executed_at ASC

Auftragsüberwachungs-Dashboard

Das folgende Dashboard verwendet Systemtabellen, um Ihnen bei den ersten Schritten bei der Überwachung Ihrer Aufträge und des Betriebszustands zu helfen. Sie umfasst häufige Anwendungsfälle wie Auftragsleistungsnachverfolgung, Fehlerüberwachung und Ressourcenauslastung.

Informationen zum Herunterladen des Dashboards finden Sie unter Überwachen von Auftragskosten und -leistung mit Systemtabellen

Troubleshooting

Auftrag wird nicht in der Tabelle lakeflow.jobs protokolliert

Wenn ein Auftrag in den Systemtabellen nicht sichtbar ist:

• Der Auftrag wurde in den letzten 365 Tagen nicht geändert.
  • Ändern Sie alle Felder des Auftrags, die im Schema vorhanden sind, um einen neuen Datensatz auszugeben.
• Der Job wurde in einer anderen Region erstellt.
• Neuere Auftragserstellung (Tabellenabstand)

Kann den in der job_run_timeline Tabelle angezeigten Job nicht finden.

Nicht alle Auftragsausführungen sind überall sichtbar. Während JOB_RUN-Einträge in allen auftragsbezogenen Tabellen erscheinen, werden WORKFLOW_RUN (Notizbuch-Workflow-Ausführungen) nur in job_run_timeline aufgezeichnet. SUBMIT_RUN (einmalige Übermittlungen) werden hingegen sowohl in der einen als auch in der anderen Zeitleistentabelle aufgezeichnet. Diese Ausführungen werden nicht in andere Auftragssystemtabellen wie jobs oder job_tasks eingetragen.

Eine detaillierte Übersicht darüber, wo jeder Ausführungstyp sichtbar und zugänglich ist, finden Sie in der nachstehenden Tabelle " Run types" weiter unten.

Auftragsausführung ist in der Tabelle billing.usage nicht sichtbar

In system.billing.usage wird usage_metadata.job_id nur für Aufträge aufgefüllt, die auf Aufragscompute oder serverlosem Computing ausgeführt werden.

Darüber hinaus haben WORKFLOW_RUN Arbeitsplätze in usage_metadata.job_idkeine eigene usage_metadata.job_run_id- oder system.billing.usage-Zuordnung. Stattdessen wird der Computeverbrauch dem übergeordneten Notebook, das sie ausgelöst hat, zugeordnet. Dies bedeutet, dass beim Start einer Workflowausführung durch ein Notebook sämtliche Computekosten unter der Nutzung des übergeordneten Notebooks und nicht als separater Workflowauftrag angezeigt werden.

Weitere Informationen finden Sie in der -Verwendungsmetadatenreferenz.

Berechnen der Kosten eines Auftrags, der auf All-Purpose Compute ausgeführt wird

Präzise Kostenberechnungen für Aufträge, die auf All-Purpose Compute ausgeführt werden, sind mit einer Genauigkeit von 100 % nicht möglich. Wenn ein Auftrag auf einem interaktiven (allgemeinen) Rechner ausgeführt wird, werden mehrere Workloads wie Notizbücher, SQL-Abfragen oder andere Aufträge häufig gleichzeitig auf derselben Rechnerressource ausgeführt. Da die Clusterressourcen gemeinsam genutzt werden, gibt es keine direkte 1:1-Zuordnung zwischen Rechenkosten und einzelnen Auftragsläufen.

Für die genaue Nachverfolgung von Auftragskosten empfiehlt Databricks das Ausführen von Aufträgen auf dediziertem Job-Computes oder serverlosem Computing, wobei usage_metadata.job_id und usage_metadata.job_run_id eine genaue Kostenzuweisung ermöglichen.

Wenn Sie All-Purpose Compute verwenden müssen, haben Sie folgende Möglichkeiten:

• Überwachen Sie Verbrauch und Kosten des gesamten Clusters in system.billing.usage basierend auf usage_metadata.cluster_id.
• Separat die Laufzeitmetriken von Aufträgen verfolgen.
• Berücksichtigen Sie, dass jede Kostenschätzung aufgrund gemeinsam genutzter Ressourcen ungefähr ist.

Weitere Informationen zur Kostenzuordnung finden Sie unter Referenz zu Nutzungsmetadaten.

Referenzwerte

Der folgende Abschnitt enthält Verweise auf ausgewählte Spalten in auftragsbezogenen Tabellen.

Aufteilungslogik in den Zeitachsentabellen

Die Spalten period_start_time und period_end_time in den Tabellen job_run_timeline und job_task_run_timeline zeichnen den aktiven Zeitraum einer Auftragsausführung oder einer Aufgabenausführung auf.

Jede Zeile zeichnet bis zu einer Stunde Laufzeit auf. Läufe, die länger als 1 Stunde dauern, werden über mehrere Zeilen aufgezeichnet. Diese Aufteilung sorgt für stündliche Granularität bei der Überwachung langfristig ausgeführter Aufgaben.

Kurzlaufaufträge

Für Ausführungen, die kürzer als 1 Stunde sind, wird eine einzelne Zeile ausgegeben, wobei period_start_time sie auf die Startzeit der Ausführung festgelegt ist und period_end_time auf die Endzeit der Ausführung festgelegt ist.

Beispielsweise wird ein Auftrag, der um 12:13 Uhr UTC gestartet und um 12:45 Uhr UTC endet, durch eine einzelne Zeile dargestellt:

Lange ausgeführte Aufträge

Bei Läufen, die länger als 1 Stunde dauern, werden mehrere Zeilen mit demselben run_idausgegeben, die jeweils bis zu einer Stunde der Laufzeit darstellen:

• Die erste Zeile beginnt mit der tatsächlichen Startzeit und endet am Ende der ersten Laufstunde.
• Zwischenreihen (falls vorhanden) umfassen vollständige stündliche Fenster, die an der vorherigen Slice period_end_time ausgerichtet sind.
• Die letzte Zeile beginnt am Anfang des vorherigen Datenschnitts und endet mit der tatsächlichen Endzeit der Ausführung.

Beispielsweise wird ein Auftrag, der von 4:47 PM UTC bis 18:28 UHR UTC ausgeführt wurde, in mehrere Zeilen unterteilt. Jede Zeile stellt eine Stunde Aktivität dar, mit Ausnahme der letzten Zeile, die kürzer sein kann:

Triggertypwerte

In der job_run_timeline Tabelle sind die möglichen Werte für die trigger_type Spalte:

• CONTINUOUS
• CRON
• FILE_ARRIVAL
• ONETIME
• ONETIME_RETRY

Ausführungstypwerte

In der job_run_timeline Tabelle sind die möglichen Werte für die run_type Spalte:

Ergebniszustandswerte

In den job_task_run_timeline Und job_run_timeline Tabellen sind die möglichen Werte für die result_state Spalte:

Beendigungscodewerte

In den job_task_run_timeline Und job_run_timeline Tabellen sind die möglichen Werte für die termination_code Spalte:

Pipelinetypwerte

In der pipelines Tabelle sind die möglichen Werte für die pipeline_type Spalte:

Referenz für Pipelineergebnisse

In der pipeline_update_timeline Tabelle sind die möglichen Werte für die result_state Spalte:

• COMPLETED
• FAILED
• CANCELED

Referenz zu Pipelineeinstellungen

In der pipelines Tabelle sind die möglichen Werte für die settings Spalte:

Pipeline-Update-Typwerte

In der pipeline_update_timeline Tabelle sind die möglichen Werte für die update_type Spalte:

• API_CALL
• RETRY_ON_FAILURE
• SERVICE_UPGRADE
• SCHEMA_CHANGE
• JOB_TASK
• USER_ACTION
• DBSQL_REQUEST
• SETTINGS_CHANGE
• SCHEMA_EXPLORATION
• INFRASTRUCTURE_MAINTENANCE
• START_RESOURCES

Typwerte für Pipelinetrigger

In der pipeline_update_timeline Tabelle sind die möglichen Werte für die trigger_type Spalte:

Details des Pipeline-Trigger-Typs

In der pipeline_update_timeline Tabelle sind die möglichen Werte für die trigger_type.job_task Struktur: