適用対象:
SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsMicrosoft Fabric SQL Database
この記事を使って、OLE DB操作の失敗段階を特定し、次のチェックを選択し、詳細なトラブルシューティング手順を見つけてください。 このガイダンスは現在の提供者である MSOLEDBSQL19を使用しています。 リリース固有の欠陥やアップグレードの変更については 、「既知の問題 および 主要なバージョンの違い」を参照してください。
症状を特定する
設定を変更する前に、完全なエラー説明と利用可能なエラーレコードをすべて取得してください。
DB_E_ERRORSOCCURREDのようなトップレベルのHRESULTだけでは原因を特定することはできません。 プロバイダーの読み込み、接続を開く、コマンドの実行、データの取得、トランザクションのコミット時に失敗が発生したかどうかを記録します。
| 症状: | ここから始める |
|---|---|
| 提供者が見つからなかったり、クラスが登録されていないこともあります。 | プロバイダー登録とアーキテクチャ |
| ログイン失敗、アクセス拒否、統合認証失敗などです。 | ログインおよび認証の失敗 |
| 証明書チェーンが信頼されていないか、証明書名が一致しないことがあります。 | TLS証明書の失敗 |
| サーバーやインスタンスが見つからなかったり、接続が拒否されたりします。 | ネットワークおよびインスタンスのディスカバリー障害 |
| パラメータが失敗したり、値が切り詰められたり、データを変換できなかったりします。 | パラメータおよびデータ変換エラー |
| 接続が切断されたり、復旧が失敗したり、タイムアウトが切れたりします。 | 接続喪失とタイムアウト |
| エラーの詳細が欠けているか、サポートのためにトレースが必要な場合もあります。 | 診断とトレース |
接続障害については、アプリケーションを ユニバーサルデータリンク(UDL)接続テストと比較してください。 同じコンピュータ、プロバイダー、プロセスアーキテクチャ、認証識別、サーバー、データベース、暗号化設定を使いましょう。 異なるプロバイダーやアイデンティティでのテストが成功しても、アプリケーションの構成が正常に動作しているとは限りません。
プロバイダー登録とアーキテクチャ
「プロバイダーが見つからない」や「REGDB_E_CLASSNOTREG(0x80040154、クラス未登録)」などのエラーは、認証前のプロバイダーロードSQL Server示します。
- 申請で求められるプロバイダーを確認してください。
MSOLEDBSQL19そしてMSOLEDBSQL異なるメジャーバージョンを識別します。 現在のドライバーをインストールしても、アプリケーションのプロバイダー選択は変わりません。 もしアプリケーションが別のプロバイダーを要求し続けた場合は 、移行手順 に従ってください。 - アプリケーションをホストするプロセスのアーキテクチャを確認してください。 32ビットアプリケーションは64ビットWindowsでも32ビットプロバイダーを必要とします。 サービスやスケジュールジョブの場合は、開発環境だけでなく、そのホストが使っている実行ファイルとアカウントを確認してください。
- アプリケーションを動かしているコンピュータで、対応しているインストーラーを使ってドライバーをインストールするか修復してください。 x64インストーラーには64ビットと32ビットのドライバーバイナリの両方が含まれています。 「 Install the OLE DBドライバ と システム要件」で必要な依存関係を確認してください。 インストールの代わりに他のコンピュータからドライバーライブラリをコピーしないでください。
- マッチングアーキテクチャとプロバイダーでUDLテストを繰り返します。 動作してもアプリケーションがプロバイダーを読み込めない場合は、実際のプロバイダ選択やホストアーキテクチャをテストと比較してください。
エラーがadal.dllを明確に指定する場合は、既知の認証ライブラリの問題を確認し、欠損したSQL Serverプロバイダーとして扱うのではなく確認してください。
ログインおよび認証の失敗
サーバーのログイン拒否と、認証情報取得や暗号化接続の確立失敗を区別してください。 リスト化されたプロバイダーエラーを含め、全文のエラーテキストをお読みください。
- SQL Serverエラー18456の場合は、データベース管理者に対応するサーバーエラーのログエントリと状態を確認するよう依頼してください。 認証モード、ログイン状況、リクエストしたデータベース、 MSSQLSERVER_18456を使ってデータベースアクセスを確認してください。 すべてのログイン拒否がパスワードの誤りだと決めつけないでください。
- 統合認証の場合は、アプリケーションが動作する識別元を確認してください。 サービスアカウントやスケジュールタスクアカウントは、接続を成功裏にテストしたユーザーとは異なる場合があります。 メッセージに 「SSPIコンテキストを生成できません」が含まれている場合は、 セキュリティサポートプロバイダーインターフェース(SSPI) トラブルシューティングおよび サービスプリンシパル名(SPN)サポートに従ってください。
- Microsoft Entra IDについては、選択した認証方法がアプリケーションの実行環境に適合し、そのアイデンティティがターゲットデータベースにアクセスできるかを確認してください。 「Use Microsoft Entra ID」のメソッド固有の設定やアクセストークンの制限を確認してください。 認証や認証情報の性質が競合するアクセストークンを組み合わせないでください。
- 有効な設定と正しい接続文字列キーワードテーブルを比較してください。
IDBInitialize::Initialize、IDataInitialize::GetDataSource、およびActiveXデータオブジェクト(ADO)は異なるキーワードテーブルを使用します。 表でアプリケーションが使っているインターフェースを確認してください。
対象のプリンシパル名が正しくありません というテキストは、さまざまな状況で表示されることがあります。 もしそれが「SSPIコンテキストを生成できない」といった場合は、Windows 認証やSPNについて調べてください。 もしエラーが証明書や暗号化ハンドシェイクを識別している場合は、次のセクションをご利用ください。
TLS証明書の失敗
トランスポート層セキュリティ(TLS)エラーは、ログインがSQL Serverに到達する前に発生することがあります。 現在のドライバーはデフォルトで強制暗号化を有効にしているため、アップグレードによって古い接続設定では検出されなかった証明書の信頼や名前の問題が明らかになることがあります。
- 証明書チェーンが信頼されていない権威によって発行された場合、SQL Serverが提示する証明書とクライアントコンピュータが信頼する発行証明書チェーンを確認してください。 有効なサーバー証明書を設定し、組織の証明書管理プロセスを通じて必要な信頼済みルート証明書および中間証明書をインストールしてください。
- 証明書名の不一致がある場合は、アプリケーションが使用するサーバー名やリスナー名と証明書内の名前を比較してください。 目的の接続名をカバーする証明書を使用してください。 アプリケーションが意図的に異なる接続名を使用している場合は、期待される証明書名を設定する前に、文書化された HostNameInCertificateプロパティ を確認してください。
- 有効な暗号化や検証設定、 レジストリ設定も確認してください。
暗号化および証明書検証テーブルで優先順位や動作を確認し
Strict。Strictモードでは、ドライバーは信頼サーバー証明書の設定に関係なく証明書を検証します。 - もし移行中に故障が始まった場合は、暗号化プロパティの価値タイプや
Strictモード外でのServerCertificate使用制限など、メジャーバージョンのトラブルシューティングを確認してください。
詳細なチェックにはSQL Serverの証明書要件と信頼されていない証明書チェーンのトラブルシューティングを使いましょう。 本番環境では暗号化と証明書検証を有効にしておきましょう。 どちらかを無効にしても証明書の展開問題は解決しません。
ネットワークおよびインスタンスのディスカバリー障害
サーバーが見つからない場合、サーバー/インスタンスの位置特定エラー、または接続拒否エラーは、アプリケーションが到達しようとしているエンドポイントを特定します。
- サーバー名、インスタンス名、設定済みのリスニングポートをデータベース管理者と確認してください。 データベースサービスが実行中で、意図したプロトコルとリスナーが有効になっているかを確認します。 すべてのインスタンスがポート1433を聞いていると決めつけないでください。
- リモートの伝送制御プロトコル(TCP)接続の場合、ドライバーの
tcp:<server>,<port>サーバー名形式を使って既知のエンドポイントをテストします。 認証、データベース、暗号化設定は同じままにしてください。 インターフェースに適用されるサーバーキーワードについては 、接続文字列キーワード を参照してください。 - 明示的なホストとポートは動作するのに、名前付きインスタンスが動作しない場合は、SQL Serverブラウザとインスタンスの検出を調査してください。 ブラウザサービスおよびブラウザディスカバリーが使われているユーザーデータグラムプロトコル(UDP)ポート1434パスを確認してください。
- 明示的なエンドポイントも失敗した場合は、ドメインネームシステム(DNS)の解決、ルーティング、アプリケーションホストからの実際のリスニングポートへのファイアウォールアクセスを確認してください。 複数の接続設定を一度に変更するのではなく、 ネットワーク関連またはインスタンス固有の接続エラー に従うことが重要です。
可用性グループリスナーについては、 高可用性および災害復旧サポートも確認してください。 LocalDBの場合は、リモートTCPディスカバリーステップを適用する代わりに、ローカルインスタンスとユーザーのコンテキストを確認するために LocalDBサポート を利用しましょう。
パラメータおよびデータ変換エラー
接続は開いてもコマンド実行やデータ取得に失敗した場合は、複製を失敗したコマンドと値に減らします。 機密データを置き換える際は、元のデータ型、長さ、ヌル状態、文字エンコーディングを保持してください。
- 各
?パラメータマーカーを、その結合順序数、方向、メタデータと比較します。ICommandWithParameters::SetParameterInfoを使う場合は、SQLのソースタイプをコマンドやストアドプロシージャに合わせてください。 パラメータメタデータが常に自動で導出されるとは思わないでください。 導出制限や出力パラメータの挙動についてコマンド パラメータ を確認しましょう。 - 全体の
HRESULTバインディングだけでなく、アクセス器のバインディングステータスや各返された値のステータスや長さを検査してください。 プロパティ設定の失敗については、各プロパティのdwStatusを点検してください。DB_S_ERRORSOCCURREDのような部分的成功リターンは、エラーオブジェクトがなくてもステータス配列検査が必要になることがあります。 戻りコードを参照してください。 - 変換や切断については、消費者バッファの種類とサイズを実際の列やパラメータメタデータと比較してください。 数値値は精度とスケール、日付・時刻の有効範囲と分数秒、文字バッファのバイト長をチェックしましょう。
DBSTATUS_E_CANTCONVERTVALUEを調査し、DBSTATUS_S_TRUNCATEDを完全な値として扱わないでください。 適用されるルールには データ型マッピング、 行の取得、 日付と時間の変換 を活用してください。 - バウンドされた出力パラメータが欠落している場合は、読み取る前に返された行セットを使い尽くしてください。 複数の結果セットを処理するにはIMultipleResultsをご利用ください。 ストリーム出力パラメーターについては、出力パラメーターのストリーミングのサポートで説明されているように、次の結果を要求する前に、保留中のストリームを消費または解放してください。
ADO固有のマッピングについては、OLE DBドライバを使ったADOの使用およびUse Microsoft Entra IDのDataTypeCompatibility認証制限を確認してください。 互換性設定を追加する際には両方確認してください。
ドライバーアップグレード後の sql_variant 列で破損した細い文字列については、保存データを変更する前に既存の SSVARIANT既知の問題と回復手順 を確認してください。
接続喪失とタイムアウト
最後に接続が動作した時期、失敗した操作、そしてその操作がどれくらいの時間続いたかを記録してください。 リトライやタイムアウト設定を変更する前に、これらのケースを区別してください。
| 失敗期 | チェックと詳細なガイダンス |
|---|---|
| 接続を開く。 | まずプロバイダー、ネットワーク、認証、TLSのエラーを確認してください。 有効 DBPROP_INIT_TIMEOUT または対応する接続キーワードを確認してください。 接続 タイムアウトのトラブルシューティングを参照してください。 |
| コマンドの実行。 |
DBPROP_COMMANDTIMEOUTかアプリケーションのコマンドタイムアウト設定を確認してください。
Query Timeoutのトラブルシューティングでブロッキングやクエリのパフォーマンスを調査しましょう。 接続タイムアウトを増やしてもコマンドのタイムアウトは変わりません。 |
| アイドル接続の再利用。 | 復旧条件、再試行設定、 アイドル接続のレジリエンシーの予想エラーを確認してください。 再接続が完了する前にコマンドのタイムアウトが切れると、回復が失敗することがあります。 |
| 実行やコミット中に接続が失われること。 | クライアントとサーバーのイベントを関連付けて、ネットワークの中断、サーバーの再起動、フェイルオーバーの有無をチェックします。 再挑戦の安全かどうかを判断する前に、手術の結果を把握してください。 |
アイドル接続の回復力は初期接続の再試行や任意のコマンドやトランザクションの自動再生を提供しません。 一時的な障害が確認された場合は、遅延付きのバウンデッドアプリケーション再試行を使い、各試行をログに記録します。 プロバイダーの読み込みエラー、認証情報の拒否、証明書検証の失敗を原因を修正せずに繰り返し試行しないでください。
Caution
書き込みやコミット中に接続が切断された場合、クライアントはSQL Serverがトランザクションをコミットしたかどうかを知らないことがあります。 作戦を盲目的に繰り返してはいけません。 結果を確認するか、重複効果を防ぐアプリケーションデザインを使い、再挑戦してください。
診断とトレース
エラー情報が無関係なプロバイダーの呼び出しに置き換えられる前に、故障点で診断を収集してください。
- 失敗した操作、タイムスタンプとタイムゾーン、経過時間、
HRESULTを記録します。 ネイティブのOLE DB利用者にとっては、最初の記述だけでなく、IErrorInfoやIErrorRecordsを通じて利用可能なすべてのレコードを取得してください。SQLSTATEとISQLErrorInfoで入手可能な場合は、ネイティブSQL Serverエラー番号を含めてください。 エラー情報の取得およびSQL Serverのエラー詳細を参照してください。 ADOの場合は、接続のErrorsコレクションをキャプチャしてください。 - エラーを報告するメソッドのプロパティごと、バインディングごとのステータス、値ごとのステータスを収集します。 エラーオブジェクトが存在しないからといって、部分成功の結果を無視してよいことにはなりません。
- クライアントの失敗とサーバーエラーログや拡張イベントを関連付けます。 利用できる場合は、
ClientConnectionIDとActivityIDを記録してください。 事前ログイン前の失敗はクライアント接続識別子なしで発生することがあります。 - エラー記録が不十分な場合は、 拡張イベントログのAccess診断情報を 使い、ドライバーの追跡や相関設定を行ってください。 再現時の範囲を限定したトレースを収集し、その後トレースを停止します。
エスカレーション時には、ドライバーバージョン、要求されたプロバイダー、アプリケーションおよびプロセスアーキテクチャ、サーバーバージョン、認証方法、有効な接続設定、障害段階、エラー記録、そして最小限の再現を含めてください。 マッチングされたUDLテストが成功したかどうか、また問題が1つのホストに影響するのか複数のホストに影響しているのかを明記してください。
接続設定やログからパスワード、アクセストークン、その他の秘密を削除してください。 クエリテキストや機密データの痕跡を確認し、制限されたアクセスで保存し、承認されたサポートチャネルを通じてのみ共有してください。