ベンダーは、ビジネスアプリケーションの5分ごとにMSDBジョブを実行したい

両方のDBがSQL Serverインスタンスに存在する2つの異なるアプリケーションを150以上の他のDBと統合しようとするサードパーティベンダーがあり、2つの異なるアプリケーションを5分ごとに「同期」するMSDBジョブを作成します。毎分実行したかった）。

私の最初の予感は、代わりにWindowsのスケジュールされたジョブ、または恐らく恐ろしいトリガー（通常、このような状況に頼る）を使用して、アプリケーション層で何らかの方法でこれを行う必要があるということです。

MSDBジョブをできるだけDBAタスク用に予約しておくと、混乱が減ります。また、このような非常にアクティブなジョブのジョブ履歴を表示すると、MSDBのクエリが遅くなります。バックアップ履歴などのより重要なもの）。しかし、再び、私の好みが間違っている可能性があり、MSDBのアプリケーション層にいくつかのスペースを確保し、袖をまくり、ジョブ履歴の問題を修正する必要があります。バックアップなどの重要なもの（またはハイパーアクティブなジョブエントリをパージ）。

私が抱えているもう1つの問題は、GUIを介してアップグレードを実行するときに、DBに対してのみ「dbo」権限ではなく、このベンダーに「sysadmin」権限を与える必要があり、ミッションクリティカルなインスタンスを爆破しないことを願っていますDBは（統合の欠点の1つ）です。

私は、私たちが素敵をプレイしていないすべてのベンダーを置く別の「単離された」インスタンス上に置くことができますね、しかし、我々は（新しいSQLインスタンスを指すようにアプリケーションを再設定する必要がため息この場合には、残念ながら簡単ではないが）。

ベンダーは、トリガーがどれほど悪いかについての私の懸念を既に押し返しました。それで、私はこれを少し「グーグルで検索」し、空になりました。これは悪い考えであり、私はそれを参照できるという「信頼できる」リンクを誰かが見ましたか？または、彼らのアプローチを採用すべきですか？

助けを求める前にSQLフォーラムに投稿したことがないと思うので、うまくいけば私の問い合わせは適切に組み立てられます。

編集：SQL Server 2008 Enterprise R2 x64 SP1を実行しています（バージョンについて言及するのを忘れていたことを指摘してくれてありがとう！）うーん、できれば、新しいバージョンに移行するときにMSDBアップグレードスクリプトを変更する必要はありません。

御時間ありがとうございます！リッチ

IMOは、ベンダーが実際に正しい軌道に乗っています。

アプリケーションレイヤージョブでは、すぐに使用できる多くのSQLエージェント機能を再実行する必要があります（たとえば、既に実行中のジョブを実行しない、セキュリティおよび資格情報ストアソリューションを考え出す、ジョブの結果をエラー報告とSQLなどでの結果追跡など）。そして、最も重要なことは、スケジューリングのためにバックアップ/ HA / DCソリューションを提供することです。あなたはしたくないあなたの災害復旧の話をする「とあなたはこれらの50個のNTスケジューラタスクを作成GOスタンバイサーバを復旧が完了した後に」。そのため、彼はシステムスケジューラを使用することに対して抵抗するのが正しいのです。エージェントが持つ機能や能力は何もありません。

彼は引き金に逆らうのがさらに正しい。定期的なジョブを同期トリガーに置き換えると、リクエストのレイテンシが増加し、結合と結合が増加します（スキーマの変更を考える...）、同期の問題によるダウンタイムリスクが増加します（トリガーエラー->アプリエラー対ジョブエラー->修正して後で再試行） 、デッドロックの問題が劇的に増加し（追跡対象/追跡対象間の相互更新による）、さらに多くの問題が発生します。

最も簡単なソリューションは、実際にはエージェントジョブでありmsdb、DBAのために予約されているわけではありません。より洗練されたソリューションは、会話タイマーと内部アクティベーションを使用することです。これは、主に封じ込めのためにエージェントジョブよりもいくつかの利点があります（すべてがアプリDB内にあり、フェールオーバーシナリオをミラーリングすると思います）が、ベンダーが非常に具体的なノウハウを必要とする何かを試すことに消極的です。ところで、DBあたり 5分ごとに1つのジョブを意味しないことを願っています。

sysadminパーミッションについては、ゲームの名前はコード署名です。プライベート証明書で署名することにより、検査および検証された特定の手順に許可を与えることができます。

私の個人的な好みは、同期の少なくとも一部を処理するためにトリガーを使用することです。潜在的な競合、古いデータ、繰り返しジョブのパフォーマンスへの影響などに対処する必要があるため、スケジュールされたポーリング同期は特に気にしません。1〜5分ほど積極的に実行したい場合は、それは紛争と陳腐化を緩和することであり、トリガーの即時性はそれに対処します。

すべてが同じサーバー内で発生している場合は、おそらくトリガー内に同期コードを入れるか、影響を受ける各レコードを同期するストアドプロシージャをトリガーに呼び出させることができます。同期がサーバーにまたがる場合、または1つのデータベースをオフラインにしても他のデータベースが使用できなくなることを防ぐには、Service Brokerを使用して非同期更新を処理する方法を検討します。これは、2つの異なるサーバー間で販売エントリの数値をCRMデータと同期し、一方のサーバーを他のアプリケーションに影響を与えずにオフラインにするために行いました。バックアップが完了すると、Service Brokerはメッセージを配信し、リモートサーバー上のデータを更新します。

また、トリガーについて本質的に悪いことは何もありませんが、T-SQLのほとんどの側面と同様に、恐ろしく動作するコードを書くことは非常に可能です。トリガーの一般的な落とし穴についての記事を書きました。

行儀の良いトリガーを書く