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

Komponente	Beschreibung
Agent für elastische Aufträge	Der Azure-Ressource, die Sie zum Ausführen und Verwalten von Aufträgen erstellen.
Auftragsdatenbank	Eine Datenbank in Azure SQL-Datenbank, in der der Auftrags-Agent auftragsbezogene Daten, Auftragsdefinitionen usw. speichert.
Auftrag	Ein Auftrag ist eine Arbeitseinheit mit mindestens einem Auftragsschritt. Auftragsschritte geben das auszuführende T-SQL-Skript sowie andere für die Skriptausführung erforderliche Details an.
Zielgruppe	Die Gruppe von Servern, Pools und Datenbanken, für die ein Auftrag ausgeführt werden soll.

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.

Wichtig

Ändern Sie die vorhandenen Objekte nicht und erstellen Sie keine neuen Objekte in der Auftragsdatenbank, auch wenn Sie die Tabellen für Berichte und Analysen lesen können.

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.

Tipp

Die Gruppe von Datenbanken in Zielgruppen mit Servern oder Pools wird dank dynamischer Enumeration zum Zeitpunkt der Auftragsausführung neu ausgewertet. Die dynamische Enumeration stellt sicher, dass Aufträge für alle Datenbanken ausgeführt werden, die zum Zeitpunkt der Auftragsausführung auf dem Server oder im Pool vorhanden sind. Das erneute Auswerten der Datenbankliste zur Laufzeit ist besonders hilfreich in Szenarios mit häufig wechselnder Pool- oder Servermitgliedschaft.

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.

Hinweis

Die Auftragsdatenbank kann selbst Ziel eines Auftrags sein. In diesem Szenario wird die Auftragsdatenbank genau wie jede andere Zieldatenbank behandelt. Der Auftragsbenutzer muss in der Auftragsdatenbank mit ausreichenden Berechtigungen erstellt werden, und die datenbankweit gültigen Anmeldeinformationen für den Auftragsbenutzer müssen auch in der Auftragsdatenbank vorhanden sein (genau wie bei anderen Zieldatenbanken).

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.

Wichtig

Wenn Sie die Microsoft Entra ID-Authentifizierung verwenden, erstellen Sie Ihren jobuser-Benutzer aus dieser Microsoft Entra ID in der betroffnen Zieldatenbank. Gewähren Sie diesem Benutzer die erforderlichen Berechtigungen, um Ihren Auftrag bzw. Ihre Aufträge in den bestimmten Zieldatenbanken auszuführen.

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.

Hinweis

Wenn Sie datenbankübergreifende Anmeldedaten verwenden, müssen Sie Ihren jobuser-Benutzer in jeder Zieldatenbank separat anlegen.

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.

Rollenname	jobs Schemaberechtigungen	jobs_internal Schemaberechtigungen
jobs_reader	SELECT	Keine

Achtung

Sie dürfen keine internen Katalogansichten in der Auftragsdatenbank aktualisieren, wie z. B. jobs.target_group_members. Das manuelle Ändern dieser Katalogansichten kann die Auftragsdatenbank beschädigen und zu einem Fehler führen. Diese Ansichten dienen nur für schreibgeschützte Abfragen. Sie können die gespeicherten Prozeduren in Ihrer Auftragsdatenbank verwenden, um Zielgruppen/Mitglieder wie z. B. jobs.sp_add_target_group_member hinzuzufügen/zu löschen.

Wichtig

Bedenken Sie die Auswirkungen auf die Sicherheit, bevor Sie einen erweiterten Zugriff auf die Auftragsdatenbank gewähren. Ein böswilliger Benutzer mit Berechtigungen zum Erstellen oder Bearbeiten von Aufträgen kann theoretisch einen Auftrag erstellen oder bearbeiten, der unter Verwendung gespeicherter Anmeldeinformationen eine Verbindung mit einer Datenbank herstellt, die der Kontrolle des böswilligen Benutzers unterliegt. Auf diese Weise kann der böswillige Benutzer dann das Kennwort der Anmeldeinformationen ermitteln oder bösartige Befehle ausführen.

