Elastische Jobs in der Azure SQL-Datenbank

Gilt für:: Azure SQL-Datenbank

In diesem Artikel werden die Möglichkeiten und Details von elastischer Aufträgen für Azure SQL Database erläutert.

• Ein Tutorial zur Konfiguration von elastischen Aufträgen finden Sie im Tutorial zu elastischen Aufträgen.
• Erfahren Sie mehr über Automatisierungskonzepte in Azure-Datenbankplattformen.

Elastische Aufträge – Übersicht

Sie können elastische Aufträge erstellen und planen, die in regelmäßigen Abständen für einzelne oder mehrere Azure SQL-Datenbanken ausgeführt werden können, um T-SQL-Abfragen (Transact-SQL) und Wartungsaufgaben zu ermöglichen.

Sie können eine Zieldatenbank oder Gruppen von Datenbanken sowie Zeitpläne für die Auftragsausführung definieren. Alle Datums- und Zeitangaben in den elastischen Aufträgen sind in der UTC-Zeitzone.

Ein Auftrag übernimmt die Aufgabe der Anmeldung bei der Zieldatenbank. Zudem können Sie Transact-SQL-Skripts zur Ausführung für eine Gruppe von Datenbanken definieren, verwalten und speichern.

Jeder Auftrag protokolliert den Ausführungsstatus und wiederholt die Vorgänge im Falle eines Fehlers automatisch.

Empfohlene Verwendung für elastische Aufträge

Die Automatisierung mit elastischen Aufträgen kann in verschiedenen Szenarien hilfreich sein:

• Automatisierung von Verwaltungsaufgaben und Planung der Ausführung beispielsweise an jedem Werktag oder nach Geschäftsschluss usw.
  • Bereitstellung von Schemaänderungen, Anmeldeinformationsverwaltung.
  • Sammlung von Leistungsdaten oder Telemetrieerfassung des Mandanten (Kunden).
  • Aktualisierung von Referenzdaten (Informationen für alle Datenbanken).
  • Laden Sie Daten aus dem Azure Blob Storage.
• Konfiguration von Aufträgen, sodass diese für eine gesamte Sammlung von Datenbanken auf wiederkehrender Basis ausgeführt werden (etwa in Zeiten mit geringer Auslastung).
  • Sammlung von Abfrageergebnissen aus einer Menge von Datenbanken in einer zentralen Tabelle auf fortlaufender Grundlage.
  • Abfragen können fortlaufend ausgeführt werden und für die Auslösung der Ausführung weiterer Aufgaben konfiguriert werden.
• Sammeln von Berichtsdaten
  • Aggregation von Daten aus einer Sammlung von Datenbanken in einer einzelnen Zieltabelle.
  • Ausführung von Abfragen zur Datenverarbeitung mit längerer Laufzeit für eine große Anzahl von Datenbanken, z.B. bei der Sammlung von Kundentelemetrie. Die Ergebnisse werden zur weiteren Analyse in einer einzelnen Zieltabelle gesammelt.
• Datenverschiebung
  • Für individuell entwickelte Lösungen, Geschäftsautomatisierung oder andere Aufgabenverwaltung.
  • ETL-Verarbeitung zur Extraktion/Verarbeitung/Einfügung von Daten zwischen Tabellen in einer Datenbank.

Erwägen Sie elastische Aufträge, wenn Sie:

