Troubleshooting Connectivity #9 – ローカル接続でネットワーク エラーとはこれいかに?

  高橋 理香 SQL Developer Support Escalation Engineer みなさん、こんにちは。 皆さんの疑問にお答えするブログを書きたいと思い早数年、今回は時々お問い合わせされる方が声にされる「SQL Server が稼動している環境上のほかのアプリケーションやツールから接続した場合にもネットワーク エラーが発生するのはなぜ?」について、その接続の仕組みなどを説明したいと思います。 前提: ローカル接続でトランスポートネットワークエラーが発生する事象について疑問があるとはどういうこと? まず、以下の2つの図を比べてみましょう。 図1 ではクライアント マシン CLIENT01 上の SQL Server Management Studio (以降、SSMS) から物理的にネットワークの回線を介してリモート マシン SERVER01 上で動作する SQL Server に接続するイメージです。接続でエラーが発生するということは、接続のリクエストとその完了の通信経路上で遅延や障害があった場合に生ずるため、図1 のパターンにおいてネットワークに起因した問題があればネットワーク通信におけるエラーが返される可能性があるということは容易に想像できますね。 それでは図2 はいかがでしょう。サーバー マシン SERVER01 上で SSMS を起動し、同じ SERVER01 上で動作する SQL Server に接続するイメージです。この場合、物理ネットワーク回線を介さないはずです。それにもかかわらずネットワーク層のエラーが発生することがある、これが「ローカル接続なのにネットワーク エラーが発生するのはなぜ?」という疑問です。 実際にどちらの構成であっても次のようにネットワークに問題があるようにも見えるエラーが発生します。 SERVER01 に接続できません。 ADDITIONAL INFORMATION: SQL Server への接続を確立しているときにネットワーク関連またはインスタンス固有のエラーが発生しました。サーバーが見つからないかアクセスできません。インスタンス名が正しいこと、および SQL…

0

Troubleshooting Connectivitiy #8 – エラー番号からわかる接続失敗原因 :エラー26

  高橋 理香 SQL Developer Support Escalation Engineer みなさん、こんにちは。 このシリーズの前回のポストから2年半以上経過してしまいましたが、まだ書きたいこともあり、終了はしていません!今回は接続時のエラーのうち、特徴的なエラーであるエラー番号 26 と出力されている場合のトラブルシューティングについて紹介したいと思います。 A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces,…

0

トラブルシューティング手法とサポートサービス

システムで何らかのエラーが発生したという場合や、やりたいことができないといった場合に、トラブルシューティングを行うことになりますが、その際の一般的なトラブルシューティングの流れについてご紹介します。私たちサポートチームもだいたいこのようなフローの考え方をもとに調査を行っています。また、テクニカルサポートでは、インシデント単位で承っているプロフェッショナルサービスと、時間単位で承っているプレミアサービスがあります。トラブルシューティング内容に応じた、それらのサポートサービスの違いについても、参考としてご案内します。 大きく、運用でのエラー発生、開発時の How-to では考え方も異なりますので、それぞれ分けて見ていきます。 エラー発生 A) いま事象が発生しているか これは一番重要なポイントになります。いま事象が発生している場合には、すぐに対処が必要なため緊急度は高くなり、できることも多くなります。復旧優先で対処となりそうな対応をすぐに行ったり、原因調査のためにいったん情報も採取してから対処を行うといった対応があります。 一方、いま発生していないけれども、過去発生していたエラーをさかのぼって調査することもあります。この場合には、どれだけ手掛かりとなる情報が残っているかが重要です。 B)エラーメッセージやログから調査 いま事象が発生している場合には、エラーメッセージやログを確認します。 SQL Server を例にとると、既定で出力されている情報として参考になるのは、下記があります。 既定の情報 SQL Server エラーログ (ERRORLOGファイルや、同じフォルダにあるデフォルトトレースやダンプファイル等) Reporting Services ログ (ログファイルや同じフォルダにあるダンプファイル、ExcecutionLog ビュー) Analysis Services ログ (msmdsrv.logやフライトレコーダー) イベントログ その他、事象に応じて、次のような情報を採取することもあります。 追加情報 ブロッキング情報 動的管理ビュー サーバートレース 拡張イベント パフォーマンス カウンター 問題ステップ記録ツール BID トレース ネットワークトレース ダンプファイル プロフェッショナルサービス、プレミアサービスのいずれでも、これらの情報からの調査は承っています。違いとしては、下記があります。 プロフェッショナルサービス これらの情報から、対処方法を調査してご案内します。 プレミアサービス これらの情報から、対処方法を調査してご案内します。また、必要に応じて原因追及の調査も行うことが可能です。 追加情報の中でも、BIDトレース、ネットワークトレース、ダンプファイルを採取する必要がある事象については、環境依存の問題の可能性が一般的には高いと言えます。その場合にはプレミアサービスでのみ調査可能です。   C) 発生状況の切り分け 事象によっては、情報採取よりも、事象が発生するパターン、発生しないパターンを切り分けることによって、問題点が特定できる場合があります。また、発生しないパターンが確認できると、それが対処方法に直結する場合もあります。例えば、次のような切り分けがあります。 特定の環境で発生する、もしくは複数の環境で発生する 特定のクライアントで発生する、複数のクライアントで発生する 特定のユーザーで発生する、複数のユーザーで発生する…

