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

照合順序 – 文字の比較と並び順 (その 2)

神谷 雅紀Escalation Engineer   照合順序 – 文字の比較と並び順 (その 1) では照合順序とは何かを書きました。今回は、照合順序に関わるいくつかの注意点について書きます。     照合順序の衝突   異なる照合順序が指定されている列同士は、比較することができません。 以下は、その簡単なサンプルです。   use mastergodrop database ja_90_bin2go— 照合順序 japanese_90_bin2 のデータベースを作成create database ja_90_bin2 collate japanese_90_bin2gouse ja_90_bin2go— 照合順序 japanese_90_bin2 のデータベースに japanese_90_ci_as と japanese_90_cs_as の列を持つテーブルを作成create table dbo.ja_90_cias (c1 int, c2 nvarchar(10) collate japanese_90_ci_as)create table dbo.ja_90_csas (c1 int, c2 nvarchar(10) collate japanese_90_cs_as)go— japanese_90_ci_as と japanese_90_cs_as…

0

照合順序 – 文字の比較と並び順 (その 1)

神谷 雅紀Escalation Engineer 照合順序が分かりにくいという意見がありましたので、今回は照合順序を取り上げます。        照合順序とは何か SQL Server では、文字の大小関係を比較する場合の基準を照合順序 (collation) と呼んでいます。例えば、「朝」と「海」ではどちらが大きいのか、「あ」「ア」「ア」を大きい順に並べた場合どのように並ぶのかといった、文字の大小関係を決めているのが照合順序です。 言語としての日本語の観点では、「朝」と「海」のどちらが大きくても、さほど問題にはならないように思えるかもしれません。しかし、もしこれらの文字に大小関係がなかったら、データを大きい順に並べても毎回違った並び順になる可能性があります。さらに、もしこれらの文字に大小関係がなかったら、大きくも小さくもないということになります。大きくも小さくもないということは、   if (a < b) …else if (a > b) …else …   の式で最後の else に入るということであり、そこに入るのは a = b の場合だけです。つまり、等しいということです。「朝」と「海」が等しいとなると、それは言語としての日本語でも問題となってきます。 このように、照合順序 (文字の大小関係) は、データを扱う処理にとっては、重要な要素です。 照合順序はどのような場面で使われるのか 文字の比較を行うすべての場面で使われます。 例えば、インデックスを作成する際には、キー列の値順にインデックス行を並び替えるために使われます。select … from … order by Col1 のようなクエリでデータを並び替える際にも使われます。select … from … group by Col1 のようなクエリでグルーピングを行う際にも使われます。また、if (@a = @b)…

1

[VS 2013] SQL Server Data Tools (SSDT) のフォントの色が変わらない

  佐藤 靖典 SQL Developer Support Engineer   みなさん、こんにちは。 今回は、Visual Studio 2013 の SQL Server Data Tools (SSDT) 日本語版を使用している開発者の方が遭遇する可能性のある問題と対処方法を紹介します。 [1] 事象 SSDT のアップデートを行うと、次のように SSDT のエディタのフォントが色分けされなくなる事象が発生する場合があります。 この事象が発生したら、以降の対処策をご確認ください。 [2] 対処策 次のどちらかを実施ください。 (a) Visual Studio 2013 Update 3 以上を適用する。 (b) レジストリ キーを削除する。 (a) Visual Studio 2013 Update 3 以上を適用する。 Visual Studio 2013 の [ツール] メニューの [拡張機能と更新プログラム] から、Visual Studio…

0

[Data Access] ODBC カーソルライブラリ非推奨に伴う Visual Studio 2012 以降のバージョンの MFC における実装変更とその動作について

横井 羽衣子 (よこい ういこ) Microsoft SQL Developer Support Engineer みなさんごきげんよう。本日は、Visual Studio 2012 の MFC CDatabase クラスにおける実装変更と、それに伴う挙動の変化についてご紹介します。この挙動は、レガシー テクノロジの一つである ODBC カーソル ライブラリが非推奨になったことに伴う変更です。 ODBC カーソル ライブラリをはじめ、いくつかの古くから存在するデータアクセス テクノロジには時代の変化に伴い、非推奨となった機能があります。今回の記事では、そうした非推奨となった機能についての情報を今後確認頂くための情報などもご紹介します。 【現象】 Visual Studio 2012 より前のバージョンの MFC の CDatabase クラスで以下の条件で処理を実行した場合と、Visual Studio 2012 以降の同クラスを用いた場合で接続先の SQL Server のバージョンに関わらず、処理の結果が異なる。 実装の流れは以下の通り。 1. CDatabase::OpenEx() のオプションに、CDatabase::useCursorLib を指定してデータベースをオープン 2. CRecordset::Open() でレコードセットタイプ (nOpenType) を明示的に指定しないか、あるいは CRecoredset::snapshot(※) を指定して Edit() メソッドを実行する 結果は以下の通り。 Visual…

0

[Info] .NET Framework アプリケーションをリモート配置した場合に SQL Server への接続がタイムアウトすることがある

