Microsoft SQL Server 2000 のベスト プラクティス アナライザ ツールは、Microsoft SQL Server 開発チームによって開発されたデータベース管理ツールで、設計されたデータベースが SQL Server の運用と管理のベスト プラクティス ガイドラインに従っているかどうかを検出できます。これらのガイドラインは、データベースのパフォーマンスと効率を向上させ、アプリケーションの保守を容易にするのに役立つと認識されています。
2. SQL BPA ベスト プラクティス アナライザーの使用を開始します。
インストール
が完了すると、SQL Server ベスト プラクティス アナライザー ユーザー ガイドの基本的な手順がわかりやすく説明されています。
SQL BPA に入力
(2) 分析/検出された SQL Server インスタンスを追加します
。ここで SQL Server インスタンス名を入力する必要があります。フレンドリ名は、後で作成するベスト プラクティス グループに関連付けるために使用されます (SQL Server インスタンス名と同じにしておきます)。 ）。 Database List のデフォルト値は * で、現在の SQL Server インスタンスのすべてのデータベースが含まれていることを意味します。ただし、BPA は、「master」、「tempdb」、「msdb」、「pubs」、「northwind」などのデータベースの検出をスキップします。
(3) ベスト プラクティス グループを管理するには、
まずベスト プラクティス グループを作成する必要があります。このグループは、実際にいくつかのルールを組み合わせて、前に入力した SQL Server インスタンスに関連付けます。
(4) SQL Server インスタンスを分析し
、以前に作成したベスト プラクティス グループを [実行するベスト プラクティス グループ] リストに移動します。これにより、以前に定義されたルールに従ってグループが実行され、改善のための提案とガイドラインを提供するレポートが生成されます。
3. SQL BPA v1.0 に含まれるルール
が重要なポイントだと思います。SQL Server の運用と管理に関するこれらのベスト プラクティス ガイドラインを理解することによってのみ、データベースの設計や T-SQL スクリプトの作成時にこれらのルールに従うことができるからです。 SQL Server とアプリケーションのパフォーマンスと効率を向上させます。
実際、すべてのルールはここにあります (英語版) file:///C:/Program%20Files/Microsoft%20SQL%20Server%20Best%20Practices%20Analyzer/html/RuleInformation.html#_Rule:_Explicit_Index_Creation 。 use SQL BPA はデフォルトのパスにインストールされます。インストール パスを変更すると、ここにはインストールされなくなります。
私が興味のあるルールをいくつか示します。
(1) データベース設計
ルール: 主キーまたは一意制約のないテーブル
データベースをチェックして、すべてのテーブルに主キーが定義されているか、列に一意制約が定義されていることを確認します。
ルール: ユーザー オブジェクトの名前付け (ユーザー オブジェクトの名前付け) は
、SQL Server の組み込みオブジェクトとの名前の競合を避けるために、接頭辞 sp_、xp_、または fn_ が付いた名前のユーザー オブジェクトを検出します。 SQL Server は、ストアド プロシージャに sp_ というプレフィックスが付いていることを検出すると、最初に master データベース内のストアド プロシージャをクエリします。これはパフォーマンスに影響します。
したがって、次のガイドラインに従う必要があります。
ユーザー定義ストアド プロシージャの名前に sp_ 接頭辞を使用しないで
ください。 ユーザー定義拡張ストアド プロシージャの名前に xp_ 接頭辞を使用しないでください。
ユーザー定義関数の名前に fn_ 接頭辞を使用しないでください。 。
実際、usp_、uxp_、ufn_ などの接頭辞を使用して名前を付けることができます。u はユーザー定義を意味します。
(2) T-SQL
ルール: カーソル FOR UPDATE 列リストは、
ストアド プロシージャ、関数、ビュー、およびトリガー内の FOR UPDATE 句を検出します。カーソルで FOR UPDATE 句を定義する場合は、明示的に列を指定することをお勧めします。 FOR UPDATE は、カーソル内の更新可能な列を定義するために使用されます。 OF column_name が指定された場合、リストされた列のみが変更できます。列のリストが指定されていない場合は、READ_ONLY 同時実行オプションが指定されていない限り、すべての列を更新できます。 SQL Server は、指定された列に基づいて操作を最適化できます。
ルール: カーソルの使用法は、
カーソルの更新可能性がストアド プロシージャ、関数、ビュー、およびトリガーで正しく定義されているかどうかをチェックします。
カーソルが FOR UPDATE 句を定義していないが、カーソルによって更新されている場合、
カーソルが FOR UPDATE 句を定義しているが、カーソルによって更新されていない場合、失敗が報告されます
。
ただし、サーバー側カーソルはサーバーのメモリ リソースを占有し、SQL Server のパフォーマンスに影響を与えるため、通常はサーバー側カーソルの使用を避けるよう努めます。カーソルの代わりに、ネストされたクエリまたは WHILE ステートメントを使用できます。カーソルを使用する場合でも、FAST_FORWARD などのカーソルのいくつかのオプションの定義に注意する必要があります。
ルール: 明示的なインデックス作成
インデックスを明示的に作成するには、CLUSTERED または NONCLUSTERED を使用することをお勧めします。
ルール: INSERT 列リストで
は、INSERT を使用する場合、コードの保守性を向上させるために列リストを明示的に指定する必要があります。
ルール: ネストされたトリガーの構成は、
ネストされたトリガーの構成の問題によりトリガーされないトリガーを検出します。これは比較的珍しいので、直接投稿しました。
「ネストされたトリガー」構成オプションが 0 に設定されている場合、INSTEAD OF トリガー内で更新されたテーブル/ビューに定義されている AFTER トリガーは起動されません。
1) 構成オプションの値を確認し、0 でない場合は終了します。
2) すべての INSTEAD OF トリガーをスキャンし、トリガー内から DML のターゲットであるテーブル/ビューのリストを生成します。
3
) 特定された DML ターゲットに AFTER トリガーが定義されているかどうかを確認します。
場合。
ルール: トリガーの NOCOUNT オプションは
トリガーを検出し、トリガーの前に SET NOCOUNT ON が書き込まれるようにします。
SQL Server は、各ステートメントが実行された後に「完了」メッセージを送信します。この情報により、トリガーをトリガーするアプリケーションに予期しない結果が生じる可能性があります。したがって、トリガーの前に SET NOCOUNT ON を追加することは、設計上の良い習慣です。
もちろん、ストアド プロシージャや関数の前に SET NOCOUNT ON を追加することをお勧めします。こうすることで、一連の SQL コマンドの実行によって影響を受ける行数がクライアントに送信されなくなり、ネットワーク トラフィックが削減され、パフォーマンスが向上します。
ルール: NULL 比較は、
ストアド プロシージャ、関数、ビュー、トリガー内の NULL 定数を含む等価または不等比較を検出します。 ANSI_NULLS を ON に設定し、IS キーワードを使用して NULL 定数を比較することをお勧めします。
ルール: トリガーの結果はトリガー
をチェックして、トリガーが呼び出し元にデータを返していないことを確認します。したがって、トリガーで次のステートメントを使用することはお勧めできません。
PRINT ステートメント
SELECT (代入または INTO 句なし)
FETCH (代入なし)
ルール: トランザクションのスコープは、
ストアド プロシージャとトリガーのトランザクション範囲を検出します。トランザクションの開始と終了は同じ T-SQL 構造内にあることが推奨されます。
一般に、多くのリソースを消費して SQL Server のパフォーマンスに影響を与えることを避けるために、トランザクションの範囲をできる限り狭めるようにしてください。
ルール: SELECT * は、
ストアド プロシージャ、関数、ビュー、トリガーでの SELECT * の使用を検出します。 SELECT * の方が便利ですが、プログラムの保守性が低下します。テーブルまたはビューを変更すると、エラーやパフォーマンスの変化が発生する可能性があります。
したがって、SELECT ステートメントの後にフィールド リストを明示的に指定することをお勧めします。
ルール: SET オプションは、
ストアド プロシージャおよびトリガーでの次の SET ステートメントの使用を検出します。
次のオプションを ON に設定することをお勧めします:
ANSI_NULLS
ANSI_PADDING
ANSI_警告
アリサボート
CONCAT_NULL_YIELDS_NULL
QUOTED_IDENTIFIER では、
次のオプションを OFF に設定することをお勧めします。
NUMERIC_ROUNDABOUT
ルール: 一時テーブルの使用法は、
ストアド プロシージャおよびトリガーでの一時テーブルの使用を検出します。一時テーブルを作成する場合は、CREATE INDEXを作成し、使用終了後に一時テーブルを解放する必要があります。
一時テーブルでは大量のディスク IO 操作が生成されるため、一時テーブルの使用の代わりに TABLE 変数を使用することをお勧めします。
ただし、同時実行と統計情報の保守に制限があるため、大量のデータを一時テーブルに挿入する場合は、引き続き一時テーブルを使用することをお勧めします。
ルール: ORDER BY を使用しない TOP は、
ストアド プロシージャ、関数、ビュー、トリガーに ORDER BY TOP ステートメントがないことを検出します。 TOP文を使用する場合は、ソート条件を指定することをお勧めします。そうしないと、生成される結果が SQL 実行プランに依存し、予期しない動作が発生する可能性があります。
ルール: スキーマ修飾されたテーブル/ビューの使用は、ストアド
プロシージャ、関数、ビュー、トリガーでテーブルとビューが参照されるときに所有者が指定されているかどうかを検出します。 SQL Server で特定のオブジェクトを参照する場合、サーバー、データベース、所有者 (スキーマ) を指定する必要はありません。つまり、server_name.database_name.owner_name.*** のような手間は必要ありませんが、SQL Server では次のことを推奨しています。ストアド プロシージャ、関数で使用されます。ビューまたはトリガーでテーブルまたはビューを参照する場合は、テーブルまたはビューの所有者を指定するのが最善です。
SQL Server が所有者を指定せずにテーブル/ビュー オブジェクトをクエリする場合、最初にデフォルトの所有者をクエリし、次に dbo をクエリします。これにより、SQL Server 製品の追加の運用コストが発生します。所有者を指定すると、SQL Server のパフォーマンスを向上させることができます。 (この発言初めて聞きました)
4. 参考ドキュメントおよび関連リソース
ツールのダウンロード URL:
ビデオのダウンロード URL: