SQL Server における分散トランザクション 2

  神谷 雅紀Escalation Engineer   SQL Server における分散トランザクション 1 の続きです。   前回の投稿では、SQL Server における MSDTC の接続を確立する際の振る舞いと、コミットまでの動作を説明しました。本投稿では、ロールバック時のシナリオや異常系シナリオについて説明します。   分散トランザクションの流れ (前回からの続き)   8) トランザクションのロールバック   ロールバック前までの流れは、前回紹介したコミットの場合と同様です。   8-1) アプリケーションは、アプリケーション側 MS DTC に対して、トランザクションのロールバック (中断) を要求します。 8-2) アプリケーション側 MS DTC は、SQL Server 側 MS DTC に対して、トランザクションの中断を要求し、その要求は SQL Server に対しても行われます。 この時、Transaction is aborting トレース/拡張イベントが生成されます。 8-3) SQL Server でのロールバックが完了すると、その完了が SQL Server…

0

SQL Server における分散トランザクション 1

  神谷 雅紀Escalation Engineer     分散トランザクション 分散トランザクションとは、複数のリソースマネージャーで実行されるトランザクションを、ひとつのトランザクションとして実行するトランザクションです。       リソースマネージャー リソースマネージャー (RM) とは、トランザクションによって更新されるデータを管理しているコンポーネントです。通常は、SQL Server や Oracle などのデータベース管理システムです。   トランザクションマネージャー トランザクションマネージャー (TM) とは、トランザクションを管理し、各リソースマネージャーに対してトランザクションに関する指示を出すソフトウェアコンポーネントです。SQL Server は、トランザクションマネージャーとして、Microsoft Distributed Transaction Coordinator (分散トランザクションコーディネーター / MS DTC) を使用します。   SQL Server における分散トランザクション実行時のソフトウェア構成 SQL Server やアプリケーションは、MS DTC Proxy を使用して MS DTC とのやり取りを行います。 最も一般的な形は次の図のように、それぞれの Windows で動作している MS DTC を使用して分散トランザクションを実行します。 尚、通常リソースマネージャは複数 (上図のように右側のサーバーが複数ある構成)…

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

用語解説: 復旧、復元、修復

神谷 雅紀 Escalation Engineer 今回は、混同しやすい用語である「復旧」「復元」「修復」について解説します。 復旧 復旧 (英語では recover, recovery) は、データベース開始時に実行されるトランザクションのロールフォワード、ロールバックなどの処理を表します。 SQL Server は、多くのデータベースシステムと同様に、ログ先行書き込み (Write-Ahead-Logging, WAL) を行います。データベースファイルへの書き込みは、必ずトランザクションログファイルへの書き込みが先行されます。トランザクション完了時、トランザクションログへの書き込みは必ず同期されます。言い換えれば、クライアントが COMMIT を発行しても、トランザクションログへの書き込みが終わらないと、クライアントへは制御が返されません。一方、データファイルへの書き込みは非同期です。そのため、データベースクローズ時にデータファイルの内容が最新の状態であるとは限りません。データベース開始時には、トランザクションログを使用して、データファイルをトランザクションとして整合性のとれた最新の状態にするために、未完了トランザクションをロールバックしたり、データファイルへ未反映のトランザクションをロールフォワードしたりします。つまり復旧が必要になります。 データベースの開始は、SQL Server の起動時やデータベースのアタッチ時に実行されたり、WITH RECOVERY の指定された RESTORE DATABASE または RESTORE LOG ステートメントの実行時に実行されます。データベースが開始されると、Errorlog ファイルには “Starting up <database name>” と記録されます。 復元 復元 (restore, restoration) は、RESTORE ステートメントによってバックアップデータからデータベースを作成したり、復元中 (restoring) の状態にあるデータベースにトランザクションログを適用することを指します。 修復 修復 (repair) は、SQL Server のデータベースとして論理的に正常ではない状態になってしまったデータベースを、データベースとして使用可能な状態に戻すことを指します。 通常は、復旧に失敗し、データベースが未確認 (suspect) の状態となってしまったものの、そのデータベースのバックアップがなく、バックアップからデータベースを復元できない状況の場合に、最後の手段として、DBCC CHECKDB に修復オプションを指定することで修復します。…

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

IDENTITY プロパティ使用時の動作について

皆さん、こんにちは。 SQL Server/Windows Azure SQL Database サポートチーム の高原です。 今回は、SQL Server / Windows Azure SQL Database (以下 WASD) の何れでも使用可能な IDENTITY プロパティの動作について説明します。   [IDENTITY プロパティとは] IDENTITY プロパティをテーブル列に指定した場合、追加した列では、行が追加 (Insert) される毎に、指定された増分の値を基に、自動的に ID 番号を採番することが可能になります。そのため、ID を自動的に採番したい場合、IDENTITY プロパティを使用することにより、番号を採番する仕組みをアプリケーション側で実装する手間を省くことができます。   [IDENTITY プロパティの制限事項] IDENTITY プロパティは 非常に便利な機能なのですが、次の点が保証されていません。   1) 連続された ID 値が採番されることを保証していない。 パフォーマンス上の理由から 採番される ID 値がキャッシュ上に保持されているため、サーバーの再起動や、データベースの再起動が発生した場合、キャッシュ上に保持された ID 値が失われ、次回 行挿入時に、前回 挿入された値から非連続的な ID が生成される場合があります。 また、1つのトランザクション内で連続した値が必ず採番されることも保証されていないため、1 つのトランザクション内で連続した値を必ず採番する必要がある場合は、他のトランザクションから列の挿入が行われないよう、該当テーブルに対して、排他ロックを獲得するなどの対策が必要です。  …