今回の記事では、SQL Server データアクセスを行うアプリケーションについて、その実体の配置場所によって処理の遅延が発生し、接続処理がタイムアウトしたという事例について紹介いたします。もし、身近に同様の事例や、経験をお持ちの方は、以下の内容がご参考になれば幸いです。   事例 : 「ファイル共有に配置したADO から ADO.NET アプリケーションに移行したら遅くなった」 ADO 経由で SQL Server に接続しデータアクセスを実行するアプリケーション(*.exe)を共有フォルダ上に配置し、クライアントには共有フォルダ上のアプリケーションのショートカットをダブルクリックしてアプリケーションを実行していたシステムを、.NET Framework で再構成し、ADO.NET 経由で SQL Server に接続するようにマイグレーションしたところ、SQL Server への接続が高確率でタイムアウトするようになった。 接続文字列で、”Connection Timeout” プロパティを 120 秒程に延長してみたが、状況は改善しなかった。処理の序盤ではタイムアウトせず、だんだんタイムアウトしていく確率が上がっていくような動きになっている。そこでアプリケーションをクライアント ローカルもしくは SQL Server と同じ環境に配置したところ、タイムアウトは一切発生しないことがわかった。 検証結果から、アプリケーションの配置場所がローカルか、リモートかという違いのみ、動作に影響しているようであるが、以前の ADO 経由のアプリケーションでは問題が発生しなかった。 発生例) Visual Basic 6.0 アプリケーションから Visual Basic (.NET Framework ベース) に移行した場合など   この事例での対処 この問題は障害ではなく、以下の二つの要因により接続処理のすべてのフェーズが接続タイムアウト期間中に完遂していない可能性が高いという判断に至りました。このため、この件ではアプリケーションの配置を各ローカルに変更することにより、問題を解消することができました。 1. 非同期で読み込まれていくアプリケーション実行関連のファイル(DLL、EXE、ini、config ファイルなど)のネットワーク伝送およびネットワーク伝送処理における IO のオーバーヘッド 2….

0

real および float データ型におけるアンダーフロー時の動作

    神谷 雅紀 Escalation Engineer   real および float 浮動小数点データ型においてアンダーフローが発生した場合、エラーは発生しません。0 が設定されます。   各データ型で格納可能な数値範囲は以下の通りです。   データ型 格納可能な数値範囲 real – 3.40E+38 ~ -1.18E-38、0、および 1.18E-38 ~ 3.40E+38 float – 1.79E+308 ~ -2.23E-308、0、および 2.23E-308 ~ 1.79E+308     以下は、その動作を確認することのできる簡単なサンプルです。   float 型に格納可能な最小値よりも小さな 2.23E-309 を格納しようとすると、結果は 0 になります。それを示す警告も返されます。   declare @r float set @f = 2.23E-309 select @f as ‘float’…

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

サーバー カーソル動作とクエリパフォーマンスとの関連性について

皆さん、こんにちは。 SQL Server/Windows Azure SQL Database サポートチームの 高原 です。 今回は、サーバー カーソル (Transact-SQL カーソル) の動作とクエリパフォーマンスとの関連性について説明します。   SQL Server では、以下の 4 種類の サーバー カーソル をサポートしています。 静的カーソル (STATIC) キーセット ドリブン カーソル (KEYSET) 動的カーソル (DYNAMIC ) 順方向専用カーソル (FAST_FORWARD)   各カーソルの動作 (特徴) について簡単に説明します。   静的カーソル (STATIC) ・カーソル宣言 (DECLARE CURSOR) 時に指定したクエリ結果セットを、TempDB 上の 一時テーブル に保存 ・フェッチ (FETCH) 時に、FIRST、LAST、RELATIVE などのフェッチ動作が使用可能 ・取得した結果セットの行の値がカーソル処理中に更新された場合でも、変更は結果セットに反映されない   キーセット…

0

[SQL Connectivity] 名前付きパイプでの接続時トラブルシューティング

佐藤美菜 SQL Developer Support Engineer SQL Server へのアクセスは各種プロトコル( TCP/IP、名前付きパイプ、共有メモリ) で行えます。 SQL Server 2000 以降、既定のプロトコルは TCP/IP となっており、TCP/IP での接続がメインとなっているのが昨今です。 TCP/IP に比べ、名前付きパイプは古いテクノロジーで忘れがちですが、忘れがちだからこそ、ということで、今回は、名前付きパイプでの接続時のトラブルシューティング方法を紹介します。接続できなかった場合にはチェックしてみてください。   問題箇所特定のための切り分け接続テスト 名前付きパイプでのトラブルシューティングに入る前に、まずは、問題箇所を特定するために、以下で案内している 「2-2. 再現性がある場合に、切り分けのために実施いただきたい接続テスト」を試してみてください。 Troubleshooting Connectivity #4 – 接続エラーの調査方法 名前付きパイプの接続時の問題かどうかを切り分けるには、接続テスト時のサーバー名に使用するプロトコルを指定して確認します。 TCP/IP での接続 : tcp:接続先SQLServerホスト名 名前付きパイプでの接続 : np:接続先SQLServerホスト名 共有メモリでの接続 : lpc:接続先SQLServerホスト名 接続テストの結果、名前付きパイプでの接続に問題があることが特定できたら、次に進みます。   名前付きパイプでの接続トラブルシューティング はじめに : 名前付きパイプでの接続時の動作について 名前付きパイプ プロトコルによる通信では、サーバー側の IPC$ という共有名に対して接続要求を行います。ユーザー情報を渡し、適切である場合に接続が確立されます。クライアント上で動作しているアプリケーションの実行ユーザーが、このサーバーの共有にアクセスする権限を持っていないと名前付きパイプの接続が失敗します。 ※ SQL Server 認証の場合でも、名前付きパイプを使用する場合は、Windows ユーザーの認証処理がプロトコル…

0