0

私の問題(シナリオ):

たとえば「ストアドプロシージャ」を実行できる組み込みメソッド呼び出し「WAITFOR」がすでにあります。この待機は 24 時間未満しか実行できません。

しかし問題は、開発者でもある私のクライアントが、この問題を回避し、開発時間を短縮するために 24 時間以上待つ方法を見つけたいと考えていることです。

方法はすでにある。これにより、必要なテーブルを 1 日 1 回クエリし、必要なメールを顧客などに送信できます。

この「WAITFOR」は 24 時間に制限されているため、この「WAITFOR」の実行回数が増えると (たとえば 2000)、パフォーマンスの問題が発生するはずです。

私の質問:

  1. ストアド プロシージャを 24 時間以上保持する方法はありますか。14日以上としましょう。
  2. これを解決する方法がない場合,,この問題についてどのように弁護すればよいですか, クライアントに提供できる事実は何ですか, パフォーマンスの問題など,,

これは私が思うことです.この待機は24時間に制限されているため、データベースタスクを正確に時間どおりに実行するために期待される機能を提供する他のオプションはありません. ただし、これにより、各「WAITFOR」実行を追跡するためにサーバーに大きなオーバーヘッドが生じます。これが 2000 を超えると、サーバーとしては耐えられません。

利用可能な最良のオプションは、(必要に応じて) 1 日に 1 回実行される「SQL エージェント ジョブ」を用意し、 WAITFORの設定に関連する値を取得して、ジョブを時間どおりに正確に実行することです。

24 時間以上待つというこの問題について、よりよく理解してください。次の代替案に進みます。:(((((

前もって感謝します。

4

2 に答える 2

4

ストアド プロシージャを 24 時間以上保持する方法はありますか。14日以上としましょう。

はい、たとえば 14 x 24 時間WAITFORです..しかしもちろん、それは説明する能力を超えてひどいものです。その期間、接続を強制的に開いたままにし、その期間サーバー上のリソースを消費するなどです。

あなたが説明するのは、まさにSQLエージェントジョブの目的です。使用してください。

于 2012-07-20T10:30:13.140 に答える
0

WAITFOR 制限に関する質問は、簡単な方法で解決できます。「Waitfor」を数回実行するだけです。

Declare @i int;
Set @i = 0;
While @i < 5
Begin
    Set @i = @i + 1
    WAITFOR DELAY '00:00:01';
End;

正確な時間の後にジョブを実行したい場合は、サービス ブローカ (SB) とダイアログ タイマーを使用することもできます。(私はSBが大好きなので、どこでも使用されているかもしれません..)。

SB では、メッセージを送信して (実行する時間を含めることも、固定時間を設定することもできます)、ダイアログ タイマーを開始することができます。そうすれば、接続を開いたままにすることはありません。

SB BEGIN CONVERSATION TIMER、およびService Broker

于 2012-07-20T11:16:00.917 に答える