1

何が起こっているのか少し気になるかもしれませんが、確認を求めて、代替案を検討したいと思いました。

少し背景として、ストアドプロシージャに小さなフロントエンドを提供するC＃アプリケーションを作成しました。このプロシージャには、他のストアドプロシージャ（および1つのテーブル値はudf）からの一時的なテーブル挿入と、いくつかのxml処理が含まれています。

ストアドプロシージャのどこまで進んでいるかを把握するために、からInfoMessage（を使用してSqlInfoMessageEventHandler）をサブスクライブしていSqlConnectionます。SP全体のさまざまな場所に有益な印刷ステートメントを配置したので、完了した処理の感覚を把握し、それに応じてステータスバーを更新できます）。

SPの大まかな構造は、次の線に沿っています。

Print 'Beginning processing'

Create Temp Table
Insert into Temp Table from Table Valued UDF

Print 'Creating working Tables'
Create more Temp Tables
Insert into Temp Tables from SPs (each SP contains a print statement e.g 'Starting SP1').

すべてのメッセージは正常に受信および処理されますが、サーバーからメッセージが返されるまでに数秒の遅延があり、最初の数個が一度に到着します（すべてが処理されたが、出力がその間）。

私は、SP内の他の処理命令が実行される前に、最初の印刷ステートメントが返されると素朴に想定していました（DBメカニズムについて学ぶことはまだたくさんあります）。

サーバーが実行プランのフェッチやプランの再計算の可能性に関して何かをしていると思いますか、それともクエリオプティマイザーが結果が返される前に前処理を行っているのですか？

うまくいけば、私の質問はその混乱したテキストから合理的に理解できます。基本的に、クエリオプティマイザーは、プロシージャが実際に印刷ステートメントに連続して遭遇し始める前に、サーバーに選択/挿入の一部を実行させますか？

また、最初のprintステートメントの前にいくつかの小さな一時テーブル操作を実行しようとしたため、低速操作が開始される前にいくつかの行が返されましたが、結果はほとんど同じでした。

ご回答ありがとうございます。

4

2 に答える 2

2

MSSMで判断できますが、PRINTステートメントを使用すると、バッファがいっぱいになると出力が発生するため、遅延します。メッセージをすぐに出力したい場合は、以下を使用してください。

RAISERROR（'メッセージ'、0,0）WITH NOWAIT

印刷として機能しますが、すぐに出力されます。

お役に立てれば。

于 2012-10-24T11:06:44.500 に答える
0

PRINTの代わりにSELECTステートメントを使用したい-

SELECT 'Beginning processing'

Create Temp Table
Insert into Temp Table from Table Valued UDF

SELECT 'Creating working Tables'

Create more Temp Tables
Insert into Temp Tables from SPs (each SP contains a print statement e.g 'Starting SP1').
于 2012-10-24T11:27:24.137 に答える