- ハードウェアおよびソフトウェアの障害を識別し、タイムアウトを調整し、ミラーリングにおける誤検知を防止します。
- パフォーマンスを低下させるパターンを修正します: N+1、WHERE 関数、インデックスの欠落。
- SQL エラー (構文、順序、エイリアス) と不適切な設計方法 (PK、正規化) を回避します。
- 繰り返し発生するインシデントを迅速かつ透過的に解決するために KEDB を実装します。
このコースの目的は、問題が発生する原因、検出方法、そして対処方法を明確にしたロードマップを皆様に提供することです。SQL Server (ミラーリング) におけるハードウェアおよびソフトウェアのエラー、パフォーマンスを著しく低下させるパターン、よくあるクエリ作成ミス、典型的なモデリング/開発上の落とし穴、そして構造化されたキー付きエラーデータベース (KEDB) を使用して繰り返し発生するインシデントを文書化および解決するための ITIL/ITSM アプローチに関する詳細なガイドラインをご覧いただけます。
ハードウェアエラー：兆候、原因、対応時間
物理的な障害は、他のシステムコンポーネントがデータベースエンジンに警告を発するため、通常はすぐに明らかになります。このような場合、サーバーは即座にハードウェアエラーレポートを受信しますが、ネットワークやI/Oタイマーによって通知が遅れる場合もあります。
一般的な原因としては、接続不良やケーブルの損傷、ネットワークカードの故障、ルーターやファイアウォールの変更、エンドポイントの再構成、トランザクションログが格納されているドライブの消失、プロセスエラーやOSエラーなどが挙げられます。これらの問題がログディスクやネットワークに影響を与えると、接続切断からデータベースのレプリケーションやミラーリングにおける深刻な障害まで、あらゆる事態を引き起こす可能性があります。
ネットワークコンポーネントや特定のI/Oサブシステムの中には、独自の内部タイムアウトを設定しているものがあることに注意してください。これらのタイムアウトはデータベースとは独立しており、検出を遅らせ、実際の障害発生からエンジンが障害を認識するまでの間隔を長くする可能性があります。
ネットワーク上で何が起こっているかをよりよく理解するために、DNS障害、ケーブルの切断、ファイアウォールによるポートのブロック、ポートで待機しているアプリケーションのクラッシュ、サーバー名の変更、再起動といった典型的な事象発生時に、ポートにどのようなメッセージが届いているかをネットワークチームに尋ねることが有効です。こうした症状のリストがあれば、サービスが突然停止した際の診断を迅速に行うことができます。
ソフトウェアのバグとタイムアウト：いつ修正すべきか、誤検知を避ける方法
ソフトウェア障害は自ずと発生するものではないため、監視メカニズムがなければサーバーは無期限にアイドル状態のままになる可能性があります。そのため、データベースミラーリングなどのシナリオでは、インスタンスに定期的にpingを送信し、合意された時間内に信号を受信しない場合は、問題が発生したとみなされます。
これらの待ち時間を引き起こす条件には、ネットワークエラー（TCPタイムアウト、パケットの破損、紛失、または順序の誤り）、応答しないオペレーティングシステム/サーバー/データベース、Windowsレベルの有効期限切れ、およびリソース不足（ディスクまたはCPUの飽和、トランザクションログの100%使用、メモリまたはスレッドの不足）などがあります。
このような状況に陥った場合は、タイムアウト時間を長くするか、負荷を軽減するか、またはハードウェアをアップグレードして要求に対応できるようにすることができます。タイムアウト時間を短く設定しすぎると誤検知が発生し、長く設定しすぎると実際の障害への対応が遅れます。
SQL Server ミラーリングにおける ping/タイムアウト メカニズム
各接続を維持するために、各インスタンスは一定間隔でpingを送信します。タイムアウト時間（送信時間を含む）内にpingが受信された場合、通信はアクティブであるとみなされ、タイマーがリセットされます。その時間内にpingが届かない場合、タイムアウトが経過したとみなされ、接続が閉じられます。このイベントは、役割と動作モードに応じて処理されます。
相手側のサーバーが正常に動作している場合でも、タイムアウトは障害とみなされます。設定値が環境の通常のレイテンシに対して短すぎると、「架空の」エラーが発生します。そのため、10秒未満に設定しないことをお勧めします。
高性能モードでは、タイムアウトは常に10秒です。これは通常、誤検知を回避するのに十分です。高セキュリティモードでも、デフォルト値は10秒ですが、設定可能です。ネットワークが遅い場合は、このモードで10秒以上に調整してください。
変更が必要な場合は、この変更は高セキュリティセッションに特有のものであることに注意してください。バージョンとポリシーに応じて、エンジン管理画面またはT-SQLを使用して表示および変更できます。
エラー発生時のサーバーの応答方法
何らかのエラーが発生した場合、インスタンスは役割（プライマリ／ウィットネス／セカンダリ）、動作モード、および接続状態に応じて動作します。パートナーが切断された場合、動作はウィットネスを伴う高性能モードか高セキュリティモードかによって異なるため、ダウンタイムや切り替えを予測するために、各セッションの動作モードを文書化しておくことが重要です。
SQL のパフォーマンスを低下させるパターン (およびその修正方法)
レイテンシを不必要に悪化させる、非常にありがちな「過ち」が4つあります。これらは簡単に見つけることができ、避けることで初日からCPU、I/O、データベースアクセスを節約できます。
ループ内でのクエリ実行：イテレーションごとにクエリを実行する（古典的なN+1問題）と、トラフィックとレイテンシが増加します。UNIONまたはIN句を使用してデータを一度に取得するか、バッチクエリを使用してください。コード内のロジックは、既にメモリにロードされている構造体を使用して処理してください。
不要な列や行まで含めてデータを読み込むのは、大槌でナッツを割るようなものです。データベースをフィルタリングし、必要なものだけを選択し、必要に応じてページネーションを使用し、明確な理由がない限りSELECT * の使用は避けてください。
WHERE句における関数の使用：列にLOWER()、DATE()などの関数を適用すると、インデックスが使用できなくなることがよくあります。列を変換せずに比較する方が良いでしょう。つまり、データを前処理するか、リテラルを変換してください。たとえば、日付/時刻列を関数で囲まずに、日付範囲でフィルタリングします。
インデックスの欠落：フィルタリングや結合を行う列にインデックスを付け忘れると、フルスキャンを要求するようなものです。アプリケーションがフィルタリングや結合を行う箇所を定期的に確認し、適切なインデックス（必要に応じて複合インデックス）を作成してください。バランス：インデックスが多すぎると書き込み処理に悪影響を及ぼします。
SQL を書くときによくあるエラー: 構文、順序、あいまいさ
初心者（そして経験豊富なユーザーでさえも）が犯すミスのほとんどは、構文エラーとSQLインジェクションに関連しています。データベースは要求内容を理解できず、エラーを返します。テキストハイライト機能付きのエディタは役立ちますが、よくある落とし穴を知っておくことで作業効率が向上します。
スペルミス：FROM、WHERE、またはテーブル名／列名などのスペルミスはよくあることです。通常、メッセージにはパーサーがエラーを起こしている箇所が示されます。ハイライト表示とオートコンプリート機能のあるエディタを使用してください。キーワードがハイライト表示されない場合は、疑わしい箇所がある可能性があります。
括弧と引用符：括弧や引用符が欠けていると、見づらい問題が生じます。演算子の優先順位（AND/OR）に注意し、括弧でテキストをグループ化してください。テキストリテラルでは、文字列が途切れないように、内部の引用符をエスケープするか、シングルクォーテーションとダブルクォーテーションを交互に使用してください（例：O'Reilly）。
SELECT句の順序が間違っています。正しい順序は、SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BYです。ORDER BY句またはHAVING句の順序を変更するとエラーが発生します。この順序を覚えておくか、カンニングペーパーを手元に置いておきましょう。
テーブルエイリアスは省略してください。自己結合の場合や、2つのテーブルに同じ名前の列がある場合、「あいまいな列」エラーが発生します。短く分かりやすいエイリアスを使用し、列は`alias.column`の形式で参照してください。これにより、SQLの可読性も向上します。
大文字小文字を区別する名前や特殊な名前：どうしても大文字小文字を区別する名前やスペースを区別する名前を使用したい場合は、検索エンジンに応じて二重引用符で囲む必要があります。これらの名前は避けるのが最善ですが、どうしても使用する場合は、引用する際に一貫性を保つようにしてください。
データベース開発におけるよくある間違い
クエリの作成以外にも、中長期的に大きな違いを生む設計上の決定事項があります。ここでは、よくある開発上のミスを5つ挙げ、整合性と保守性を守るために代わりに何をすべきかを説明します。
ストアドプロシージャの過剰使用：ストアドプロシージャは便利ですが、最新のORMやアクセスレイヤーを使えば、すべてのロジックをストアドプロシージャに記述する必要はありません。ストアドプロシージャには保守とバージョン管理のコストがかかります。データアクセスが必要な場合にのみストアドプロシージャを作成し、アプリケーションのビジネスロジックには使用しないでください。
主キーの使用は避けてください。一意性をビュー、ストアドプロシージャ、またはアプリケーションに委ねると、複雑さとエラーが増加します。すべてのテーブルで真の主キーを定義し、適切な箇所で一意キーを使用してください。これにより、重複排除後の処理や脆弱なクエリを防ぐことができます。
ソフト削除ではなくハード削除：データの物理的な削除は、監査や「うっかりミス」からの復旧を複雑にします。多くのユースケースでは、アクティブ/非アクティブ（ソフト削除）フラグを追加し、クエリから除外してください。物理的な削除は、管理されたクリーンアップのために残しておきましょう。
既知のエラーデータベース（KEDB）：それが何であるか、そしてなぜそれがあなたにとって良い考えであるか
運用においては、すべての問題を即座に解決できるとは限りません。限られたリソース、複雑な状況、あるいは事業継続の必要性などから、一時的な解決策（回避策）は避けられません。KEDBは、既知のエラー、その原因（存在する場合）、そして一時的または恒久的な解決策をすべて文書化するリポジトリです。
これはITILフレームワークの一部であり、問題管理および知識管理と関連しています。繰り返し発生するインシデントが発生した場合、チームはKEDBを参照し、実績のあるソリューションを適用することで、ゼロからやり直すのではなく、ダウンタイムを短縮できます。
ユーザーにとってのメリット：問題解決の迅速化、中断の減少、結果の予測可能性の向上。IT部門にとってのメリット：効率性の向上（ゼロからやり直す必要がない）、人材の入れ替わりがあっても知識が保持されること、継続的な改善のためのデータが得られること。ステークホルダーにとってのメリット：透明性の向上、情報に基づいたキャパシティ／リスク判断、コスト削減。
効果的なKEDBを段階的に実装する方法
1) 範囲と目標を定義する：どの障害（ソフトウェア、ハードウェア、ネットワーク、または特定の領域）を含めるか、それらをどのように分類するか、そしてどのような目標（MTTRの短縮、顧客満足度の向上など）を追求するかを決定します。重要なシステムとサービスに優先順位を付け、範囲をビジネス目標とSLAに合わせます。
指針となる質問：すべてを網羅するのか、それとも最も影響力の大きい問題から始めるのか？解決時間の短縮を主な目的とするのか、それとも予防策のためのパターン検出も目的とするのか？
2) 収集と文書化：インシデント／問題管理チームと連携し、まだ文書化されていない繰り返し発生するエラーと効果的な回避策を収集します。説明、根本原因（既知の場合）、一時的／恒久的な解決策、影響、日付、メモなどの項目を含むシンプルなテンプレートを使用します。
ヒント：分かりやすい言葉遣い、実行可能な手順、役立つ分類、関連する出来事のリンク、そして新たな展開があった場合のエントリの更新。
3）ツールの選択：優れた検索機能、分類／タグ付け機能、アイテム間のリンク機能、拡張性、レポート機能、そしてITSMプラットフォームとの統合機能が必要です。導入を促進するために、ユーザーフレンドリーなインターフェースを優先し、AIを活用した検索機能やカスタマイズ可能なワークフローを検討してください。
4）チームのトレーニング：効果的な文書作成方法、効率的な検索方法、品質維持方法を教えます。実際の事例を用いた実践的な演習、クイックガイド、ビデオ、メンター制度、定期的な復習コースなどを活用します。プロセス改善のためにフィードバックを積極的に求めます。
5）維持と改善：責任範囲、KPI、およびレビューサイクル（重要な問題については月次、その他すべてについては四半期ごと）を定義します。新規エントリのピアレビュー、各問題発生後の継続的なドキュメント作成、およびユーザーとサポートからのフィードバックチャネルを確立します。
6）利用促進：社内キャンペーンを実施し、最も貢献度の高いユーザーを表彰し、部門間（ネットワーク、ソフトウェア、ハードウェア）の連携を促進する。KEDBをサービス文化に組み込み、ユーザーが最初に参照する場所となるようにする。
KEDBとナレッジベース（KDB）の主な違い
KEDBは、既知の障害とその解決策（一時的なものか恒久的なものかを問わず）に焦点を当てており、問題管理およびインシデント管理と密接に連携しています。通常はITSMと統合されており、主な対象者はインシデント解決を担当する技術チームです。
KEDBは、ベストプラクティス、手順、構成データ、ヘルプ記事など、はるかに多くの情報を網羅しています。そのメンテナンスはより広範囲にわたり、技術記事に加えて手順やベストプラクティスの改訂も含まれます。つまり、KEDBは「これが失敗したら、別のことをする」という一連の手順を専門的にまとめたものです。
ご覧のとおり、データベースの安定性とパフォーマンスは、適切なSQLの記述、インテリジェントなモデリング、運用知識の整理だけでなく、物理的および論理的な障害（とその検出時間）を理解することにも大きく依存します。4つのパフォーマンスパターンを修正し、典型的な構文エラーを回避し、強力な主キーと適切な正規化を用いて設計し、さらにライブデータベース管理システム（KEDB）をセットアップすれば、問題が発生した場合でも、より高速で予測可能、かつ操作しやすいプラットフォームを実現できます。
