SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

AlwaysOn Availability Groups のセカンダリレプリカと行バージョンについて

leave a comment

AlwaysOn Availabiility Groups のセカンダリレプリカは読み取り専用のデータベースとして利用することが可能です。
image

プライマリとセカンダリレプリカはデータの同期をしているため定期的にデータの更新が発生します。
Tech Ed の DBI404 のセッションスライドでは以下のように構成が説明されています。
image
データの更新が発生するということはそのタイミングで同期対象のレコードに対してロックがかかるので読み取り時に頻繁にブロッキングが発生しそうですが、セカンダリレプリカでは [行バージョン] が自動的に使用され、読み取りに対する待ちが軽減される仕組みがとられています。

今回はこのあたりを見ていきたいと思います。

■セカンダリレプリカと行バージョン


セカンダリレプリカと行バージョンについては以下に記載されています。
Read-Only Access to Secondary Replicas (AlwaysOn Availability Groups)

この中に以下の記載があります。

All read operations are supported by row versioning and are automatically mapped to snapshot isolation transaction level, which eliminates reader/writer contention.

読み取りの操作では行バージョンが使用され、自動的にスナップショット分離レベルとなり、読み取りと書き込みの競合が緩和される旨が記載されています。
DB404 でも 2 スライドで解説がされています。
image
image

それでは実際に見てみたいと思います。

現在はこのような形で可用性グループが設定されています。
image

この状態でプライマリに対して更新を行い、その時のセカンダリの行バージョンの使用状況を確認してみます。
更新がかかっていない状態では行バージョンのバージョンストアのページ数は 0 となっていますが
image

更新をかけるとページ数が増加します。
image

行バージョンが使用されていることは DBCC PAGE からも確認することが可能です。
Record Attributes が NULL_BITMAP VERSIONING_INFO となっており、Version Information に tempdb のどこに行バージョンの情報を格納しているかが表示されています。
image

セカンダリレプリカでスナップショット分離レベルを設定しなくてもデフォルトでこのような動作となります。
# 使用有無を制御できないようです
image

自動でこのような動作となるため、tempdb のサイズには少し注意をする必要がありそうですね。

プライマリで更新がされていてもセカンダリの読み取りを効率よく実施するための実装だと思うのですが調べると興味深いですね。

Share

Written by Masayuki.Ozawa

8月 4th, 2011 at 8:29 am

Posted in SQL Server

Tagged with , ,

Leave a Reply