SQL Serverエージェントを使用して、データベース以外のタスクもスケジュールしています-これは悪い考えですか？

私はDBA（および多くの場合、事実上のsysadmin）であるため、SQL Serverは、定期的に作業する必要があるほとんどすべてのサーバーにインストールされます。最近、ネイティブWindowsタスクスケジューラではなく、ほとんどすべての場合にジョブスケジューラとしてSQLエージェントを使用していることに気付きました。

私の観点から見ると、SQLエージェントには、ネイティブのWindowsタスクスケジューラーよりも多くの利点があります。

• リモート（私のワークステーションから）タスクの開始/停止/監視
• 共有スケジュール（各タスク自体ではなく）
• 複数のステップと制御フロー
• さまざまな種類のタスク
• 失敗/完了のアラート
• 異なるユーザーとして動作するように構成できます
• （中程度）エラーコードではなく、説明的なエラーメッセージ

しかし、これは悪い習慣であるという感覚から逃れることはできません-SQLエージェントはデータベース関連のタスクのためだけに予約する必要があり、その使いやすさを嫌いながらも、WindowsレベルのタスクスケジューラでOSレベルのタスクを実行したままにする必要があります。

この方法でSQLエージェントに依存しても大丈夫ですか？そうでない場合、探している機能の一部を取得するために、サードパーティのWindowsタスクスケジューラを検討する必要がありますか？

個人的には、最大の警告は仕事のリストを整理するのが難しいことだと思います。私が知っている限りでは、ジョブを整理するためのフォルダーを作成することはできないため、多数のファイルを作成するのは面倒です。ただし、私のサーバーには1ダースほどのジョブしかないので、100％確信はありません。Server 2008以降のタスクスケジューラを使用すると、IMOの編成がはるかに簡単になり、一般に以前のバージョンよりもはるかに優れた機能を備えています。サードパーティのアプリがさらに良い仕事をしていると確信しています。Server 2003のタスクスケジューラを使用する必要がある場合、またはat.exe。

私が考えることができる2番目の警告は、潜在的にSQLサーバーに過度の負荷をかけることです。エージェントは小さなプログラムですが、長いタスクや複雑なタスクを実行すると、多くのリソースが簡単に消費される可能性があります。これらのリソースは、SQLエンジンでは使用できません。SQLエンジンは利用可能なシステムメモリの約80％を使用するようにプログラムされているため、これは問題になる可能性があります。

第三に、バックアップが問題になる場合があります。ファイルシステムだけでなく、msdbデータベースもバックアップして、ジョブを回復できるようにする必要があります（または何かを使用して、タスクをテキストファイルにスクリプト化します）。これにより、災害復旧に複雑な層が追加されます。

最後に、SQL Serverエージェントを実行するためだけにSQL Serverライセンスを購入する立場にはなりたくないでしょう。データベースが使用停止になった場合は、SQL Serverエージェントから移行する計画を作成する必要があります。

前の仕事でこれを正確にやったのは、主にジョブがすべて最も目に見えるサーバーである中央のプライマリクラスターから実行されたためです。多数のサーバーでコマンドラインをチェックする代わりに、スケジュールされたすべてのタスクを1か所で見ることができました。

これは主に主観的なものですが（この形式で「正しい」答えを導き出すのは難しいでしょう）、このアプローチには本質的に問題があるとは考えていません。

すべてのタスクが、稼働中のデータベースサーバーと実行中のSQL Serverサービスと対話する、または依存している場合は、関係ない場合があります（この場合は実行しました）。

ああ、タスクを実行しようとするサーバーが稼働していない場合にエラー処理を追加する必要があります。タスクがそのサーバーにセットアップされていれば、実行する必要はありません。

私は〜おそらく〜Windowsタスクマネージャーを介してSQLエージェントを使用します...明らかにデータベース関連のタスクの場合。

まったくコーディングできる場合、またはコーディングできる人がいる場合は、コンソールアプリを使用して、TopShelf（http://topshelf-project.com/）のようなサービスクリエーターにラップすることができます。簡単にハックして、SQLエージェントからすべてを少し切り離し、その時点でキューイングのレイヤーを提供し始めます。

個人的には、あなたはこれに十分気を配り、あなたが大丈夫だと思うあなたの落とし穴を十分に知っているようです。私が本当に心配していることを気にしない/知っているのは人々です。合理的な間隔でソリューションを評価し、それに応じて行動することは間違いありません。

別のオプションは、ストアドプロシージャを使用してスケジュールされたタスクのテーブルを作成し、そこからメッセージキューテーブルを更新することです。次に、SQL Serverエージェントは、ストアドプロシージャを頻繁に呼び出して、メッセージを作成し、タスクの状態を更新します。他のシステムは、SQL接続またはWeb APIレイヤーのいずれかを介してJSONとしてメッセージキューテーブルを照会します。