仕事：
タイムスタンプを MS SQL データベース テーブルに毎秒書き込みます。
ソリューション:
- スケジュールによってタイムスタンプを書き込む外部アプリケーション (SQL エージェントなど)。
- 無限ループでタイムスタンプを書き込むストアド プロシージャ。
質問。
- どのソリューションが最適ですか?
- ストアド プロシージャで無限ループを実行することの欠点はありますか?
- サーバーの再起動後にストアドプロシージャを開始する方法は?
- 他の解決策はありますか？
質問する
425 次
3 に答える
3
- どちらかですが、ストアドプロシージャルートを使用する傾向があります
WAITFOR DELAY - あまり
- sp_procoption とストアド プロシージャの起動
- 外部のクライアントやシステムが絡まなければ考えられない
于 2010-07-03T13:01:19.843 に答える
2
1、どちらにもメリットとデメリットがあります。環境に基づいて評価して選択する
手順の利点:
- 1 秒に 1 回の SQL エージェント処理のオーバーヘッドがありません。(実際、SQL エージェントに同じジョブを 1 秒に 1 回一貫して起動させることはできないと思います。)
- WAITFOR モードのプロシージャがリソースを使用しているとは思いませんが、確認したいでしょう。
手順の無効化:
- 手順が失敗した場合 (何らかの理由で停止した場合)、起動しません。(手順が停止したかどうかを確認するために SQL エージェント ジョブを実行している場合を除きます。その場合は、手順を実行することもできます)
- 思ったよりも簡単に停止/中断できる可能性があります (同時実行/デッドロック、デタッチされた DB、手動)メンテナンス中に停止し、再起動を忘れる）
ジョブの利点:
- ジョブが失敗した場合 (おそらくデータベースが利用できない場合)、次のジョブが起動されます
Job Disads:
- 毎秒 SQL エージェントを実行するのは非常に厄介なようです。これを行う場合に必要なサーバー オーバーヘッドを測定します。
- SQL エージェントが失敗または停止した場合、ジョブは実行されません
提案: 1 秒に 1 回にする必要がありますか? 5回、10回、15回、30回に1回でもいいですか？
2、上記以外の場合は、該当しません。ロック、ブロッキング、またはデッドロックの状況に陥らないようにしてください。
3、@gbn が言うように、sp_procoption
4. 悲観的ロック手法に基づく厄介なトリックや、(datetime ではなく) タイムスタンプ データ型に基づくビザンチン ロジックを伴わないものはありません。最善の解決策は、長期的にはこれら 2 つのデータベースを 1 つに統合することだと思われますが、それは短期的な選択肢ではありません。
完全なパラノイアから、次のように 2 つを組み合わせます。
- 2、3、または 5 分ごとに実行するように設定されたジョブ
- ジョブは、タイムスタンプを更新するプロシージャを呼び出し、数秒間待機します
- 手順は停止しないため、ジョブは引き続き実行されます。ジョブの実行中は開始されません (まだ実行中のため)
- プロシージャが何らかの理由で終了した場合、ジョブは次に実行がスケジュールされたときに再び起動します。
于 2010-07-05T22:19:32.597 に答える
1
SQL サービス ブローカーを使用してこれを非同期で実行してみてください。そのキュー システムにより、SQL Server サービスを再起動する必要がある場合でも、データを見逃すことはありません。この種のポーリング シナリオで、これを使用したことがあります。
http://msdn.microsoft.com/en-us/library/ms345108(SQL.90).aspx#sqlsvcbr_topic2
これは役立つかもしれません、 http://msdn.microsoft.com/en-us/library/bb839488.aspx
于 2010-07-06T07:15:40.337 に答える