SQL Server 2008 および SQL Server 2008 R2 の不具合修正情報の公開 – 照合順序のバージョンが 90 の場合、誤った実行結果が返ってくる事象について

山崎 実久  SQL Engine Support Engineer 下記の SQL Server のバージョンで修正済みですが、マイクロソフト サポート技術記事で公開されていない不具合情報を記載します。 ・SQL Server 2008 SP2 Cumulative Update 7 ・SQL Server 2008 R2 Cumulative Update 11 ・SQL Server 2008 R2 SP1 Cumulative Update 4 上記の環境より前のバージョンをご利用で、データベースの照合順序のバージョンが 90 の場合、LIKE 句を含み % のワイルドカード文字を利用するクエリを実行した際、誤った結果が返ってくる事象が報告されています。 もしくは、以下のように照合順序のバージョンを 90 を利用してクエリを実行した場合、誤った結果が返ってくる事象が報告されています。 Select * from table where c1 like ‘1%5’ collate Japanese_90_CI_AS 以下に、本不具合を再現可能なサンプルスクリプトの例を紹介します。 — データベース作成…

0

SQL Server 2005,2008,2008 R2 Analysis Services Standard エディションにおける使用可能な関数について

藤丸 陽子SQL Developer Support  Engineer Analysis Services ではエディションにより使用可能な集計関数が異なります。Enterprise エディションではすべての集計関数が使用可能ですが、Standard エディションでの対応は以下の通りです。 エディションを選定頂くにあたりご参考下さい。 集計関数 種類 加法性 SUM           加法   ○ COUNT         加法   ○ MIN           準加法 ○ MAX           準加法 ○ DISTINCTCOUNT    非加法 ○ NONE             非加法 × ByAccount        準加法 × AverageofChildren 準加法 × FirstChild       準加法 × LastChild        準加法 ○ FirstNonEmpty       準加法 × LastNonEmpty       準加法 × SQL Server 2005、SQL Server 2008、SQL…

0

Oracle 経験者のための SQL Server HowTo #1: 拡張イベントを使って On-Error Dump を取得する

早川 邦彦  SQL Engine Support Engineer   技術者としていくつかのデータベース製品を扱う機会があるかと思いますが、データベース製品には構文や機能の違いがあるので、一つのデータベース製品でできることが別の製品では実装方法が分からないケースが多々あると思います。そこで、 Oracle データベースでできることをいくつか例として挙げて、 SQL Server ではどのようにこれらを実装できるかを何回かのシリーズで紹介しようと思います。 まず一回目の今回は、SQL Server の拡張イベント機能を使って Oracle でいう On-Error Dump を取得する方法について紹介します。 1. On-Error Dump について Oracle データベースでは以下のようなコマンドを実行することで特定のエラーが発生した際にエラー発生時の情報をトレースファイルに出力させることができます。 下記のコマンドは ORA-942 エラーが発生した際に errorstack というタイプのダンプファイルを詳細レベル 3 で出力するというコマンド例です。     alter system set events ‘942 trace name errorstack level 3’ SQL Server 2008 以降では拡張イベントを使えば上記の Oracle データベースのコマンドのように特定のエラーが発生したタイミングで情報をトレースファイルに出力させることができます。なお、 Oracle のコマンドとは違い、SQL Server の拡張イベントを使用すればいつ、何を、どこに出力するかをより詳細に制御することが可能です。…

0

スクリプト アップグレード モード

  神谷 雅紀 Escalation Engineer   最近連続してスクリプト アップグレード モードに関する問合わせがあったため、今回は、スクリプト アップグレード モードについて、説明したいと思います。   スクリプト アップグレードモードとは サービスパックや Hotfix をインストールすると、sqlservr.exe などの実行可能ファイルだけでなく、master データベース内のシステム ストアドプロシージャやシステム テーブルの一部も更新される場合があります。スクリプト アップグレード モードとは、これらデータベース内の ストアドプロシージャや テーブルの更新を行なうためのスクリプトを実行するためのモードで、SQL Server 2008 から導入されています。SQL Server 2005 以前は、サービスパック等のインストール中にスクリプトが実行されていました。   いつスクリプト アップグレード モードになるのか SQL Server は、起動時に、master データベースに記録されているスクリプト バージョンとインストールされているスクリプトバージョンを比較します。このバージョン比較の結果、バージョンが一致していない場合に、スクリプト アップグレード モードになり、スクリプトの実行が始まります。一致していれば、スクリプト アップグレード モードにはならず、スクリプトも実行されません。 従って、次の場合にスクリプト アップグレード モードになります。 サービスパックや Hotfix のインストールが完了し、インストール済みスクリプトのバージョンが上がった場合、その後の最初の SQL Server 起動時 (アップグレード) サービスパックや…

