- ハードウェアおよびソフトウェアの障害を識別し、タイムアウトを調整し、ミラーリングにおける誤検知を防止します。
- パフォーマンスを低下させるパターンを修正します: 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 を書くときによくあるエラー: 構文、順序、あいまいさ
初心者（そして初心者ではない人）のミスの多くは 構文 y SQLインジェクションデータベースがあなたの要求を理解できず、エラーを出します。ハイライトエディタは役立ちますが、よくある落とし穴を知っておくと、修正が早くなります。
スペルミス: FROM、WHERE、テーブル名、列名などのスペルミスはよくあります。メッセージは通常、 パーサーが失敗する箇所ハイライト機能と自動補完機能を備えたエディターを使用してください。キーワードがハイライトされていない場合は疑ってください。
括弧と引用符：括弧や引用符がないと、見づらい文章になってしまうので注意しましょう。 演算子の優先順位 （AND/OR）で括り、括弧で囲みます。テキストリテラルでは、文字列が分割されないように、内部の引用符をエスケープするか、シングルクォートとダブルクォートを交互に使用します（例：O'Reilly）。
SELECTの順序が無効です: 正しい順序は SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BYORDER BY句またはHAVING句の位置を変更するとエラーが発生します。覚えておくか、チートシートを用意しておきましょう。
テーブルエイリアスを無視: 自己結合の場合、または 2 つのテーブルに同じ名前の列がある場合、「あいまいな列」が生成されます。 短くてわかりやすいエイリアスを使用する alias.column で列を参照します。また、SQL の可読性も向上します。
大文字と小文字を区別する名前や特殊な名前: 大文字と小文字を区別する名前やスペースを含む名前が必要な場合は、引用符で囲む必要があります。 二重引用符 エンジンによると。これらの名前は避けるのが最善ですが、そうでない場合は、引用する際に一貫性を持たせてください。
データベース開発におけるよくある間違い
クエリの作成以外にも、中長期的に大きな違いをもたらす設計上の決定がいくつかあります。ここでは、よくある開発上のミス5つと、その対策をご紹介します。 整合性と保守性を保護する.
ストアドプロシージャの過剰な使用：ストアドプロシージャは便利ですが、ORMと最新のアクセスレイヤーでは、すべてのロジックをストアドプロシージャに置く必要はありません。ストアドプロシージャには次のようなコストがかかります。 メンテナンスとバージョン管理; 正当な理由がある場合は、アプリケーションのビジネス ロジック用ではなく、データ アクセス用の SP を作成します。
主キーは使用しないでください。ビュー、SP、またはアプリケーションに一意性を委譲すると、複雑さとエラーが増加します。定義 すべてのテーブルでリアルPK 該当する場合は一意のクエリを使用します。事後的な重複排除や脆弱なクエリを回避できます。
ソフト削除ではなくハード削除: 物理的な削除は、監査や「うっかりミス」からの回復を複雑にします。多くのユースケースでは、チェックマークが追加されます。 アクティブ/非アクティブ（ソフト削除） クエリから除外してください。物理的な削除は、制御されたパージのために残しておいてください。
既知のエラーデータベース（KEDB）：それが何であるか、そしてなぜそれがあなたにとって良い考えであるか
運用においては、すべてを即座に解決できるわけではありません。回避策は避けられません。 限られたリソース、複雑さ、継続性のニーズKEDB は、すべての既知のエラー、その原因 (ある場合)、および一時的または永続的な解決策を文書化するリポジトリです。
これはITILフレームワークの一部であり、問題管理と知識管理と関連しています。繰り返し発生するインシデントが発生した場合、チームはKEDBに相談し、 テスト済みの解像度 ゼロから始めるのではなく、ダウンタイムを削減します。
ユーザーにとってのメリット: 解決が早くなり、中断と結果が少なくなる より予測可能IT部門にとって：効率性（無駄な作業の削減）、離職率の高い状況でも知識の保持、継続的な改善のためのデータ。利害関係者にとって：透明性、情報に基づいたキャパシティ／リスクの意思決定、そしてコスト削減。
効果的なKEDBを段階的に実装する方法
1) 範囲と目標を定義する: 含まれる障害の種類(ソフトウェア、ハードウェア、ネットワーク、または特定の領域)、それらの分類方法、および追求する目標を決定します(MTTRを短縮し、満足度を向上など)。重要なシステムとサービスを優先し、ビジネス目標と SLA に合わせて範囲を調整します。
ガイドとなる質問：すべてを網羅するのか、それとも最も影響の大きいものから始めるのか？主に解決時間の短縮を目指すのか、それとも 斑点模様 予防のためですか?
2) 収集と文書化: インシデント/問題管理チームと連携して、繰り返し発生するエラーを捕捉し、 効果的な回避策 まだ書かれていない問題。説明、根本原因（既知の場合）、暫定的／最終的な解決策、影響、日付、メモなどのフィールドを備えたシンプルなテンプレートを使用してください。
ヒント: 明確な言葉遣い、実行可能な手順、役立つ評価、リンク 関連事件 ニュースがあればエントリを更新します。
3) ツールを選択する: 優れた検索機能、分類/タグ付け、要素間のリンク、拡張性、レポート機能などが必要です。 統合能力 ITSMプラットフォームと連携しましょう。導入を促進するために、ユーザーフレンドリーなインターフェースを優先し、AIを活用した検索機能やカスタマイズ可能なワークフローを検討しましょう。
4) チームをトレーニングする: 適切な文書化、効果的な検索、品質維持の方法を教えます。 実際の事例を用いた実践クイックガイド、ビデオ、メンタリング、定期的な復習など、プロセス改善のためのフィードバックを奨励します。
5) 維持と改善：責任者、KPI、レビューサイクル（重要な項目は月次、その他の項目は四半期ごと）を定義します。新規エントリのピアレビューを確立します。 継続的なドキュメント化 各問題の後に、ユーザーとサポートからのフィードバック チャネルが提供されます。
6) 使用を促進する: 社内キャンペーンを実施し、最も貢献した人を認識して使用を促進します。 地域間の連携 （ネットワーク、ソフトウェア、ハードウェア）。KEDB をサービス文化に統合し、最初に参照されるようにしましょう。
KEDBとナレッジベース（KDB）の主な違い
KEDBは、既知の障害とその解決策（一時的または永続的）に焦点を当てており、問題管理およびインシデント管理と密接に連携しています。通常、 ITSMと統合 主な対象者は、インシデントを解決する技術チームです。
KDBは、ベストプラクティス、手順、構成データ、ヘルプ記事など、より多くの情報をカバーしています。メンテナンスはより広範囲にわたり、 手順と優良事例のレビュー 技術記事に加えて、KEDBは「これが失敗したらあれをする」という機能に特化したサブセットです。
ご覧のとおり、データベースの安定性とパフォーマンスは、 物理的および論理的な障害 （そしてその検出時間）、適切なSQLの記述、賢明なモデリング、運用知識の整理。4つのパフォーマンスパターンに対処し、典型的な構文エラーを回避し、強力なPKと適切な正規化を用いて設計し、さらにライブKEDBを構築すれば、問題が発生した場合でも、より高速で予測可能で、運用しやすいプラットフォームを実現できます。