Ü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.

Erstellen einer Ebene für den Agenten für elastische Aufträge	Maximale Anzahl gleichzeitiger Aufträge
JA100	100
JA200	200
JA400	400
JA800	800

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.

Problem	BESCHREIBUNG
Nach einem Failover/einer Verschiebung in eine neue Azure-Region muss der Agent für elastische Aufträge neu erstellt und in der neuen Region gestartet werden.	Der Dienst für elastische Aufträge speichert alle Auftrags-Agents und Auftragsmetadaten in der Auftragsdatenbank. Bei jedem Failover und jeder Verschiebung von Azure-Ressourcen in eine neue Azure-Region werden auch die Auftragsdatenbank, der Auftrags-Agent und die Auftragsmetadaten in die neue Azure-Region verschieben. Der Agent für elastische Aufträge ist jedoch eine reine Computeressource und muss explizit neu erstellt und in der neuen Region gestartet werden, damit Aufträge in der neuen Region ausgeführt werden können. Nach dem Start setzt der Agent für elastische Aufträge die Ausführung von Aufträgen in der neuen Region gemäß dem zuvor definierten Auftragszeitplan fort.
Übermäßig viele Überwachungsprotokolle aus der Auftragsdatenbank	Der Agent für elastische Aufträge fragt fortlaufend die Auftragsdatenbank ab, um diese auf den Eingang neuer Aufträge und andere CRUD-Vorgänge zu überprüfen. Wenn die Überwachung auf dem Server aktiviert ist, auf dem eine Auftragsdatenbank vorhanden ist, wird möglicherweise eine große Menge an Überwachungsprotokollen von der Auftragsdatenbank generiert. Diese kann verringert werden, indem Sie diese Überwachungsprotokolle mithilfe des Befehls Set-AzSqlServerAudit und einem Prädikatausdruck herausfiltern. Beispiel: Set-AzSqlServerAudit -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -BlobStorageTargetState Enabled -StorageAccountResourceId "/subscriptions/7fe3301d-31d3-4668-af5e-211a890ba6e3/resourceGroups/resourcegroup01/providers/Microsoft.Storage/storageAccounts/mystorage" -PredicateExpression "database_principal_name <> '##MS_JobAccount##'" Mit diesem Befehl werden nur Überwachungsprotokolle vom Auftrags-Agenten an Auftragsdatenbanken herausgefiltert, nicht jedoch Überwachungsprotokolle vom Auftrags-Agent an beliebige Zieldatenbanken.
Verwenden einer Hyperscale-Datenbank als Auftragsdatenbank	Verwenden einer Hyperscale-Datenbank als Auftragsdatenbank wird nicht unterstützt. Elastische Aufträge können jedoch Hyperscale-Datenbanken auf die gleiche Weise wie jede andere Datenbank in Azure SQL-Datenbank als Ziel verwenden.
Serverlose Datenbanken und automatisches Anhalten mit elastischen Aufträgen.	Eine serverlose Datenbank, die AutoAnhalten unterstützt, wird als Auftragsdatenbank nicht unterstützt. Serverlose Datenbanken, auf die elastische Aufträge gerichtet sind, unterstützen das automatische Anhalten und werden von Auftragsverbindungen fortgesetzt.
Exportieren einer Auftragsdatenbank in eine BACPAC-Datei	Der Export einer Auftragsdatenbank in eine BACPAC-Datei wird nicht unterstützt. Wenn der SQL-Server, der eine Auftragsdatenbank enthält, exportiert werden muss, sollte die Auftragsdatenbank zuerst gelöscht werden, bevor der Server exportiert wird.

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

Tutorial: Erstellen, Konfigurieren und Verwalten von Aufträgen für die elastische Datenbank