• eine Aufgabe haben, die regelmäßig nach einem Zeitplan ausgeführt werden muss und sich auf eine oder mehrere Datenbanken bezieht.
• eine Aufgabe haben, die einmal ausgeführt werden muss, aber für mehrere Datenbanken.
• Aufträge für eine beliebige Kombination von Datenbanken ausführen müssen: für einzelne oder mehrere individuelle Datenbanken, für alle Datenbanken auf einem Server, für alle Datenbanken in einem Pool für elastische Datenbanken, und zusätzlich mit der Flexibilität, spezifische Datenbanken ein- oder ausschließen zu können. Aufträge können für mehrere Server, für mehrere Pools und sogar für Datenbanken aus anderen Abonnements ausgeführt werden. Server und Pools werden zur Laufzeit dynamisch aufgezählt, sodass Aufträge für alle Datenbanken ausgeführt werden, die zum Zeitpunkt der Ausführung in der Zielgruppe vorhanden sind.
  • Dies ist ein wesentlicher Unterschied zum SQL Agent, der die Zieldatenbanken nicht dynamisch aufzählen kann, insbesondere in SaaS-Kundenszenarien, in denen Datenbanken dynamisch hinzugefügt/gelöscht werden.

Komponenten elastischer Aufträge

Agent für elastische Aufträge

Bei einem Agent für elastische Aufträge handelt es sich um die Azure-Ressource zum Erstellen, Ausführen und Verwalten von Aufträgen. Der Agent für elastische Aufträge ist eine Azure-Ressource, die über das Portal erstellt wird (Erstellen und Verwalten von elastischen Aufträgen mithilfe von PowerShell und REST API werden ebenfalls unterstützt).

Zum Erstellen eines Agents für elastische Aufträge muss eine Datenbank in Azure SQL­-Datenbank vorhanden sein. Der Agent konfiguriert die vorhandene Azure SQL-Datenbank-Instanz als Auftragsdatenbank.

Sie können einen Auftrag über das Azure-Portal starten, deaktivieren oder abbrechen. Über das Azure-Portal können Sie auch Auftragsdefinitionen und den Ausführungsverlauf einsehen.

Kosten des Agenten für elastische Aufträge

Die Auftragsdatenbank wird zum gleichen Tarif abgerechnet wie eine Datenbank in Azure SQL-Datenbank. Für die Kosten des Elastic Job Agents basiert es auf festen Preisen der Serviceebene, die für den Job Agent ausgewählt wurde. Siehe Azure SQL-Datenbank Preisseite.

Datenbank für elastische Aufträge

Die Auftragsdatenbank dient zum Definieren von Aufträgen sowie zum Nachverfolgen des Status und Verlaufs von Auftragsausführungen. Aufträge werden in Zieldatenbanken ausgeführt. Darüber hinaus wird die Auftragsdatenbank auch zum Speichern von Agent-Metadaten, Protokollen, Ergebnissen und Auftragsdefinitionen verwendet und enthält außerdem zahlreiche praktische gespeicherte Prozeduren sowie andere Datenbankobjekte zum Erstellen, Ausführen und Verwalten von Aufträgen mit T-SQL.

Eine Azure SQL-Datenbank (S1 oder höher) wird empfohlen, um einen Agent für elastische Aufträge zu erstellen.

Bei der Auftragsdatenbank sollte es sich um eine bereinigte, leere Azure SQL-Datenbank-Instanz mit dem Dienstziel S1 oder höher handeln.

Für die Auftragsdatenbank wird das Dienstziel S1 oder höher empfohlen, die optimale Wahl hängt jedoch von den Leistungsanforderungen Ihrer Aufträge ab (also von der Anzahl von Auftragsschritten, der Anzahl von Auftragszielen und der Ausführungshäufigkeit der Aufträge).

Sollten Vorgänge für die Auftragsdatenbank unerwartet langsam sein, überwachen Sie die Datenbankleistung und die Ressourcenverwendung der Auftragsdatenbank in langsamen Phasen über das Azure-Portal oder mithilfe der dynamische Verwaltungssicht sys.dm_db_resource_stats. Wenn eine Ressource (etwa CPU, Daten-E/A oder Protokollschreibvorgänge) in langsamen Phasen nahezu vollständig ausgelastet ist, empfiehlt es sich gegebenenfalls, die Datenbank schrittweise auf höhere Dienstziele zu skalieren (entweder in DTU-basiertes Kaufmodell oder im V-Kern-Kaufmodell), bis sich die Leistung der Auftragsdatenbank ausreichend verbessert hat.

