1

私たちが抱えている問題に少し立ち往生しているので、シナリオ、問題、そして私たちが試したことを説明するために最善を尽くします。

  1. 末尾に日付が追加されたタグが付けられた特定のファイルにログを記録するSQLジョブがあります
  2. 最初のステップでは、ログファイルが何であるかを確認します（例：log_01012012.log）。これが正しくない場合は、テーブルsysjobstepsを更新して、すべてのステップの新しいファイルの場所（例：log_02012012.log）を設定します。これを行うには、最初のジョブステップでストアドプロシージャを呼び出します。
  3. これはテーブルで更新されますが、残りの手順では古いログが使用され続けます。これは、ジョブの開始時にこのテーブルが1回だけ読み取られると想定しているためです。

次のコードを使用して、ストアドプロシージャ内でジョブを再開しようとしました。

EXEC msdb.dbo.sp_stop_job @job_name = 'My Job'
waitfor delay '00:00:15'
EXEC msdb.dbo.sp_start_job @job_name = 'My Job'

ただし、ジョブを強制終了すると、ストアドプロシージャ（ジョブの子であると思われます）が強制終了されたように見えます。つまり、ジョブを再開するステップに到達することはありません。

ジョブがそれ自体を再起動して、sysjobstepsテーブルを再度確認し、ログに正しい場所を使用する方法はありますか？

問題を解決するかもしれないものは

  • ジョブ自体からジョブを再開できること
  • いくつかの点で仕事をリフレッシュすることができる。

明確にする必要があることは何でも最善を尽くしますが、現在は行き詰まっており、すべての入力に大いに感謝します！

4

3 に答える 3

0

Service Broker を使用すると、面白いことができます。何かのようなもの：

1) ジョブの最後のステップとしてメッセージをブローカー キューに入れます。内容は空にすることができます。「ねえ...ジョブを再送信する必要があります」と言うのは単なるトークンです。

2) 遅延を発生させるキューのアクティブ化ストアド プロシージャを記述し (既存のプロシージャで行っているように)、ジョブを再送信します。

または、ジョブ ステップ自体にログ ファイル名をハードコーディングする代わりに、そのデータをテーブルのどこかに配置します。次に、場所を変更するステップで、成功条件を「次のステップに進む」、失敗条件を「ステップ 1 に進む」と定義します。次に、ファイルの場所を変更してエラーを返すようにコードを変更します (これにより、ジョブ ステップの失敗条件がトリガーされます)。

于 2012-05-11T10:51:25.273 に答える
0

SSMS で SQL サーバー エージェントに移動します。

ジョブを展開

  1. 仕事を作り、
  2. ステップを定義する (sp または簡単なクエリ)
  3. スケジュールを定義する (sqlserver の再起動時にジョブを開始する頻度またはジョブを開始する)
  4. ジョブが完了したときにメールで通知するように設定します (成功/失敗)

お役に立てれば。

于 2012-05-11T03:37:33.620 に答える