21

デバッグの手間を軽減する sproc を作成するための適切な方法論は何ですか? また、ストアド プロシージャをデバッグするためのツールにはどのようなものがありますか?

おそらく最も重要なことは、エラーがコードではなく sproc で発生しているという兆候は何ですか? ここで私が全面的にひどく悪くないことを願っています。上記のいずれかに対する回答に投票します。ありがとう。

なんといっても、私は .NET 環境、SQL サーバーで働いています。

4

13 に答える 13

9

SQL Server 2005 プロシージャのデバッグを (IDE やデバッガーを使用せずに) 容易にするために、ストアド プロシージャで使用する手法の 1 つを次に示します。

プロシージャーのパラメーター・リストの最後に、@Debug = 0 (デフォルトは 0 = オフ) という名前の入力パラメーターを追加します。

次に、if (@Debug = 1) print '...'; を追加します。

重要な節点でコード内のステートメントを使用して、有用な内部値などを表示します。

はい、それは「古い学校」であり、「コードをウォークスルー」できるデバッガーは素晴らしいですが、これはどの SQL ツールからでも誰にでも機能します (同じ IDE なしでデバッグする人を含む)。

ロン

于 2008-09-20T01:14:34.713 に答える
8

単純なログ出力とデバッグの両方に使用するもう 1 つの手法は、プロシージャの先頭にテーブル変数を作成することです。

   --**************************************************************************
   -- Create a log table variable to store messages to be returned to the
   -- calling application.
   --**************************************************************************
   declare @log             as table ( msg  varchar(MAX) );

then

     insert into @log values ('Inserted a new DVO Order into IRMA, order id: [' + convert(varchar(10), @@IDENTITY ) + ']');
etc.

then ...

   select msg from @log;
end

プロシージャの最後に - これは、呼び出し元のアプリケーションがプロシージャ コールからの出力をどれだけうまくログに記録するかに依存しますが、私が作成したアプリはすべてをログに記録します。:-)

于 2008-09-20T01:23:30.073 に答える
6

SQL Management Studio の組み込みツールを確認することを強くお勧めします。

私はそれについてかなり詳細なブログ記事をここに書いています：

http://www.diaryofaninja.com/blog/2010/11/23/debugging-sql-queries-function-amp-stored-procedures-with-sql-management-studio

基本的には、SQL クエリを入力してストアド プロシージャを実行し、F5 を押したり感嘆符を押したりする代わりに、再生ボタンを押して F10 と F11 を使用して、ストアド プロシージャをステップスルーしてステップインすることです。

非常に便利で、誰も使用していないようです。

于 2010-11-30T12:20:59.217 に答える
3

TSQLユニット

これは、SQL Server の単体テスト フレームワークです。正確には古典的なデバッグ ツールではありませんが、ストアド プロシージャの単体テストを記述できるため、バグの特定や予想される動作の検証に非常に役立ちます。

たとえば、ストアド プロシージャにバグがある場合は、単体テストを記述して、どのように失敗するかを理解できます。また、SQL コードに変更を加えた場合、変更によって他の部分が壊れていないことを検証したり、少なくとも問題がどこにあるかを知ることができます。

何かをテストするのが難しい場合は、ストアド プロシージャが多すぎる可能性があることを示している可能性があり、より多くのフォーカスとターゲット プロシージャに分割することでメリットが得られる可能性があります。これらのプロシージャは、長期的にはデバッグと保守が比較的容易になるはずです。

于 2008-09-20T00:54:35.073 に答える
3

さまざまな環境や手法を使用して SQL proc をデバッグすることに関する多くの提案に気付きましたが、DBFitについて言及した人はいません。FitとFitNesseに慣れていない場合は、ぜひ参考にしてください。これらの 3 つのツールを使用すると、受入テストのスイート全体をすばやく構築できます。これにより、問題なくリファクタリングできるという安心感が得られます。

DBFit は、データベースの実行に使用できる一連の Fit Fixture です。Fitness を使用すると、ストアド プロシージャに、テストを作成したいだけの数の呼び出しの順列を書き込むことができます。

これ自体はデバッグではありませんが、1 つのストアド プロシージャに対して一連のテストをすべて行うと、問題をいかに迅速に特定できるかに驚かれることでしょう。失敗したテストは問題に直接つながり、失敗した正確なコンテキストを提供するため、推測作業はありません。その上、何も壊していないことを確認するためにテストを再実行するだけでよいため、ストアド プロシージャを恐れることなくリファクタリングできます。

于 2008-09-20T02:06:38.833 に答える
2

これは個人的な好みかもしれませんが、すべてが1つの長い行にまとめられているSQLクエリを読み取るのは非常に難しいと思います。次のインデントスタイルが好きです。