0

[SQL Database] ”削除されたデータベース” の一覧に削除されたデータベースが存在しない

山崎 実久 SQL Server Developer/Microsoft Azure SQL Database Support 新しい Microsoft Azure Portal (https://portal.azure.com/) で利用可能な、”削除されたデータベース” に関する機能についての説明です。 ”削除されたデータベース” の一覧には、復元可能な削除されたデータベースの一覧が表示されます(図1)。 しかし、データベースを作成してから 10 分以内にデータベースを削除した場合、”削除されたデータベース” の一覧に削除されたデータベースが表示されない場合があります。 理由は、データベースが作成されてからバックアップファイルを生成し、データベースが復元可能になるまで 10 分程度時間を要するためです。 図1、 ”削除されたデータベース” に復元可能な削除されたデータベース testdb01 が表示されていることがわかります。   ※ 本ブログの内容は、2016年1月時点の情報です。

0

V12 の Azure SQL Database の sys.event_log に reconfiguration が記録されない (Document Version 1.0)

Note : 本トピックの扱いについて 本トピックは 2015/8/24 現在の最新情報であり、今後についてはアップデートを随時実施してまいります。速報としてのご案内となりますため、今後の内容が変更される場合があります。 Azure SQL Database のビュー sys.event_log は、データベースの再構成 (Reconfiguration) に関するログが出力されておりました。 しかし、アップデート後のAzure SQL Database v12 では、その結果が返されないというお問い合わせが多く寄せられております。 現時点(20/15/8/24)では、アップデート後の Azure SQL Database v12では データベースの再構成 (Reconfiguration) の発生状況を sys.event_log から、確認することが出来ません。米国開発部門とこの現象について協議した結果、以前のバージョンの Azure SQL Database と同様に Azure SQL Database v12においても sys.event_log から データベースの再構成 (Reconfiguration)の発生状況を 確認出来るよう、機能改善することの検討が進められています。 sys.event_log (SQL データベース) http://msdn.microsoft.com/ja-jp/jp-ja/library/dn270018.aspx [代替案] エラー 40613 がクライアントに返された場合、Reconfiguration である可能性が高いといえます。 SQL Azure Connection Management…

0

SQL Server 2014 SP1 適用における不具合 – Updated(解消されました)

SQL Server Support Team   2015/5/22 追記 「SQL Server 2014 SP1適用における不具合」は現在解消されています。 KB3058865 にて不具合を修正した新しいリリース(バージョン 12.0.4100.1 )がダウンロード可能です。 Microsoft® SQL Server® 2014 SP1 Microsoft® SQL Server® 2014 SP1 Express Microsoft® SQL Server® 2014 SP1 Feature Pack   このたびは弊社提供製品の不具合により、大変なご迷惑をおかけ致しましたこと、改めてお詫び申し上げます。   —– 以下は2015年4月23日時点の情報になります 2015/4/15 に SQL Server 2014 SP1 が公開されましたが、インストールにおける問題が発覚したため現在は公開を中止しております。 ※ ダウンロード可能だった時間は 11 時間程になります。 弊社提供製品の不具合により、大変なご迷惑をおかけし誠に申し訳ございません。 不具合を修正した新たな SQL Server 2014 SP1…

0

Analysis Services のデッドロックとブロッキングの確認方法

はじめに Analysis Services データベースにおいてもデッドロックやブロッキングが発生することがあり、SQL Server Profiler を使って発生状況を確認する事が可能です。 Profiler の起動方法についてはこちらをご覧下さい。SQL Server も Analysis Services も Profiler の起動方法は同じです。Profiler の接続先を Analysis Services インスタンスに指定することで、Analysis Services のトレースを取得できます。 ※Profiler を GUI で使用すると、スクリプトで取得する場合と比較して負荷が大きくなります。そのため、運用環境で情報を取得する場合は、スクリプトで取得する事をお勧めします。スクリプトでの取得方法は、[SSAS] SQL Server Analysis Services トレース採取方法 をご覧ください。 — 参考情報DO’s&DONT’s #1: やらない方がいいこと   運用環境で、Profiler GUI を使用してトレースする デッドロックの確認方法Analysis Services のデッドロックは SQL Server Profiler の Deadlock イベントで確認することができます。Deadlock イベントでは、デッドロックを検知した際に、XML の構造でその情報を取得します。どのセッションがどのオブジェクトに対してロックを獲得していて、どのセッションがそのオブジェクトへのロック獲得を待っているのかを確認することができます。 Deadlock イベントは既定で有効になっていないため、トレースのプロパティで [すべてのイベントを表示する] オプションから…

0

[SQL Database] Reconfiguration (リコンフィグレーション) は悪ではない。

皆さん、こんにちは。 SQL Server/Microsoft Azure SQL Database サポートチーム です。 今回は、Microsoft Azure SQL Database (以下 MASD) を使用するうえで、必ずお目に掛かる Reconfiguration (リコンフィグレーション) について紹介します。 New! Azure SQL Database v12 環境における既知の問題について Azure SQL Database v12 の Reconfiguration については、現在以下の問題が認識されており、以下のブログに速報をご案内しております。 V12 の Azure SQL Database の sys.event_log に reconfiguration が記録されない http://blogs.msdn.com/b/jpsql/archive/2015/08/21/v12-azure-sql-database-sys-event-log-reconfiguration-document-version-1-0.aspx 上記記事についてはアップデートを随時実施してまいります。速報としてのご案内となりますため、今後の内容が変更される場合がありますが、ご参考になれば幸いです。 [Reconfiguration (リコンフィグレーション) とは!?] Reconfiguration は、MASD 環境上の高可用性を維持するために実装された仕組みであり、ロールの変更 (セカンダリからプライマリへの昇格など) が行われる動作のことを意味します。 具体的には、以下のような場合に発生する可能性のある動作になります。   1. SQL…

0

【レプリケーション】サブスクリプション数が多いとディストリビューションエージェント(distrib.exe)が失敗することがある

  福原 宗稚 Support Escalation Engineer   最近複数のお客様から、レプリケーションについて同様の事象を報告いただくことがありました。レプリケーションモニターやエージェントのヒストリーを見ても、エージェントの起動に失敗したという記録くらいしか確認できずなかなか分かりにくい事象のため、ここでご紹介します。   問題 サブスクリプションのスナップショット適用時、もしくはその後の同期において、ディストリビューション エージェントでエラーが発生します。 SQL Server エラーログや、アプリケーションイベントログには、エラー 14151が記録されます。 エラー: 14151、重大度: 18、状態: 1。 Replication-レプリケーション ディストリビューション サブシステム: agent <job name> failed. プロセスで、テーブル ‘”dbo”.”<tablename>”‘ に一括コピーできませんでした。   特徴 下記の特徴があります。これらに合致する場合には、この問題に合致していると判断できます。 1) システム イベントログに、ディストリビューションエージェントの起動後にエラー 243が 1 回記録されます。 ログの名前:         System ソース:           Win32k イベント ID:       243 レベル:           警告 説明: デスクトップ ヒープの割り当てに失敗しました。 2) 多くのサブスクリプションを設定しています。これまでの実績としては、約300個のサブスクリプションを設定している環境で発生しています。   原因…

