Geplante Ausführung von Code Datenbankoperationen in SQL Server

Question

führen, wenn ich einige Datenbankoperationen nach Zeitplan durchführen will, könnte ich:

• Verwenden Sie SQL Server-Agent (wenn SQL Server) die regelmäßig anrufen gespeicherte Prozedur und/oder führen Sie den T-SQL

• Run einige externen Prozess (geplant von der Task-Scheduler des Betriebssystems zum Beispiel), die die Datenbankoperation

• usw. führt

Zwei Fragen:

1. Was sind einige andere Mittel, dies zu erreichen
2. Welche Entscheidungskriterien sollte man verwenden, um die beste Vorgehensweise zu entscheiden?

Vielen Dank.

Answer 1

Ich denke, der beste Ansatz für die Entscheidungskriterien ist, was der Job ist. Wenn es sich um eine vollständig interne SQL Server-Aufgabe oder eine Gruppe von Aufgaben handelt, die sich nicht auf die Außenwelt beziehen, würde ich sagen, dass eine SQL Job die beste Wette ist. Wenn Sie andererseits Daten abrufen und dann etwas damit machen, das inhärent außerhalb von SQL Server liegt, in T-SQL sehr schwierig oder zeitaufwendig ist, ist vielleicht der externe Dienst die beste Wahl.

Answer 2

Eine andere Möglichkeit besteht darin, irgendwo eine Aufgabenwarteschlange zu haben, und wenn Anwendungen, die die Datenbank anderweitig verwenden, eine Operation ausführen, erledigen sie auch einige Aufgaben außerhalb der Warteschlange. Wikipedia macht so etwas mit seiner Job-Warteschlange. Die Planung ist nicht so sicher wie bei den anderen Methoden, aber Sie können z.B. Aufräumen, wenn der Server stark ausgelastet ist.

Edit: Es ist nicht unbedingt besser oder schlechter als die anderen Techniken. Es eignet sich für Aufgaben, die nicht zu einem bestimmten Termin durchgeführt werden müssen, sondern "ab und zu" oder "bald, aber nicht unbedingt jetzt".

Vorteile

• Sie benötigen keine separate Anwendung oder richten Sie SQL Server-Agenten zu schreiben.
• Sie können alle Kriterien verwenden, die Sie programmieren können, um zu entscheiden, ob eine Aufgabe ausgeführt werden soll oder nicht: sofort, wenn eine bestimmte Zeit verstrichen ist oder nur wenn der Server nicht stark ausgelastet ist.
• Wenn es sich bei den geplanten Tasks um Optimierungsindizes handelt, können Sie sie seltener ausführen, wenn sie weniger wichtig sind (z. B. wenn Aktualisierungen selten sind) und häufiger, wenn Updates üblich sind.

Nachteile

• Sie müssen möglicherweise mehrere Anwendungen zu modifizieren, richtig zu kooperieren.
• Sie müssen sicherstellen, dass die Warteschlange nicht zu viel aufgebaut wird.
• Sie können nicht zuverlässig sicherstellen, dass eine Aufgabe vor einer bestimmten Zeit ausgeführt wird.
• Sie haben möglicherweise lange Zeiträume, in denen Sie keine Anfragen erhalten (z. B. nachts), an denen verzögerte/geplante Aufgaben ausgeführt werden könnten, aber nicht. Sie könnten es mit einer der anderen Ideen kombinieren, mit einem speziellen Programm, das nur die Jobs in der Warteschlange erledigt, aber Sie könnten sich einfach nicht mit der Warteschlange herumschlagen.

Answer 3

Ich würde mit SQL Server Agent gehen. Es ist gut in SQL Server integriert; Verschiedene SQL Server-Funktionen verwenden den Agenten (z. B. Log Shipping). Sie können einen Agentenauftrag erstellen, um beispielsweise ein oder mehrere SSIS-Pakete auszuführen.

Es ist auch mit Operatorbenachrichtigung integriert und kann Skripte erstellt oder über SMO ausgeführt werden.

Answer 4

Ich gehe in der Regel mit der Betriebssystem-Scheduling-Methode (Task-Scheduler für Windows, Cron für Unix).

Ich habe mit mehreren Datenbankplattformen (SQL Server, Oracle, Informix) zu tun und möchte die Aufgabenplanung so allgemein wie möglich halten.

Außerdem müssen wir in unserer Produktionsumgebung einen DBA für die Fehlersuche/den Neustart von Jobs erhalten, die in der Datenbank ausgeführt werden. Wir haben besseren Zugriff auf die Anwendungsserver mit den geplanten Aufgaben auf ihnen.

Answer 5

Sie können sich nicht wirklich auf externe Prozesse verlassen. Alle "OS" -basierten Lösungen, die ich gesehen habe, konnten in der realen Welt nicht geliefert werden: Eine Datenbank ist viel mehr als nur die Daten, hauptsächlich wegen der Backup/Restore-Strategie, der Hochverfügbarkeitsstrategie, der Strategie zur Notfallwiederherstellung und all der anderen 'ities' zahlen Sie in Ihrer SQL Server-Lizenz. Ein OS-Scheduler basiert auf einer externen Komponente, die mit keiner von ihnen völlig unbewusst und nicht integriert ist. Ie. Sie können Ihren Zeitplan nicht mit Ihren Daten sichern/wiederherstellen, er wird nicht mit Ihrer Datenbank fehlschlagen, Sie können ihn nicht über Ihren SQL-Datenversandkanal an eine Remote-Disaster Recovery-Site senden.

Wenn Sie einen Agenten haben (dh keine Express Edition), dann verwenden Sie den Agenten. Hat eine lange Geschichte der Nutzung und das Know-how um es ist von Bedeutung. Das einzige Problem mit Agent ist seine Abhängigkeit von msdb, die dazu führt, dass es von der Anwendungsdatenbank getrennt wird und daher nicht gut mit Spiegelungsbasierten Verfügbarkeits- und Wiederherstellungslösungen funktioniert.

Für Express-Editionen (dh kein Agent) ist die beste Option, einen eigenen Scheduler basierend auf conversation timers zu rollen (zumindest in SQL 2k5 und forward). Sie verwenden Konversationen, um Nachrichten im gewünschten Moment zu planen, und verlassen sich auf activated procedures, um die Aufgaben auszuführen. Sie sind transaktional und in Ihre Datenbank integriert, sodass Sie sich darauf verlassen können, dass sie nach einer Wiederherstellung und nach einem Failover mit Spiegelung oder Clustering vorhanden sind. Leider ist das Know-how, wie man sie benutzt, ziemlich übertrieben, ich habe mehrere Artikel über das Thema auf meiner Website rusanu.com. Ich habe Systeme gesehen, die eine ziemlich große Menge von Agenten-APIs in Express replizieren, wobei sie sich ausschließlich auf Konversationstimer verlassen.