私はSQL DBAの役割が初めてです。 1日に複数回実行できるストアドプロシージャ（SP1）があります。これは、テーブル1上で高価なSELECTを実行します。実行には15分かかります。私は完了するために1秒かかるかもしれないtable1にSELECTを実行する別のストアドプロシージャ（SP2）があります。実行中のSPからテーブルを取得してSQL Serverの別のSPに与える方法はありますか？
SP1の実行後、SP2はSP1が終了するまで待機する必要があります。 SP2を実行するために必要なリソース（table1から選択するようなもの）を得ることができ、SP2が完了した後、SP1に戻す方法はありますか？
SELECT WITH (NOLOCK)は、他のクエリがtable1を編集しようとしている可能性があるため使用しません。
質問に対する簡単な答えは「いいえ」です。あなたは非常に長時間実行されているSP1の中で、Table1の共有ロックを受け取り、SP2のUPDATEまたはINSERTがSP1が完了するまで待って、必要な排他ロックが取れるようにする必要がある（トランザクション/分離レベルなので、それ以降の処理に時間がかからないのはSELECTだと仮定しようとしていますが、SP1はそれ自身でUPDATEまたはINSERTを実行するかもしれません。私が集めることから、SELECTの中でSP1がロックを解除し、SP2がそのUPDATEを実行し、その後SP2がロックを解除すると、SP1がそのSELECTを続行できるようにしたいとします。私はこれがSQLのロックロジックとACIDの原則に反しているのではないかと心配しています。 SP2が（または別のプロセスが）UPDATEを実行するたびにSP1がそのSELECTを再起動する必要があり、データベースのパフォーマンスに致命的な結果をもたらす一貫した結果を確実にするために、
ストアドプロシージャ/アプリケーションの再構築を検討する必要があるようです。 SPを定期的に実行するには15分かかり、潜在的にテーブルをロックすると大きなボトルネックのように聞こえます。おそらくSP2のロジックの一部をセグメントの1つに組み込むことはできませんか？また、なぜそれほど時間がかかりますか？ SELECTの時間を短縮するために適用できる索引付けはありませんか、苦しんでいるような表/範囲ロックの種類を避けてください。
READ_COMMITTED_SNAPSHOTを見ましたか？
オンラインブックはと言う、あなたは間違いなく最初の非本番環境でそれをテストする必要があるだろうが、それがうまくいけばしかしNOLOCK
に代わるものでなければなりません：
スナップショットの正味の効果トランザクションは、トランザクションの開始時に存在していたすべてのデータを、基になるテーブルにロックを付けたり配置したりすることなく、トランザクションが参照することです。これにより、競合が発生する状況でパフォーマンスが向上する可能性があります。
それはあなたのTempDBに有害可能性がありますが、あなたはそれのためのスペースを持っている場合、それはあなたにいくつかの助けになることをここで注意点があります。
私は間違いなくそれについて最初に読んで、おそらく他のいくつかをチェックアウトanswers。
Hmmm。あなたは答えを知っていますが、あなたはそれを使いたくありません。 –
さて、もっとクリーンな方法があるかどうかを知りたい。 –
明確にするために、SP1はSP1が完了するまでSP2がテーブルから読み取ることができないような排他テーブルロックを使用しますか？そして「SP1に戻す」とはどういう意味ですか？何を返せ？ – strickt01