Elastische Aufträge und Auftragsschritte

Ein Auftrag ist eine Arbeitseinheit, die gemäß einem Zeitplan oder als einmaliger Auftrag ausgeführt wird. Ein Auftrag enthält mindestens einen Auftragsschritt.

Jeder Auftragsschritt gibt ein auszuführendes T-SQL-Skript, mindestens eine Zielgruppe für die T-SQL-Skriptausführung sowie die Anmeldeinformationen an, die der Auftrags-Agent für die Verbindungsherstellung mit der Zieldatenbank benötigt. Jeder Auftragsschritt verfügt über anpassbare Timeout- und Wiederholungsrichtlinien und kann optional mit Ausgabeparametern versehen werden.

Ziele für elastische Aufträge

Mit elastischen Aufträgen können Sie einzelne oder mehrere T-SQL-Skripts parallel für eine große Anzahl von Datenbanken ausführen – entweder gemäß einem Zeitplan oder nach Bedarf. Das Ziel kann eine beliebige Ebene Azure SQL-Datenbank sein.

Sie können Aufträge für eine beliebige Kombination von Datenbanken ausführen: für einzelne oder mehrere individuelle Datenbanken, für alle Datenbanken auf einem Server, für alle Datenbanken in einem Pool für elastische Datenbanken, und zusätzlich mit der Flexibilität, spezifische Datenbanken ein- oder ausschließen zu können. Aufträge können für mehrere Server, für mehrere Pools und sogar für Datenbanken aus anderen Abonnements ausgeführt werden. Server und Pools werden zur Laufzeit dynamisch aufgezählt, sodass Aufträge für alle Datenbanken ausgeführt werden, die zum Zeitpunkt der Ausführung in der Zielgruppe vorhanden sind.

Die folgende Abbildung zeigt einen Auftrags-Agent, der Aufträge für die verschiedenen Arten von Zielgruppen ausführt:

Zielgruppe

Eine Zielgruppe definiert die Gruppe von Datenbanken, für die ein Auftragsschritt ausgeführt wird. Eine Zielgruppe kann eine beliebige Anzahl und Kombination der folgenden Optionen enthalten:

• Logischer SQL-Server: Bei Angabe eines Servers werden alle Datenbanken, die sich zum Zeitpunkt der Auftragsausführung auf dem Server befinden, in die Gruppe einbezogen. Damit die Gruppe vor der Auftragsausführung enumeriert und aktualisiert werden kann, müssen Anmeldeinformationen für die master-Datenbank angegeben werden. Weitere Informationen zu logischen Servern finden Sie unter Was ist ein logischer SQL-Server in Azure SQL-Datenbank und Azure Synapse?
• Pool für elastische Datenbanken: Bei Angabe eines Pools für elastische Datenbanken werden alle Datenbanken, die sich zum Zeitpunkt der Auftragsausführung in dem Pool für elastische Datenbanken befinden, in die Gruppe einbezogen. Genau wie bei einem Server müssen Anmeldeinformationen für die master-Datenbank angegeben werden, damit die Gruppe vor der Auftragsausführung aktualisiert werden kann.
• Einzelne Datenbank: Geben Sie eine oder mehrere einzelne Datenbanken an, die in die Gruppe einbezogen werden sollen.

Pools und einzelne Datenbanken können in die Gruppe eingeschlossen oder aus der Gruppe ausgeschlossen werden. Dadurch können Sie eine Zielgruppe mit einer beliebigen Kombination von Datenbanken erstellen. So können Sie beispielsweise einer Zielgruppe einen Server hinzufügen, aber bestimmte Datenbanken aus einem Pool für elastische Datenbanken (oder den gesamten Pool) ausschließen.

