Ich sehe oft „Probleme“, die Anforderungen an SQL Server beinhalten, um „Drecksarbeit“ zu leisten, wie:
- In meinem Trigger muss ich eine Datei zum/vom Netzwerk kopieren
- Meine gespeicherte Prozedur muss eine Datei per FTP übertragen
- Nachdem die Sicherung abgeschlossen ist, muss SQL Server sie komprimieren, eine Kopie erstellen und sie dann archivieren
- Wenn ein Kunde hinzugefügt wird, möchte ich eine neue Datenbank erstellen und einige Dinge in Active Directory erledigen
- Mein SQL Server-Agent-Job muss ein Verzeichnis nach Dateien durchsuchen und Masseneinfügungen durchführen, wenn er neue findet
Dies ist keine vollständige Liste; Ich könnte wahrscheinlich eine Seite füllen. Der Punkt ist, dass das Ausführen dieser Aufgaben innerhalb von SQL Server erhebliche Hindernisse darstellt:
Sicherheit
In der Regel werden Sie für alles, wo Sie der Meinung sind, dass SQL Server Zugriff auf das Dateisystem oder einen anderen Zugriff auf Betriebssystemebene benötigt, entweder (a) dem SQL Server-Dienstkonto (und/oder den SQL Agent-/Proxy-Konten) explizite Freibriefrechte erteilen, oder (b) legen Sie einfach SQL Server-Dienstkonten so fest, dass sie als vorhandenes Domänenkonto ausgeführt werden, das bereits über alle diese Rechte verfügt. Dies ist die „einfache“ Lösung – anstatt einzeln Zugriff auf diesen Ordner und diese Freigabe und diese andere Ressource zu gewähren, wischen Sie sich einfach die Hände ab, weil sie bereits Domänenadministratoren sind. Als nächstes aktivieren Sie Einstellungen auf Serverebene, die standardmäßig deaktiviert sind, Ihnen aber beim Ausführen einer oder mehrerer der oben genannten Aufgaben im Weg stehen (z. B. xp_cmdshell ).
Ich glaube nicht, dass ich das Ausmaß der Exposition erklären muss, das diese Aktionen darstellen können. Oder welche Art von Problemen passieren können, wenn es sich um ein echtes Mitarbeiterkonto handelt und dieser Mitarbeiter geht – oder feststellt, dass er/sie verärgert ist, bevor er geht. Huch. Ich habe mehrere Fälle gesehen, in denen ein gemeinsames Konto für alle SQL Server verwendet wird. Ratet mal, was passiert, wenn/wenn Sie das Passwort für ein Domänenkonto ändern müssen, das von Dutzenden oder Hunderten von SQL Server-Instanzen aktiv verwendet wird? Egal, wie oft es passieren wird, wenn Sie diesen Benutzer nicht von den Richtlinien zum Zurücksetzen des Passworts ausschließen?
Leistung
Zusätzlich zu Sicherheitsproblemen kann das Verlassen des Datenbankservers zu Verzögerungen führen, während SQL Server auf einen externen Prozess angewiesen ist, über den es keine Kontrolle hat. Muss die Datenbanktransaktion wirklich warten, bis eine Datei komprimiert und kopiert wird, oder bis eine FTP-Übertragung abgeschlossen ist, oder bis Ihr Backup-Domänencontroller antwortet? Wie wirkt sich das aus, wenn mehrere Benutzer ähnliche Aufgaben ausführen und alle um dieselbe Bandbreite und/oder Festplattenköpfe konkurrieren? Außerdem müssen Sie bedenken, dass, sobald SQL Server eine Batchdatei angewiesen hat, etwas zu tun, die enthaltende Transaktion rückgängig gemacht wird, Sie die externe Aktion nicht rückgängig machen können.
Die Antwort
Nun, normalerweise – und es gibt immer Ausnahmen – besteht die Antwort darin, externe Prozesse für diese Aufgaben zu verwenden, die eigentlich außerhalb von SQL Server liegen. Verwenden Sie PowerShell, verwenden Sie C#, verwenden Sie Batch-Dateien; hey, nutze VBScript. Denken Sie darüber nach, welche dieser Aufgaben wirklich *sofort* und während die Transaktion noch aktiv ist, erledigt werden müssen – ich vermute nicht viele. Erstellen Sie eine Warteschlangentabelle für diese und schreiben Sie in die Warteschlangentabelle innerhalb der Transaktion (die zurückgesetzt wird, wenn die Transaktion nicht erfolgreich ist). Verwenden Sie dann eine Hintergrundaufgabe oder ein Skript, das Zeilen aus der Warteschlangentabelle verbraucht, die zugeordnete(n) Aufgabe(n) ausführt und jede Zeile löscht oder als abgeschlossen markiert. Zusätzlicher Bonus:Der SQL Server-Agent ist hier nicht erforderlich, sodass Sie jeden Enterprise-Scheduler verwenden können, und die Methode funktioniert weiterhin mit SQL Server Express.
