DO’s&DONT’s #4: やらない方がいいこと – クエリの 条件句 (WHERE や JOIN ON 等) で参照されている列の加工

神谷 雅紀SQL Server Escalation Engineer   パフォーマンスに優れたクエリを書こうとするのであれば、クエリの WHERE 句や結合句で参照されるテーブルの列を関数などで加工してはいけません。   悪い例 SELECT * FROM Sales WHERE convert(char(10),EntryDate, 111) = ‘2010/12/01’ SELECT * FROM Sales WHERE FistName + Last Name = @name   なぜ? その列にインデックスがあったとしても、そのインデックスによる行の絞込みが行えないからです。 例えば、上の例の最初のクエリでは、以下の処理が必要です。 テーブルから行を読み取る。 列 EntryDate の値を convert 関数に渡す。 convert 関数から返された値を定数 ‘2010/12/01’ と比較する。 比較の結果、一致すれば、その行をクエリ結果へ入れる。一致しなければ 1 へ戻り次の行を処理。 このように、クエリ条件に一致しているかどうかを判定するためには、値を関数に渡す必要があり、関数に渡すためには必ず行を読み取ることが必要になるため、EntryDate がインデックスの先頭列であったとしても、そのインデックスを使用して、読み取り範囲を ‘2010/12/01’ に限定することができず、テーブルの全行を読み取る必要があります。読み取り量が多いということは、処理するデータ量が多いということであり、処理するデータ量が多ければ、処理完了までには時間がかかることになります。つまり、クエリの実行時間が長くなります。   どうするか? クエリが同じ結果を生成し、かつ、列の値を加工しない別の方法を検討します。…

0

DO’s&DONT’s #3: やらなければいけないこと – 非典型的パラメータ値が存在する場合の再コンパイル (Atypical Parameter Problem の対応)

神谷 雅紀SQL Server Escalation Engineer   非典型的パラメータの問題   Atypical Parameter Problem (非典型的パラメータ値に起因する問題) と呼ばれる問題があります。これは、ストアドプロシージャやパラメータ化クエリなどに、典型的ではない、普段使わないような特殊な値のパラメータ値が渡され、その値を用いてコンパイル及び最適化された実行プランがキャッシュされることによって引き起こされる問題です。この問題は、パラメータとして渡された値によって、検索範囲や結果セットが大きく変わる場合に発生します。   それによって、何が起こるのか?   パフォーマンスの問題が発生します。 以下のようなケースを考えてみましょう。 「休業日のデータを検索した。その後、普段は時間のかからない営業日のデータ検索に時間がかかるようになった。」「本店で、全支店のデータ検索が行われた。その後、支店別のデータを検索すると、いつもに比べて非常に時間がかかる。」 ストアドプロシージャやクエリが実行される時、まず、それらの実行プランが既にキャッシュされているかどうかが確認されます。キャッシュされていれば、キャッシュされている実行プランを用いて、処理が実行されます。キャッシュされていなければ、指定されているパラメータ値を使用して、コンパイル及び最適化がおこなわれ、実行プランが生成されます。その実行プランはキャッシュされます。先の例では、キャッシュされている実行プランがなければ、「休業日のデータ検索」のためにストアドプロシージャを実行した時に、「休業日のデータ検索」に最適な実行プランが生成され、その実行プランはキャッシュされます。それ以降、このストアドプロシージャが実行される時には、キャッシュされている「休業日のデータ検索」に最適な実行プランを用いて実行されます。その実行プランが「営業日のデータ検索」にも最適であればパフォーマンスの問題は発生しません。しかし、「休業日のデータ検索」には最適であっても、「営業日のデータ検索」には最適でなければ、言い換えれば、「休業日のデータ検索」の時に指定されたパラメータが非典型的であれば、「営業日のデータ検索」にはパフォーマンスの問題が発生することになります。   どのように対応するか?   非典型的なパラメータが存在すると予想される場合には、実行ごとにコンパイル及び最適化することを指定します。そのための方法としては、以下の方法があります。 ステートメントに OPTION(RECOMPILE) を指定する。 (SQL Server 2005 以降のみ) SELECT * FROM tabname WHERE colname = 123OPTION(RECOMPILE)   ストアドプロシージャの場合には、 ストアドプロシージャを WITH RECOMPILE 指定で作成する。 CREATE PROCEDURE p (@param1 int) WITH RECOMPILEASSELECT …   ストアドプロシージャ実行時に RECOMPILE…