Eine Zielgruppe kann Datenbanken aus mehreren Abonnements und aus mehreren Regionen enthalten. Im Vergleich zu Ausführungen in der gleichen Region ist bei regionsübergreifenden Ausführungen mit höheren Wartezeiten zu rechnen.

Die folgenden Beispiele zeigen, wie verschiedene Zielgruppendefinitionen zum Zeitpunkt der Auftragsausführung dynamisch aufgelistet werden, um zu bestimmen, welche Datenbanken vom Auftrag ausgeführt werden:

• Beispiel 1 zeigt eine Zielgruppe, die aus einer Liste einzelner Datenbanken besteht. Wenn ein Auftragsschritt mithilfe dieser Zielgruppe ausgeführt wird, wird die Aktion des Auftragsschritts in jeder dieser Datenbanken ausgeführt.
• Beispiel 2 zeigt eine Zielgruppe, die einen Server als Ziel enthält. Wenn ein Auftragsschritt mit dieser Zielgruppe ausgeführt wird, wird der Server dynamisch aufgezählt, um die Liste der Datenbanken zu bestimmen, die sich aktuell auf dem Server befinden. Die Aktion des Auftragsschritts wird in jeder dieser Datenbanken ausgeführt.
• Beispiel 3 zeigt eine ähnliche Zielgruppe wie Beispiel 2, eine einzelne Datenbank wird jedoch ausdrücklich ausgeschlossen. Die Aktion des Auftragsschritts wird in der ausgeschlossenen Datenbank nicht ausgeführt.
• Beispiel 4 zeigt eine Zielgruppe, die einen Pool für elastische Datenbanken als Ziel enthält. So ähnlich wie in Beispiel 2 wird der Pool zum Zeitpunkt der Auftragsausführung dynamisch aufgezählt, um die Liste der Datenbanken im Pool zu bestimmen.

• Beispiel 5 und Beispiel 6 zeigen erweiterte Szenarien, bei denen Server, Datenbanken und Pools für elastische Datenbanken mithilfe von Ein- und Ausschlussregeln kombiniert werden können.

Authentifizierung

Wählen Sie eine Methode für alle Ziele für einen Agenten für elastischen Aufträge aus. Beispielsweise können Sie für einen einzelnen Agenten für elastischen Aufträge nicht einen Zielserver so konfigurieren, dass er datenbankübergreifende Anmeldeinformationen verwendet, und einen anderen so, dass er Microsoft Entra ID-Authentifizierung verwendet.

Der Agent für elastischen Aufträge kann sich über zwei Authentifizierungsoptionen mit dem/den von der Zielgruppe angegebenen Server(n)/Datenbank(en) verbinden:

• Verwenden Sie die Microsoft Entra-Authentifizierung (früher Azure Active Directory) mit einer benutzerseitig zugewiesene verwaltete Identität (UMI).
• Verwendung datenbankweit gültiger Anmeldeinformationen.

Authentifizierung über eine benutzerseitig zugewiesene verwaltete Identität (UMI)

Die Authentifizierung mit Microsoft Entra (früher Azure Active Directory) über eine benutzerseitig zugewiesene verwaltete Identität (UMI) ist die empfohlene Option für die Verbindung von elastischen Aufträgen mit der Azure SQL-Datenbank. Dank der Unterstützung von Microsoft Entra ID kann der Auftrags-Agent mithilfe der UMI eine Verbindung mit Zieldatenbanken (Datenbankservern, Pool für elastische Datenbanken) und Ausgabedatenbanken herstellen.

Optional dazu kann die Microsoft Entra ID-Authentifizierung auch auf dem logischen Server aktiviert werden, der die Datenbank für elastische Aufträge enthält, um über Microsoft Entra ID-Verbindungen auf diese Datenbank zuzugreifen bzw. diese Datenbank abzufragen. Der Auftrags-Agent selbst verwendet jedoch eine interne zertifikatsbasierte Authentifizierung, um sich mit seiner Auftrags-Datenbank zu verbinden.