SELECT
    [Fields]
FROM
    Table
WHERE
    x = x

この簡単な方法は、まったく新しいデータベーススキーマのストアドプロシージャを作成するときに非常に役立ちました。ステートメントを多くの行に分割することで、クエリのバグの原因を特定しやすくなります。たとえば、SQL Server Management Studioでは、例外の行番号が指定されているため、問題のあるコードをより迅速にターゲットにできます。

仲間の開発者に気を配ってください...800文字のSQLクエリを1行に詰め込まないでください。データベースのフィールド名またはデータ型が変更され、誰からもメールが届かない場合は、後で感謝します。

于 2008-09-23T06:53:31.143 に答える
2

ツールについては、Visual Studio を使用して SP をデバッグできます。ストアド プロシージャに長いロジックがある場合は、それをリファクタリングし、別のストアド プロシージャを作成して、メインのストアド プロシージャから呼び出すことができます。これは、テストを絞り込むのにも役立ち、クエリのどの部分が間違っているかを簡単に見つけることができます。

于 2008-09-20T00:10:44.883 に答える
1

Ron の Logging と同様に、すべての呼び出しでトレースを取得するのを支援するために、他のすべてのストアド プロシージャを介してログ プロシージャを呼び出します。特定のバッチ実行のトレースを可能にするために、全体で共通の BatchId が使用されます。おそらく最もパフォーマンスの高いプロセスではありませんが、障害を追跡するのに非常に役立ちます. 管理者に電子メールを送信するための要約レポートを作成するのも非常に簡単です。

すなわち。

Select * from LogEvent where BatchId = 'blah'

サンプルコール

EXEC LogEvent @Source='MyProc', @Type='Start'
, @Comment='Processed rows',@Value=50, @BatchId = @batchNum

メイン プロセス

CREATE PROCEDURE [dbo].[LogEvent]
    @Source varchar(50),
    @Type varchar(50),
    @Comment varchar(400),
    @Value decimal = null,
    @BatchId varchar(255) = 'BLANK'
AS

IF @BatchId = 'BLANK'
  SET @BatchId = NEWID()

  INSERT INTO dbo.Log
    (Source, EventTime, [Type], Comment, [Value],BatchId)
  VALUES
    (@Source, GETDATE(), @Type, @Comment, @Value,@BatchId)

今後は、CLR を活用して、SQL 経由で Log4Net などを呼び出すことを検討するとよいでしょう。私たちのアプリケーション コードは Log4Net を使用しているため、プロセスの SQL 側を同じインフラストラクチャに統合すると有利です。

于 2009-09-03T00:03:09.357 に答える
1

今日私に繰り返されたいくつかのアドバイスがあります。本番データベースで重要なクエリに結合を追加する場合は、結合テーブルに null フィールドがある場合でも安全であることを確認してください。

LEFT JOIN

重要なページを 20 分間破りましたが、それが私が急いで行った小さなストアド プロシージャの変更であることがわかりました。

また、変更を行うときは、必ず手順をテストしてください。これを行うには、手順のコメントに簡単なテスト クエリを挿入します。明らかに、私は今日これを行うことができませんでした:-(

/************************************
  MyProcName

  Test:
  -----
  exec MyProcName @myParam
*************************************/
于 2008-09-20T01:01:25.837 に答える
1

これはあなたが探している答えではないかもしれませんが、すでに .Net 環境にいる場合、LINQtoSQL は、私が作成/使用/デバッグする必要があるストアド プロシージャの量を大幅に削減しました。

SQL のデバッグの難しさは、LINQ でのビジネス ロジックのプログラミングが私の新しい推奨プラクティスである理由の 1 つです。

于 2008-09-20T01:29:48.903 に答える
1

SQL Server 2008 Management Studio の統合デバッガーにより、段階的なデバッグが簡単になりました (VS2005 + SQL をデバッグする方法を理解するために必要な柔道と比較してください)。

于 2008-09-20T02:09:17.547 に答える
1

私が見た成功したパターンのいくつかは、「診断」または「テスト」モードとロギングです。

テスト モードまたは診断モードは、動的 SQL 実行を行う場合に役立ちます。何を実行しようとしているのかが見えることを確認してください。エラーをチェックする必要がある (またはチェックする必要がある) 領域がある場合は、何が起こっているのかを診断できるように、十分な詳細をテーブルに記録することを検討してください。

于 2008-09-20T00:06:43.083 に答える
1

Sqlサーバーのデバッグを使用できますが、最も直接的な状況（ローカルサーバーでのデバッグなど）以外では苦痛であることがわかりました。print ステートメントよりも優れたものをまだ見つけていないので、興味を持ってこのスレッドを監視します。

于 2008-09-20T00:06:59.150 に答える