0

Troubleshooting Connectivity #1 – SQL Server への接続

  高橋 理香 SQL Developer Support Escalation Engineer   SQL Server にアクセスするアプリケーションを開発、運用していて発生する接続エラー。エラーのメッセージは様々あるものの、少々古いテクノロジーを使用していると、メッセージからは何が起こったのかがわかりにくいケースが多々あります。エラー発生時のトラブルシューティングについて、SQL Server への接続の仕組みやエラーの意味、エラーが発生した場合の対処などについて、何回かのシリーズでご紹介しようと思います。 まず 1 回目の今回は、接続時の基本的な処理内容と、事前のチェック事項についてご紹介します。   SQL Server への接続で行われることは? SQL Server 付属のツールや .NET で開発したアプリケーションなどから SQL Server に接続する場合、主に次の処理が行われます。   OS レベルのセッション確立 ログイン認証 データベースアクセス   どのステップがうまくいかなくても接続は失敗します。また、どのステップで失敗したかによって原因が異なる、つまり、対処のために確認すべきポイントが異なるため、それぞれ具体的にどのような処理を行っているのかを把握しておくことは重要です。以降では、それぞれの処理について説明します。   OS レベルのセッション確立 SQL Server では各種プロトコルによる接続待ち受けを行っており、クライアントからの接続時にはこれらの待ち受け先にアクセスし、OS レベルのセッションを確立します。 既定インスタンスに接続する場合はとてもシンプルです。既定インスタンスの場合、TCP/IP による接続待ち受けのための TCP ポートは、Well-Known ポートとしても登録されている 1433 のため、クライアントからは 1433 に対して Winsock の関数を使用してセッション確立を行います。名前付きパイプの場合は、SQL Server…

1

DO’s&DONT’s #11: やってはいけないこと – トランザクションログファイルの拡張サイズを極端に小さくする

  神谷 雅紀 Escalation Engineer   トランザクションログファイルを自動拡張にすることは問題ありませんが、拡張サイズを 1MB など極端に小さな値に設定してはいけません。   なぜ? トランザクションログは、仮想ログファイル (Virtual Log File / VLF) と呼ばれる論理的なファイルに分割されて使用されます。VLF は、トランザクションログファイル作成時および拡張時に作成されますが、トランザクションログファイル拡張時の拡張サイズが小さいと、小さな VLF が多数作成されることになります。VLF の数が多くなると次のようなことが起こります。 データベースの起動に時間がかかる。 トランザクションログのバックアップ、復元 (restore) に時間がかかる。 データベースミラーリングにおいて、ミラーサーバー側へのトランザクションの配信に時間がかかる。 トランザクションレプリケーションにおいて、サブスクライバへのトランザクションの配信に時間がかかる。 DBCC CHECKDB の実行に時間がかかる。 データベーススナップショットの作成に時間がかかる。 上にリストした操作は、トランザクションログをスキャンするため、VLF の数が多くなると、処理時間が長くなります。 トランザクションログの物理アーキテクチャの詳細については、Books Online トランザクションログの物理アーキテクチャを参照して下さい。   対処 既に VLF の数が多くなっている可能性がある場合 VLF の数を少なくするために、一旦トランザクションログファイルのサイズを小さくします。その後、元のファイルサイズまたはそれ以上のサイズを明示的に指定してファイルサイズを大きくします。 1. ファイルを圧縮してファイルサイズを小さくする。 ※ 「ファイル圧縮」の「圧縮アクション」は、「未使用領域を解放する」は TRUNCATEONLY, 「データを同じファイルグループのファイルに移行してファイルを空にする」は ENPTYFILE オプション付きの DBCC SHRINKFILE です。…

0

実行プランを読む – 活用編 (その 1) – クエリチューニング

神谷 雅紀 Esclation Engineer   前回までの内容で、実行プランからクエリがどのように実行されるのかを知ることができるかと思います。では、次に、実行プランを活用して、クエリの無駄を省き、チューニングを行う方法を考えてみましょう。 本題に入る前に。どのクエリをチューニング対象にするか、クエリのどの部分をチューニング対象とするかを決定する場合は、アムダールの法則を考慮して、掛かるコストと効果を見極めながら、慎重に決定することをお勧めします。   Key Lookup (Clustered Index Seek Lookup) や RID Lookup を排除する   次の実行プランには、Key Lookup が含まれています。 SET SHOWPLAN_ALL などの regacy プラン表示では、下のように Lookup 句付き Clustered Index Seek が含まれます。これは、Key Lookup と同意です。 このクエリは、非クラスタ化インデックスで行を絞り込み、その後、絞り込んだキーを使ってクラスタ化インデックスを検索することで、結果を生成しています。もし、このテーブルにクラスタ化インデックスがなければ、Key Lookup の代わりに RID Lookup が行われます。 では、このクエリをチューニングする、言い換えれば、実行時間を短くするためには何をすべきでしょうか? クエリをチューニングすることは、基本的に、クエリによって行われる読み取り数を減らすことであると考えて問題ないと思います。 では、読み取り数を減らすためには何ができるでしょうか? 読み取り数を減らすひとつの方法として、Key Lookup をクエリから排除する方法が考えられます。そのために、まずは、なぜ Key Lookup (Clustered Index Seek) が行われているのかを見てみましょう。 以下は、このクエリの実行プランの一部として示される DefinedValues…