Sie können eine UMI erstellen oder eine bestehende UMI verwenden und dieselbe UMI mehreren Auftrags-Agents zuweisen. Pro Auftrags-Agent wird nur eine UMI unterstützt. Sobald eine UMI einem Auftrags-Agente zugewiesen ist, verwendet dieser Auftrags-Agent diese Identität nur noch, um sich mit den Zieldatenbanken zu verbinden und T-SQL-Jobs auszuführen. Die SQL-Authentifizierung wird nicht für den Zielserver/die Zieldatenbanken dieses Auftrags-Agents verwendet.

Der UMI-Name muss mit einem Buchstaben oder einer Zahl beginnen und zwischen 3 und 128 Zeichen umfassen. Er kann die -- sowie _-Zeichen enthalten.

Weitere Informationen zu UMI in Azure SQL-Datenbank finden Sie unter Verwaltete Identitäten für Azure SQL einschließlich der erforderlichen Schritte und Vorteile der Verwendung einer UMI als logische Serveridentität für die Azure SQL-Datenbank. Weitere Informationen finden Sie unter Verwenden der Microsoft Entra-Authentifizierung.

Die Verwendung einer systemseitig zugewiesenen verwalteten Identität (SMI) wird nicht unterstützt.

Authentifizierung über datenbankgestützte Anmeldeinformationen

Obwohl die Authentifizierung mit Microsoft Entra (früher Azure Active Directory) die empfohlene Option ist, können Aufträge so konfiguriert werden, dass sie datenbankübergreifende Anmeldeinformationen verwenden, um sich bei der Ausführung mit den von der Zielgruppe angegebenen Datenbanken zu verbinden. Vor Oktober 2023 waren datenbankgestützte Anmeldeinformationen die einzige Authentifizierungsoption.

Wenn eine Zielgruppe Server oder Pools enthält, wird unter Verwendung dieser datenbankweit gültigen Anmeldeinformationen eine Verbindung mit der master-Datenbank hergestellt, um die verfügbaren Datenbanken zu enumerieren.

• Die datenbankweit gültigen Anmeldeinformationen müssen in der Auftragsdatenbank erstellt werden.
• Für eine erfolgreiche Auftragsausführung müssen alle Zieldatenbanken über eine Anmeldung mit ausreichenden Berechtigungen verfügen (siehe jobuser im nachfolgenden Diagramm).
• Die in den Zieldatenbanken erstellten Berechtigungsnachweise (LOGIN und PASSWORD für masteruser und jobuser, siehe auch folgendes Diagramm) sollten mit den in der Auftragsdatenbank erstellten IDENTITY und SECRET übereinstimmen.
• Die Anmeldeinformationen können auftragsübergreifend verwendet werden. Die Kennwörter der Anmeldeinformationen sind außerdem verschlüsselt und vor Benutzern geschützt, die nur Lesezugriff auf Auftragsobjekte haben.

Die folgende Abbildung soll Ihnen helfen, die Einrichtung der richtigen Auftrags-Anmeldedaten zu verstehen und wie der Agent für elastische Aufträge sich mit Datenbank-Anmeldedaten zur Authentifizierung mit den Logins/Benutzern der Zielservern-bzw. -datenbanken verbindet.

Private Endpunkte für elastische Aufträge

Der Agent für elastische Aufträge unterstützt private Endpunkte für elastische Aufträge. Das Erstellen eines privaten Endpunkts für elastische Aufträge stellt eine private Verbindung zwischen dem elastischen Auftrag und dem Zielserver her. Das Feature für private Endpunkte für elastische Aufträge unterscheidet sich von dem Azure Private Link.

Das Feature für private Endpunkte für elastische Aufträge unterstützt private Verbindungen mit Ziel-/Ausgabeservern, sodass der Auftrags-Agent sie auch dann erreichen kann, wenn die Option „Öffentlicher Zugriff verweigern“ aktiviert ist. Die Verwendung privater Endpunkte ist auch eine mögliche Lösung, wenn Sie die Option „Azure-Diensten und -Ressourcen den Zugriff auf diesen Server erlauben“ deaktivieren möchten.