0

Known Issue: ADO アプリケーションを Windows Server 2008 上で動作させると「要求された名前、または序数に対応する項目がコレクションで見つかりません。」エラーが発生する。

高橋 理香SQL Developer Support Eascalation Engineer   こんにちは。   この blog では、既知の問題として報告されているけれども、サポート技術情報では関連性を判断できないような問題についてもわかりやすくご紹介できればと考えています。   早速ですが、最近立て続けに SQL Server にアクセスするアプリケーションを動作させる OS を Windows Server 2008 に変更したらエラーが発生するようになったというお問い合わせをいただきました。いずれも同じ現象、同じ問題でしたので、こちらでご紹介したいと思います。   同じエラーが発生した場合、参考にしてみてください。     1.   関連テクノロジー ·         Windows Server 2008 / Windows Vista·         VB 6.0/VBScript·         ADO   ※VB 6.0 はサポートを終了しています。     2.   発生する問題   ADO の Fields コレクションを使用して、Recordset 中のデータを参照しようとすると以下のエラーが発生する。   エラー:要求された名前、または序数に対応する項目がコレクションで見つかりません。コード:800A0CC1ソース:ADODB.Recordset…

0

DO’s&DONT’s #2: 絶対にやらなければいけないこと – データ型を一致させる

神谷 雅紀 SQL Server Eascalation Engineer クエリを書く場合、比較を行うデータのデータ型は一致させておくことが必要です。   なぜ? データ型が一致していない場合、必ず、どちらかのデータがもう片方のデータのデータ型に変換された後に比較が行われます。つまり、SQL Server は、データ型変換という余分な処理を行わなければならなくなります。また、それだけではなく、データ型を一致させるために、本来読み取る必要のないデータを読み取らなければならなくなることもあります。   どのような影響があるのか? クエリのパフォーマンス悪化です。比較するデータのデータ型が一致していない場合、データ型の優先順位に従って、優先順位の低いデータ型のデータが、優先順位の高いデータ型に変換されます。   データ型の優先順位 (Transact-SQL) http://msdn.microsoft.com/ja-jp/library/ms190309.aspx   例えば、以下のクエリを考えます。   CREATE TABLE TableA (C1 varchar(10)) GO SELECT * FROM TableA WHERE C1=N’XXX’ GO   SELECT の WHERE 句に指定されている C1 は VARCHAR(10) ですので非 Unicode 型ですが、比較対象の N’XXX’は Unicode 型です。 この場合、何が発生するのでしょう?実行プランを見てみます。   |–Table Scan(OBJECT:([testdb1].[dbo].[TableA]), WHERE:(CONVERT_IMPLICIT(nvarchar(10),[testdb1].[dbo].[TableA].[C1],0)=[@1]))  …

0

SQL トレーススクリプトの作成、実行 (SQL Server 2000)

神谷 雅紀SQL Server Escalation Engineer   SQL Server 2000 トレーススクリプトの作成方法です。SQL Server 2005, 2008, 2008 R2 については以下を参照して下さい。 http://blogs.msdn.com/b/jpsql/archive/2011/01/26/sql.aspx   1. Profiler の起動 [スタート] – [すべてのプログラム] – [Microsoft SQL Server] – [プロファイラ] から、Profiler を起動します。 2. 新しいトレースの作成 [ファイル] メニュー – [新しいトレース] を実行します。 続いて、SQL Server  名を指定し、SQL Server へ接続します。 3. トレースプロパティの指定 [全般] タブで、[ファイルに保存]、 [ファイルロールオーバーを有効にする] 、「サーバーが SQl Server トレースを処理する」をチェックします。また、トレースの最大ファイルサイズを指定します。 4. トレース対象イベントの指定 [イベント] タブで、トレースしたいイベント名を選択します。 5. データ列の選択 [データ列]…

0

SQL トレーススクリプトの作成、実行 (SQL Server 2005 以降)

