[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

[ご注意ください] 12 月 10 日に Windows Update で配信された Visual Studio 2012 対象の更新プログラム KB3002339 をインストールするとシステムのハングアップなどの問題が発生する(※ Ver3.0 – 12/17リンク先追記あり)

※ 本件は、Visual Studio サポート チームのブログの転載となります。 2014 年 12 月 10 日に公開され、Windows Update で配信された Visual Studio 2012 対象の KB3002339 の更新プログラムをインストールすると、Windows Update が完了しない、システム再起動時に更新が完了せずシステムがハングアップしてしまうという現象が発生することを確認いたしました。 KB3002339 https://support.microsoft.com/kb/3002339/ 本問題の報告を受け、Windows Update の配信は既に停止いたしましたが、Windows Server Update Services (WSUS) を使用して更新プログラムを配信されているお客様におかれましては、本更新プログラムの配信を停止していただけますようお願い申し上げます。 既に本更新プログラムを適用し、ハングアップなどの現象が発生している環境での復旧方法につきましては、現在調査中です。進展があり次第、Visual Studio チーム記事にて情報公開させていただきます。最新の内容は下記 Visual Studio チームブログ(※12/17 アップデート内容がございます)をご覧ください。 Visual Studio サポートチームブログ [ご注意ください] 12 月 10 日に Windows Update で配信された Visual Studio 2012 対象の更新プログラム KB3002339 をインストールするとシステムのハングアップなどの問題が発生する…

0

[SQL Database] アプリケーション作成における推奨事項について (Microsoft Azure SQL Database)

  皆さん、こんにちは。 SQL Server/Microsoft Azure SQL Database サポートチーム です。 今回は、Microsoft Azure SQL Database (以下 MASD) を使用したシステムを構築するうえで、推奨されるアプリケーションの実装について紹介します。   MASD は、クラウド上に配置されたデータベースをサービス (Software as a Service : SaaS) として提供しており、高可用性を実現するため、複数レプリカによる冗長性を備えています。また、高可用性を維持していくために、Reconfiguration (リコンフィグレーション) が内部的に行われています。 ※ Reconfiguration (リコンフィグレーション) の詳細については、以下の ブログを参照ください。   [SQL Database] Reconfiguration (リコンフィグレーション) は悪ではない。 http://blogs.msdn.com/b/jpsql/archive/2014/10/22/sql-database-reconfiguration.aspx   そのため、MASD を使用したシステムを構築する場合は、アプリケーション側でも、 アプリケーションからデータベースまでの経路間におけるネットワーク遅延、及び、Reconfiguration (リコンフィグレーション) の発生に伴う、既存セッションの切断、ロールの変更 (セカンダリからプライマリへの昇格など) が完了するまでの期間 (数秒から数十秒程度) における、新規接続の一時的な遅延を考慮した実装を検討する必要があります。 上記の事項を考慮した実装として、アプリケーション側で以下を実装することを推奨しています。   推奨実装 (アプリケーション側) 1)…

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

[Windows XP] 暗号化された SQL Server Compact Edition データベースに対してアクセス遅延が発生することがある

.NET Framework 4.0 ベースのアプリケーションにおいて、暗号化された SQL Server Compact Edition データベースに対するデータアクセス処理を行った際、Windows XP 環境で処理が遅くなることがあります。 1. 問題発生要因 SQL Server Compact Edition プロバイダは、暗号化されたデータベースを参照する際に初回に CryptAcquireContext メソッドをコールします。暗号化されたデータの複合のためのキー コンテナーは、マシンコンテナに格納されているため(※)、下記フォルダ (以下 MachineKeys フォルダと呼称) を参照することになります。 C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys MachineKeys フォルダにアクセス出来ない場合、後処理ロジックに分岐しますが、この後続処理に時間を要し処理が遅くなります。従って、対処方法としてはアプリケーションを実行するユーザーに MachineKeys フォルダに対する参照権限を付与していただくことで、後続の処理ロジックを実行させないということになります。 2. 対処方法 事前に MachineKeys フォルダに対し、SQL Server Compact Edition を参照するユーザーに対してアクセス権限を付与します。これにより後続の処理ロジックを実行させないことにより遅延が抑止されます。なお、既に SQL Server Compact Database をインストールしている環境には、既に MachineKeys フォ ルダ以下にキーコンテナが存在します。他のアプリケーションが、SQL Server Compact Database を使用している場合などは、キーコンテナの権限を手動で編集し、他のアプリケーションに対しての影響がないか十分に評価を行っていただくことを推奨いたします。…

0

Troubleshooting Connectivity #6 – 接続タイムアウトは悪なのか?

高橋 理香 SQL Developer Support Escalation Engineer みなさん、こんにちは。 数年以上前からずっと個人的にいつかきっとわかってもらえる…と思いながら今日まで心の中でしまっていたこと。それが接続タイムアウトの存在意義。(いえ、実際にはお問い合わせいただいた方にはそれとなく、もしくははっきりとお伝えしたこともあるのですが、、、) そんな接続タイムアウトについての考え方について今回は書きたいと思います。 接続タイムアウトとは? 接続タイムアウトとは、アプリケーションからの接続要求が一定時間内に完了しなかった事象を指します。また、その際に返されるエラーが、タイムアウト エラーです。 例えばこんなエラーがありますね。(接続時に発生するエラーとしてどんなエラーがあるかはまた後日に別のトピックにてご紹介予定です。) Timeout に達しました。操作が完了する前にタイムアウト期間が過ぎたか、またはサーバーが応答していません           ログイン タイムアウトが時間切れになりました。 「一定時間内に完了しない」というのがどういうことかについては、このシリーズをご覧くださっている皆様ならお分かりいただけると思いますが念のため列挙します。 OS レベルのセッション確立に遅延が生じた。 ログイン認証の処理に遅延が生じた。 データベース アクセスに遅延が生じた。 ではそれぞれに遅延が生ずる主な理由は・・・ はい、皆様、以前のブログに書いていますので、そちらをご覧くださいね。 Troubleshooting: Connectivity #2 – エラー情報からわかる失敗原因 とにかくです。どこかに遅延が生じて、時間がかかってしまったという状況を指すわけです。   遅延を許容するか?それともエラーで中断させるか? さてさて、ネットワーク等のインフラが整ってきた昨今ですが、いつどんな環境でも同じ程度のレスポンスって約束されているんでしょうか??? 私が自宅で使っている PC は CPU のクロック数はそこそこであるもののメモリは少なく、また、ネットワークのスピードも、さっき下り 75Mbps だったのが今は 10Mbps くらいになっているなど、会社と同じようにインフラが整ってます!とは言いがたい状況です。会社で作業していたとしても、一部メンテナンスでつながりにくいことなどもあります。つまり、「いつどんな環境でも」という点でいえば、いまだそこまでは High Performance が保証されてはいないのが現実だと思います。 ではこの遅い状況もあるだろうという昨今の環境において、その遅い状況に遭遇した場合を考えてみましょう。あなたはどちらを望みますか? 遅いことを示すメッセージを出して後で再試行するのがいいですか? それとも・・・ 遅くてもいいからエラーは出さないで終わってほしいですか? 少なくとも私が自宅にてちょっとした興味でどこかのサイトでお買い物なんかを行っているような状況の場合、メッセージが出て処理が中断されても問題ありません。むしろ、混雑していることを教えてもらえれば後日にやればいいだけということもあります。 勢いでクリックしたものなんかは考える余地ができます(笑)…

0

IEの制限の影響によりWCF Data Services クライアントにおいて、300秒で’System.InvalidOperationException’が発生することがある

  横井 羽衣子SQL Developer Support みなさんごきげんよう。今回は、WCF Data Services とデータアクセスを行う Silverlight アプリケーションにおいて、DataServiceQuery.EndExecute でキッチリ 300 秒で内部エラーが発生してしまうという現象についてお話したいと思います。 「DataServiceQuery.EndExecute で内部エラー」というと、WCF Data Services か、あるいは Silverlight 側を疑ってしまいがちではないでしょうか。ところが、今回ご紹介する現象は、実はクライアント側、それも Internet Explorer (IE) の制限事項の影響を受けた結果なのです。 WCF Data Services など、Web 系のアプリケーション、サービスにおいては、様々な要素が絡み合って機能を実現しています。たとえば “メモ帳” などのように、ローカルで閉じた環境で、他プロセスなどが介在しないようなアプリケーションで問題が発生した時とは異なります。まずシステムの構成要素と動作時の処理の流れを把握することが最も重要です。 今回の場合エラーが一般的問題を表すだけの内容の上、クライアントといっても、例外は Silverlight で発生していますので、 その先の IE 側まで着目せず、惑わされやすいパターンと言えます。 問題 Silverlight から WCF Data Services に要求を投げてデータ取得を行うシステムを実装している。 システム要件として、複数の画面用の処理を同時実行したいため、以下のような動作の流れとなっている。 1. WCF Data Services Client (Silverlight 側) において DataServiceQuery.BeginExecute…

0

[Windows Azure] ゲスト OS アップグレード後、ゲスト OS 上のSQL Server Native Client を使用している WebRole/Worker Role アプリケーションで例外エラーが発生する (Ver 2.0)

2013 年 7 月以前の Windows Azure の ゲスト OS には、SQL Server 2008 Native Client (以下 SQLNCLI10)が含まれていましたが、7 月リリースの Azure ゲスト OS (バージョン 1.24 / 2.16 および 3.4) には、SQL Server 2012 Native Client (以下 SQLNCLI11) に置き換えられました。SQL Databaseに接続するクライアント アプリケーションにおいて Azure ゲスト OS に含まれる SQLNCLI10 を使用していた場合、この変更によってデータソース接続ができなくなり、例外がスローされるなどの問題が発生することになります。 Note : 2013/08/09 Update – 過去バージョンの Guest OS のリタイアについて 対処方法として、SQLNCLI10 の含まれる June release…

0

[*.rdlc] エクスポートした PDF の文字化け ~ 確認ポイントの鍵はシステム構成要素にあり ~

横井 羽衣子 SQL Developer Support Engineer みなさんごきげんよう。今日は、みんな大好きレポートの大敵「PDF の文字化け」についてです。 以前、弊社森が Reporting Services でエクスポートした PDF における文字化け問題について書いています。これは SQL Server Reporting Services 上のレポート、いわゆるサーバー レポート (*.rdl) についてのお話でしたが、この記事では、意外に気づかないローカル レポート (*.rdlc) について「Report Viewer コントロールは Version 10 ではフォント埋め込み対応してるけど、Version 9 では対応されていない」という件についてと、エクスポート時の文字化けの確認ポイントについて触れたいと思います。 ちなみに、Version 9 は、Visual Studio 2008 付属、Version 10 は Visual Studio 2010 に付属しています。 PDF で文字化けしてしまうときのフォントの扱われ方 まず、レポートをエクスポートするときの動きについておさらいしてみましょう。PDF にする際は、サーバーレポート、クライアント レポートともに、以下のような動きになります。 (1) レポートのエクスポート出力元は、そのマシン上の OS のフォント情報を使い、PDF ファイルをレンダリングします。その際、フォントが埋め込まれない場合、文字識別情報 (グリフ…

0

DO’s&DONT’s #18: やった方がいいこと – .NET Framework アプリケーションでパラメータクエリを実行する場合にはパラメータのデータ型やサイズを明示的に指定する

    高橋 理香 SQL Developer Support Escalation Engineer     SQL Server では、パラメータ付きのストアドプロシージャを作成して実行したり、sp_executesql を使用してパラメータ クエリを実行することができます。このパラメータ クエリを実行する際には、パラメータのデータ型やパラメータ値が必要となります。また、文字列型やバイナリ型の場合には、サイズの指定も必要です。 一方で .NET Framework Data Provider for SQL Server (以降 SqlClient) を使用するアプリケーションからストアドプロシージャやパラメータ クエリを実行する場合、SqlParameter クラスを使用してパラメータのデータ型等を設定できますが省略することもできます。これは、SqlClient が SqlParameter の Value プロパティに代入された値を基にデータ型やサイズの推論を行っているからです。 しかしながら、パラメータのデータ型やサイズを明示的に指定しなかった場合には、意図しないデータ型やサイズとなることで、クエリのパフォーマンス劣化が発生したり、エラーによって実行できないなどの問題が発生する可能性もあります。そのため、可能な限りパラメータのデータ型やサイズは明示的に記述しておいた方が、アプリケーションの堅牢性の面からもよいでしょう。   推奨事項 パラメータのデータ型は SQL Server 側のデータ型に合わせて明示的に指定する。 文字列やバイナリのデータ型の場合、サイズも明示的に指定する。 varchar(max) 等の max を使用したデータ型についてはサイズに -1 を指定する。   なぜデータ型を明示的に指定した方がいいのか? 以前に以下のブログで紹介しているように、データ型が一致していない場合にはデータ型変換を行ってから比較を行うことになります。つまり、クエリ パフォーマンスが悪化し、ひいては、アプリケーションのパフォーマンス劣化につながります。 DO’s&DONT’s #2:…

0