Private Endpunkte für elastische Aufträge unterstützen alle Optionen der Authentifizierung des Agent für elastische Aufträge.

Mit dieser Feature können Sie einen vom Dienst verwalteten privaten Endpunkt auswählen, um eine sichere Verbindung zwischen dem Auftrags-Agent und den Ziel-/Ausgabeservern herzustellen. Ein dienstseitig verwalteter privater Endpunkt ist eine private IP-Adresse in einem bestimmten virtuellen Netzwerk und Subnetz. Wenn Sie sich für die Verwendung privater Endpunkte auf einem der Ziel-/Ausgabeserver Ihres Auftrags-Agents entscheiden, wird von Microsoft ein dienstverwalteter privater Endpunkt erstellt. Dieser private Endpunkt wird dann ausschließlich vom Auftrags-Agenten zum Verbinden und Ausführen von Aufträgen oder zum Schreiben der Auftragsausgabe auf diese Ziel-/Ausgabedatenbank verwendet.

Private Endpunkte für elastische Aufträge können über das Azure-Portal erstellt und zugelassen werden. Zielserver, die über den privaten Link verbunden sind, können überall in Azure und sogar in verschiedenen Regionen und Abonnements vorhanden sein. Sie müssen für jeden gewünschten Zielserver und den Auftragsausgabeserver einen privaten Endpunkt erstellen, um diese Kommunikation zu ermöglichen.

Eine Anleitung zur Konfiguration eines neuen dienstverwalteten privaten Endpunkts für erlastische Aufträge finden Sie unter Konfigurieren des privaten Endpunkts von elastischen Aufträgen in Azure SQL.

Anforderungen für private Endpunkte für elastische Aufträge

• Um einen privaten Endpunkt für elastische Aufträge zu verwenden, müssen sowohl der Auftrags-Agent als auch die Zielserver/-datenbanken in Azure gehostet werden (in derselben oder in verschiedenen Regionen) und sich im selben Cloud-Typ befinden (z. B. beide in der Public Cloud oder beide in der Government Cloud).
• Der Microsoft.Network Ressourcenanbieter muss für die Host-Abonnements sowohl des Auftrags-Agents als auch der Ziel-/Ausgabeserver registriert sein.
• Private Endpunkte für elastische Aufträge werden pro Ziel-/Ausgabeserver erstellt. Sie müssen genehmigt werden, bevor der Agent für elastische Aufträge sie verwenden kann. Dies kann über den Networking-Bereich dieses logischen Servers oder Ihres bevorzugten Clients erfolgen. Der Agent für elastische Aufträge kann dann alle Datenbanken unter diesem Server über eine private Verbindung erreichen.
• Die Verbindung vom Agent für elastische Aufträge zur Auftragsdatenbank verwendet keinen privaten Endpunkt. Der Auftrags-Agent selbst verwendet jedoch eine interne zertifikatsbasierte Authentifizierung, um sich mit seiner Auftrags-Datenbank zu verbinden. Eine Einschränkung ist, wenn Sie die Auftragsdatenbank als Zielgruppenmitglied hinzufügen. Dann verhält er sich als normales Ziel, das Sie bei Bedarf mit einem privatem Endpunkt einrichten müssen.

Berechtigungen für die Datenbank für elastische Aufträge

Im Zuge der Erstellung des Auftrags-Agents werden in der Auftragsdatenbank ein Schema, Tabellen und eine Rolle namens jobs_reader erstellt. Die Rolle wird mit folgenden Berechtigung erstellt und soll Administratoren eine präzisere Zugriffssteuerung für die Auftragsüberwachung ermöglichen: Administratoren können Benutzern die Möglichkeit bieten, die Auftragsausführung zu überwachen, indem sie sie zur Rolle jobs_reader in der Auftragsdatenbank hinzufügen.