神谷 雅紀 SQL Server Escalation Engineer 以降の画面は、SQL Server 2008 R2 のものですが、SQL Server 2005 以降のバージョンでは同様の手順、同様の画面です。 SQL Server 2000 については、以下を参照して下さい。 http://blogs.msdn.com/b/jpsql/archive/2011/01/26/sql-sql-server-2000.aspx 1. Profiler の起動 [スタート] – [すべてのプログラム] – [Microsoft SQL Server 2008 R2] – [パフォーマンスツール] – [SQL Server Profiler] から、Profiler を起動します。 2. 新しいトレースの作成 [ファイル] メニュー – [新しいトレース] を実行します。   続いて、SQL Server  名を指定し、SQL Server へ接続します。   3. トレースプロパティの指定…

1

DO’s&DONT’s #1: やらない方がいいこと – 運用環境で、Profiler GUI を使用してトレースする

神谷 雅紀 SQL Server Escalation Engineer SQL Server において、やらなければいけないこと / やってはいけないことを、Do’s&Don’t’s として、シリーズで紹介したいと思います。初回の今回は、Profiler GUI についてです。 一定量の負荷がある環境において、Profiler GUI を用いてリアルタイムモニタをしたり、テーブルにトレースデータを保存したりすることは、パフォーマンスなどの問題を発生させる要因となります。絶対にやってはいけない、というほどではありませんが、ベストプラクティスとして、やらない方がよいことは確かです。   なぜ?   多数のクライアント接続があり、多数のリクエストを受け付けている SQL Server が生成するすべてのイベントをひとつの Profiler で受け取ることになるため、Profiler がボトルネックとなり、SQL Server 全体のパフォーマンスが著しく悪化し、実行中のクエリがタイムアウトする、ログインがタイムアウトする、場合によっては、クラスタやミラーリングのフェールオーバなどを招くこともあります。Profiler GUI は、ひとつの普通のクライアント接続を通じて、SQL Server からトレースイベントを受け取ります。当然、その接続で転送できる量は限られており、また、それをグラフィカル表示しなければならないため、SQL Server 側で生成されるイベント量が、Profiler が処理できるイベント量の限界を超える状況になると、SQL Server 側では新たなイベントを Profiler に渡せなくなり、イベントを生成している一般のクライアントは、イベント書き込み待ち状態になります。 さらに、Profiler を経由して SQL Server のテーブルへイベントを書き込んでいる場合は、SQL Server → Profiler → SQL Server とイベントデータが渡されることになり、パフォーマンスへの影響はより大きくなります。 テスト環境など負荷を制御できる環境や、非常に負荷の低く、ほとんど処理が行われていないような環境を除いて、何らかのトラブルシューティングのために Profiler GUI…

1

Welcome to Microsoft SQL Server Japan Support Team Blog

マイクロソフト SQL Server サポートチームの Blog サイトです。SQL Server サポートチームは、SQL Server, Analysis Services, Reporting Services, Integration Services, Notification Services といった SQL Server 製品群および System.Data, SQL Native Client などのデータアクセスコンポーネント、SQL Azure などの Cloud サービスなどを担当するチームです。 この Blog では、SQL Server サポートチームが担当している製品やテクノロジー、サービスに関して、その適切な使用方法、トラブルが発生した場合のトラブルシューティング方法、製品ドキュメントを補足する情報、問題を発生させないための方法、便利なツールなど、普段のサポート業務の中から得たあらゆるトピックを紹介していきたいと思います。

0

SQL Server Compact Edition の最新モジュール

  2015 年 4月17日 時点の SQL Server Compact Edition 最新モジュール(SPとCU)です。 サービス パック 更新プログラム・搭載製品 バージョン リリース年月 SQL Server Compact 3.5 RTM 無し 3.5.5386 2007/11 延長サポート SQL Server Compact 3.5 SP1 無し 3.5.5692 2008/08 SQL Server Compact 3.5 SP2 KB 2665342 (CU7) Windows Embedded Compact 7 3.5.8089 3.5.8154 2012/02 延長サポート   SQL Server Compact 4.0 RTM 無し 4.0.8482…

0