0

統計情報更新処理をキャンセルした場合の動作

神谷 雅紀 Escalation Engineer インデックスの再構築や再構成を実行中にキャンセル (中断) した場合については、インデックス再構築と再構成の違いで触れていますが、統計情報を更新している最中に処理をキャンセルした場合はどうなるのかといった質問がありましたので、今回は、統計情報の更新処理をキャンセルした場合の動作について説明します。 ※ 以下の動作は SQL Server 2012 のものです。基本的には他のバージョンでも同じであると思われますが、明示的な確認は行っていません。   統計情報更新をキャンセルした場合の動作 統計情報の更新は、各統計情報ごとにひとつのトランザクションとして実行されます。ある統計情報を更新している最中にキャンセル (中断) した場合には、その統計情報を更新しているトランザクションも中断され、ロールバックされます。結果として、統計情報は更新前の状態に戻ります。 この動作は、拡張イベントの transactions.sql_transaction や SQL Trace の SQL Transaction イベントで確認することができます。     UPDATE STATISTICS ステートメントの場合 UPDATE STATISTICS は、個々の統計情報を指定して実行することも、テーブルを指定して実行することもできます。テーブルを指定して実行した場合には、そのテーブルに属するすべての統計情報が更新されます。 テーブル名のみを指定した UPDATE STATISTICS の実行をキャンセルした場合のキャンセル後の状態は、キャンセルよりも前に更新が完了している統計情報については更新後の状態、キャンセル時点で更新中であった統計情報、および、まだ更新が開始されていなかった統計情報は、更新前の状態になります。 テーブル名のみではなく統計名またはインデックス名も指定して実行した場合には、UPDATE STATISTICS をキャンセルすると、統計情報は更新前の状態に戻ります。 ただし、キャンセルが、統計情報更新トランザクションは完了しているものの、UPDATE STATISTICS ステートメントはまだ完了していないタイミングになることもありえます。その場合は、UPDATE STATISTICS をキャンセルしても統計情報は更新された状態になります。     統計情報の自動更新の場合 自動更新の場合も UPDATE STATISTICS の場合と同様に、統計情報更新トランザクションが実行されている最中にキャンセルした場合には、トランザクションはロールバックされ、更新前の状態に戻ります。 自動更新の場合は、明示的に…

0

DOPは並列クエリで使用されるスレッド数ではない

神谷 雅紀 Escalation Engineer 並列クエリの並列度または次数 (degree of parallelism, DOP) は、クエリを実行するために使用される総スレッド数もしくは最大スレッド数ではありません。 例えば、Gather Streams Parallelism オペレータをひとつ含むクエリが DOP = 4 で実行されると、クエリで使用されるスレッドは、Parallelism オペレータよりも上を担当するメインスレッド 1 つと下を担当する子スレッド 4 つの合計 5 スレッドになります。 DOP とは? DOP は、個々の Parallelism オペレータに作用し、クエリ内の各 Parallelism オペレータが子スレッドを作成する場合のスレッド数を規定します。max degree of parallelism や MAXDOP クエリヒントによって、この各 Parallelism オペレータが生成できる子スレッドの最大値を設定することが可能です。子スレッドが実際にいくつ生成されるかは、論理オペレータと指定されている DOP に加えて、その時点でのインスタンス内のスレッド使用状況に依存します。 並列クエリで使用される論理オペレータ Parallelism オペレータでは、子スレッド (Producer) から親スレッド (Comsumer) へのデータの受け渡しが行われます。受け渡し方法は、論理オペレータによって異なります。DOP により制限されるのは子スレッド (Producer) です。 Gather Streams…

0

NUMERIC/DECIMAL の演算結果の有効桁数と小数点以下桁数

  神谷 雅紀 SQL Server Escalation Engineer     numeric/decimal データ型は、有効桁数 (精度) と小数点以下桁数 (スケール) が固定ではないため、演算を行う場合には考慮が必要です。     NUMERIC/DECIMAL の演算結果の精度とスケールの決定方法   numeric/decimal の演算を行った場合、その結果の精度とスケールは以下のようになります。 e1, e2 はそれぞれ以下のように定義されているとします。   e1 numeric(p1, s1) e2 numeric(p2, s2)   演算 結果の精度 結果のスケール e1 + e2 max(s1, s2) + max(p1-s1, p2-s2) + 1 max(s1, s2) e1 – e2 max(s1, s2) + max(p1-s1,…

0