Überwachen elastischer Aufträge

Der Agent für elastische Aufträge verfügt über eine Integration mit Azure Alerts für Benachrichtigungen über den Auftragsstatus, wodurch die Lösung zur Überwachung des Status und der Verlauf der Auftragsausführung vereinfacht wird.

Das Azure-Portal verfügt außerdem über neue, zusätzliche Features zur Unterstützung von elastischen Aufträgen und zur Auftragsüberwachung. Auf der Übersichtsseite des elastischen Auftrag-Agents werden die neuesten Auftragsausführungen wie im folgenden Screenshot angezeigt.

Sie können Azure Monitor-Benachrichtigungsregeln über das Azure-Portal, Azure CLI, PowerShell und REST API erstellen. Die Metrik Fehlgeschlagene elastische Aufträge ist ein guter Ausgangspunkt, um die Ausführung von elastischen Auftr*agen zu überwachen und Warnungen zu erhalten. Darüber hinaus können Sie sich über eine konfigurierbare Aktion wie SMS oder E-Mail von der Azure Alert-Funktion benachrichtigen lassen. Weitere Informationen finden Sie unter Erstellen von Benachrichtigungen für SQL-Datenbanken im Azure-Portal.

Siehe auch Erstellen, Konfigurieren und Verwalten von elastischen Aufträgen.

Auftragsausgabe

Das Ergebnis der Auftragsschritte wird für jede Zieldatenbank detailliert erfasst, und als Ziel für die Skriptausgabe kann eine Tabelle angegeben werden. Sie können eine Datenbank angeben, in der alle von einem Auftrag zurückgegebenen Daten gespeichert werden.

Auftragsverlauf

Siehe auch Ausführungsverlauf eines elastischen Auftrags in der Auftragsdatenbank durch Abfragen der Tabelle jobs.job_executions. Daten des Ausführungsverlaufs, die älter als 45 Tage sind, werden durch einen Systembereinigungsauftrag bereinigt. Wenn Sie Verlaufsdaten manuell löschen möchten, die noch keine 45 Tage alt sind, führen Sie die gespeicherte Prozedur sp_purge_jobhistory in der Auftragsdatenbank aus.

Auftragsstatus

Sie können die Ausführung von elastischen Aufträge in der Auftrags-Datenbank überwachen, indem Sie die Tabelle jobs.job_executions abfragen.

Bewährte Methoden

Berücksichtigen Sie bei der Arbeit mit Aufträge für die elastische Datenbank folgende Best Practices:

Bewährte Methoden für die Sicherheit

• Schränken Sie die Nutzung der APIs auf einen vertrauenswürdigen Personenkreis ein.
• Anmeldeinformationen sollten immer nur mit den für die Ausführung von Auftragsschritten erforderlichen Mindestberechtigungen ausgestattet sein. Weitere Informationen finden Sie unter Autorisierung und Berechtigungen.
• Wenn der Zielgruppe ein Server und/oder Pool angehört, sollten Sie für die master-Datenbank unbedingt separate Anmeldeinformationen mit Rechten zum Anzeigen/Auflisten der Datenbanken erstellen, um die Datenbanklisten der Server und/oder Pools vor der Auftragsausführung zu erweitern.

Die Leistung elastischer Aufträge

Elastische Aufträge benötigen nur sehr wenig Computeressourcen, während sie auf den Abschluss von Aufträgen mit langer Ausführungszeit warten.

Die Compute- und Leistungsanforderungen, die der Agent an die Auftragsdatenbank stellt, hängen von der Größe der Zielgruppe mit den Datenbanken und der gewünschten Ausführungszeit für einen Auftrag (Anzahl gleichzeitiger Worker) ab (je mehr Ziele und je höher die Anzahl von Aufträgen, desto höher die Computeanforderungen).

Nebenläufige Kapazitätsebenen