1

HowTo: BID トレース – データアクセス アプリケーションのトレースを採取する

  高橋理香 SQL Developer Support Escalation Engineer SQL Server などのデータベースにアクセスする際に使用されるテクノロジーとして、ADO.NET や Windows DAC 等がありますが、今回はこのようなテクノロジーを使用したアプリケーションで問題が発生した場合に役立つ BID トレースについてご紹介します。今回は主に BID トレースの概要と採取の手順にフォーカスしてご説明します。 1. BID トレースの概要 1-1. BID トレースとは? Windows OS で提供している、オーバーヘッドの少ないトレースを提供することを目的とした Event Tracing for Windows (ETW) システムを使用したトレース手法です。データアクセス テクノロジーで利用する場合には、Built-in Diagnostics (BID) アダプタが製品コードを ETW プロバイダのように見せかけることでトレース採取を実現しているために、主に BID トレースという名前で呼んでいます。 1-2. BID トレースを採取できるコンポーネントは? BID トレースでは、主に以下のコンポーネントの処理をトレースすることができます。 System.Data 名前空間の各クラス (*1) MDAC/Windows DAC に含まれる ADO、OLE DB、ODBC などの各種データアクセス…

0

実行プランを読む – 基本編 (その 4)

神谷 雅紀 Escalation Engineer   物理操作と論理操作 実行プランを構成する各リレーショナルオペレータ (RelOp) には、物理操作 (PhysicalOp) と論理操作 (LogicalOp) があります。これらは、それぞれ、物理オペレータ、論理オペレータとも呼ばれます。 ※ ( ) 内の表記は、XML showplan での表記です。 論理操作は何をするかを表し、物理操作はどのように行うのかを表しています。例えば、内部結合を行う場合、論理操作は Inner Join になります。この内部結合を Nested Loop で行う場合は、物理操作は Nested Loop になります。これは、Nested Loop という方法を用いて、Inner Join を実現するということを表しています。   物理操作が実行可能な論理操作 各物理操作が実行可能な論理操作は決まっています。その代表的なものをいくつか紹介します。 尚、ここでは、論理操作によって動作が全く異なるということを示したいだけなので、オペレータの詳細については説明しません。オペレータの詳細やすべてのオペレータについて確認したい場合は、Books Online を参照して下さい。 Nested Loops Nested Loops 物理操作は、inner join, left outer join, left semi join, left anti semi join…

0

DO’s&DONT’s #10: やらない方がいいこと – クエリの条件句で変数を参照する

神谷 雅紀 Escalation Engineer   クエリの WHERE 句や JOIN ON 句など、クエリのフィルタ条件や結合条件で変数を参照すると、クエリのパフォーマンスが悪化する (実行時間が長くなる) 可能性が高まります。   なぜ?   必ずしも最適ではない実行プランが生成される可能性 SQL Server は、クライアントから送信されてくるバッチ (クライアントから送信されてくるひとつ以上のステートメントの塊) をコンパイルし、バッチ内の各ステートメントの実行プランを生成し、その後、そのバッチを実行します。実行プランの生成過程であるクエリの最適化 (optimization) では、クエリの検索条件や結合条件などを参照し、最も低コストであると考えられる実行プランを選択します。クエリの検索条件や結合条件は、実行プランの選択に大きな影響を与えます。しかし、変数は、最適化の段階では未知の値です。 以下の例を見てみます。 declare @x nvarchar(10) set @x = N’ABC’ select * from tab where col1 = @x go このバッチは、declare, set, select の 3 ステートメントから構成されています。このバッチの実行が要求されると、まず、これら 3 ステートメントがコンパイルされます。select については、実行プランが生成されます。この実行プランの生成時、@x の値は未知です。なぜならば、@x の値が決定するのは、バッチのコンパイルおよび select の最適化が終わって、実際にこのバッチが実行され、set ステートメントが実行完了した後だからです。select…

5