0

Troubleshooting Connectivity #7 – 接続タイムアウトエラーまでの時間は?

高橋 理香 SQL Developer Escalation Engineer みなさん、こんにちは。 次は接続エラーを再度・・・と予告していたのですが、今回も接続タイムアウトについての情報を書きたいと思います。 接続タイムアウト値はどこで設定するのか 前回の「Troubleshooting Connectivity #6 – 接続タイムアウトは悪なのか?」に記載したように、接続タイムアウトの設定は、接続確立完了までに要する時間として許容する限界値を定めたものであり、かつ、障害が発生しているかを見極めるための時間の設定です。したがって、接続をしようとしている側 (アプリケーションやツール等) で設定するものであり、サーバー側で設定するものではありません。たとえば、サーバーがダウンしている場合を考えてみてください。接続相手がいない状態でリクエストを行うわけですから、もしサーバー側での設定があったとしたらそれは機能できませんね。 このように、接続タイムアウト値は接続をリクエストする際にそのリクエストを行う側がその接続に要してもいい時間を設定するものですので、基本的にはアプリケーションにてその設定を行うものとお考えください。 接続タイムアウト値はどのように働くのか では、接続タイムアウト値を設定したはいいけど、指定した時間になったらちょうどでエラーになるのでしょうか。 残念ながらか、気が利いているのかは要件によるのですが、ちょうどの時間ではエラーにならないパターンがあります。 先に例にあげたサーバーがダウンしている場合がこのパターンに該当しますので、その動作について以下の2点の機能に分けて説明します。 A:    接続に使用するプロトコルの自動切り替え B:    プロトコル自体のタイムアウトおよび再転送設定 A: 接続に使用するプロトコルの自動切り替え SQL Server へアクセスするドライバーやプロバイダーの多くは、接続時には以下のように複数のプロトコルでの接続試行を行うよう設計されています。     ADO.NET の System.Data.SqlClient (.NET Framework Data Provider for SQL Server) を使用してリモートの SQL Server に接続する場合を例にすると以下の通りです。 1) TCP/IP プロトコルで接続試行する。 2) TCP/IP プロトコルによって OS レベルのセッション確立がタイムアウトした場合、名前付きパイプに切り替えて接続試行する。 3)…

0