Seit Oktober 2023 verfügt der Agent für elastische Aufträge über mehrere Leistungsstufen, die eine Erhöhung der Kapazität ermöglichen.

Die Kapazitätsschritte geben die Gesamtzahl der gleichzeitigen Zieldatenbanken an, mit denen der Auftrags-Agent eine Verbindung herstellen und einen Auftrag starten kann. Wenn Sie mehr gleichzeitige Zielverbindungen für die Auftragsausführung benötigen, erhöhen Sie die Stufe eines Auftrags-Agents von der Standardstufe JA100, die ein Limit von 100 gleichzeitigen Zielverbindungen hat.

In den meisten Umgebungen sind weniger als 100 gleichzeitige Aufträge erforderlich, daher ist JA100 die Standardeinstellung.

Das Überschreiten der Parallelitätskapazitätsstufe des Auftrags-Agents mit Auftragszielen führt zu Warteschlangenverzögerungen für einige Zieldatenbanken/-server. Wenn Sie zum Beispiel einen Auftrag mit 110 Zielen in der Stufe JA100 starten, werden 10 Ziele warten, bis die anderen fertig sind.

Das Stufen- oder Serviceziel eines Agents für elastische Aufträgen kann über das Azure-Portal, PowerShell oder die Auftrags-Agent-REST-API geändert werden. Ein Beispiel finden Sie unter Skalieren des Auftrags-Agents.

Begrenzen der Auftragsauswirkungen auf Pool für elastische Datenbanken

Die Anzahl von Datenbanken, für die ein Auftrag gleichzeitig ausgeführt werden kann, kann beschränkt werden, um sicherzustellen, dass es beim Ausführen von Aufträgen für Datenbanken in einen Pool für elastische Azure SQL Datenbanken nicht zu einer Überlastung der Ressourcen kommt.

Legen Sie die Anzahl der gleichzeitigen Datenbanken, in denen ein Auftrag ausgeführt wird, mit dem Parameter @max_parallelism der gespeicherten Prozedur sp_add_jobstep in T-SQL fest.

Idempotente Skripts

Die T-SQL-Skripts eines elastischen Auftrags müssen idempotent sein. Idempotent bedeutet, dass die erneute Ausführung eines bereits erfolgreich ausgeführten Skripts zum selben Ergebnis führt. Es kann vorkommen, dass ein Skript aufgrund von vorübergehenden Netzwerkproblemen nicht erfolgreich ausgeführt wird. In diesem Fall führt der Auftrag automatisch eine bestimmte Anzahl von Wiederholungsversuchen für das Skript aus. Ein idempotentes Skript führt auch bei mehrmaliger erfolgreicher Ausführung zum selben Ergebnis.

Vor dem Erstellen eines Objekts empfiehlt es sich, zu überprüfen, ob es bereits vorhanden ist. Im Folgenden finden Sie ein hypothetisches Beispiel:

IF NOT EXISTS (SELECT * FROM sys.objects WHERE [name] = N'some_object')
    print 'Object does not exist'
    -- Create the object
ELSE
    print 'Object exists'
    -- If it exists, drop the object before recreating it.

Analog dazu muss auch ein Skript erfolgreich ausgeführt werden können, indem logische Tests durchgeführt werden und angemessen auf die vorgefundenen Bedingungen reagiert wird.

Begrenzungen

Nachstehend werden die aktuellen Einschränkungen des Diensts für elastische Aufträge aufgeführt. Wir arbeiten daran, möglichst viele dieser Einschränkungen zu beseitigen.

Zugehöriger Inhalt

• Erstellen, Konfigurieren und Verwalten von Aufträgen für die elastische Datenbank
• Automatisieren von Verwaltungsaufgaben in Azure SQL
• Erstellen und Verwalten von elastischen Aufträgen mithilfe von PowerShell
• Erstellen und Verwalten von elastischen Aufträgen mithilfe von T-SQL

Nächster Schritt