SQL Azure

今後、改善が入るとおもうので、あくまでも本日時点の考慮ポイントとなります。

1.新規にHyperscale環境を作成し利用する

現在、128GB以上を使用しているDTUモデルのAzure SQL Database からHyperscale環境に移行をしようとしていて、かつ少しでも性能をよくしたい場合の話になります。

128GB以上を使用しているデータベースから移行する場合は、新規にHyperscale環境を作成し、データをMigration Wizardなどクライアントツールを使用してデータを移行させて、アプリケーションの向き先を切り替える対応が最もHyperscale環境の性能が良くなります。

Azure Portal の設定から、モデルを切り替えた場合は少し性能的に不利になります。

Azure SQL Database ではデータファイルのサイズが1TBと128GBの2種類が提供されています。
そして、128GBのデータファイルを使用したほうが、性能的にちょびっと有利になります。

128GB以上を使用しているデータベースから移行すると、データベースファイルは1TBが使用されてしまいます。

新規環境にデータを流し込むことで、128GBのデータファイルが選択され、追加されていくので性能的に有利になります。
現在のところ、データファイルサイズを明示的に選択はできないので、マイグレーションは新規にするのがよさそうです。

※性能影響なんであるの?どれぐらいあるの?は、きっとムッシュ案件。

2.CPUコア数の選択

P15 4000DTUのCPUコア数は通常32コアになっています。
その環境からHyperscaleに移行するなら、40コアでいいのかなと思うのですが、ちょっと事情が違うかもしれません。

ハイパースレッディングがらみで、DTUの32コアは、Hyperscaleの64コア相当になるかもしれません。
(これは、まだ検証中)

なので、4000DTUから移行するときには、80コアがよさそう。
なんとなく80コアを選ぶと、CPU使用率が2/3になったので、間違ってはなさそう?

3. DTUからHyperscaleへの移行時間

3TBぐらいあって、時々書き込みが発生するDTU P11からHyperscale 第4世代6コアに、Azure Portalから移行させました。

設定変更ボタンを押してから5時間程度かかって、最終処理、環境の切り替えで約8分ほどオフラインになった後、Hyperscaleに変更されました。
設定で対応する場合には、8分オフラインになることを見越して計画をしましょう。

SQL Azure

Azure SQL Database のジオレプリケーションに関して、推奨事項とそれに合わせたシステム制限がリリースされたので紹介します。

新しいアクティブ geo レプリケーションの最適化が Azure SQL DB でまもなく運用開始予定

ジオレプリケーションでは、PrimaryとSecondaryをログを使用してデータ連携がされます。
また、異なるインスタンスサイズを使用することができます。

PrimaryをP15、SecondaryをP11という構成を組むことができます。

image

しかし、Primaryでヘビーな更新が実施される場合、Secondaryのインスタンスサイズが低い場合、更新処理が追い付かない場合があります。
Azure SQL Databaseでは、Geo-Replicationがレプリケーションラグが40分を超えた場合は異常事態として、Reconfigurationをして同期を再実行します。

また、そうでなくても動機が追い付かない場合、レプリケーションを切り替え時にデータのロストが多くなるなどの問題がありました。

2019/07/01以降、PrimaryとSecondaryでインスタンスサイズが異なるGeo-Replicationを使用している場合、必要に応じて、Primaryの性能を制限してレプリケーションラグが広がりすぎないようにする対応が入ります。

Primaryのスロットリングを受けたくない場合は、インスタンスサイズを合わせる必要があります。

SQL Azure

Azure SQL Database でDTUモデルのデータベースを使用していたのですが、Azure SQL Database Hyperscale に移行することにしました。

さっそく、移行処理をAzure Portalからしたのですが、エラーが出てしまい移行できませんでした。

現在、Hyperscaleには以下の制約があります。

  • Azure SQL Database Hyperscaleは、長期的なバックアップ保有期間 (LTR)をサポートしていないため、有効にしていると移行できません。
  • 現在、バグで、過去に一度でも長期的なバックアップ保有期間 (LTR)を有効にしたことがある場合、移行できません。
  • これは既知のバグで修正がまもなくされるそうです。
  • 2019/7/7(太平洋時間)にデータセンター内で展開されるので、それ以降に再度試せば問題なく移行できるはずです。

SQL Azure

Microsoft Ignightで、Azure SQL Database Hyperscaleが発表されました。
ドキドキが止まらないので、早速まとめてみました。

もう間も無く、2018/10/1からPublic Previewが開始されるようです。
GAは、いつだろー?

特徴

  • Hyperscaleは、ストレージが根幹技術にあたるサービスです。
  • 最少1TB〜100TBまでのデータベースサイズを使用できます。
    • 容量だけでなくI/O性能の改善も含めたサービスです。
  • Data StoreサーバーとLogサーバーが誕生し色々すごくなっています。
    • Time to Restoreは健在
    • バックアップはストレージスナップショットで担保
    • リストアも10分程度を目指す
  • コンピューティングとストレージが分離されたモデル
    • プライマリコンピューティング、セカンダリコンピューティング両方とも柔軟に変更可能
    • セカンダリコンピューティングはプライマリコンピューティングと同じデータストレージをみる。
      • 同じ!同じです!同じなのです。
    • セカンダリコンピューティングは読み取り専用で、プライマリコンピューティングと同じエントリポイント。(接続先サーバー名が同じ
    • 接続の切り分けは、接続文字列に「Read_Only」「Read_write(既定)」を付けるかどうかの差。

vCoreモデルをベースとしているのでDTUモデルでは使用できません。
マイグレーションなどは、インスタンスサイズ変更と同等の手順で実施できるようになるようです。

仕組み

下のスライドのスクリーンショットをみてください。

ストレージが根幹のサービスだけあって、仕組みスライドもストレージがメインとなっています。
バックエンドにデータストア層があって、そこをコンピューティングが参照する。
プライマリもセカンダリも同じデータストアを見るので、データ反映タイムラグがレプリケーションよりも断然抑え込まれています。

サービス帯

ここで掲載されています。
一番大きいのは80コアモデル。

Storage Typeがまだ、LOcal SSDとなっているのはご愛嬌。

まとめ

Azure SQL Databaseが最大容量4GBで苦しんでた皆様が解放される日はもう間も無くです!
そこまで、なんとか生き延びましょう(^ ^)

SQL Azure

MSSQL Tiger Teamが投稿したBlogを基に整理した内容です。

可容性グループはSQL Server 2012で初めてリリースされました。
可容性グループセカンダリレプリカの各データベースではトランザクションログのredoは一つのredoスレッドで制御していました。
このredoモデルは、serial redoと呼ばれていました。

SQL Server 2016で、redoモデルが強化され、redo操作を分けるためにデータベース毎に複数の並列redoワーカースレッドになりました。さらに各データベースは、ダーティページディスクフラッシュIOを管理する新しいヘルパーワーカースレッドがあります。
この新しいredoモデルは、parallel redoと呼ばれます。

新しいparallel redoは、SQL Server 2016から既定の設定で、小さいトランザクションが並列に大量に実行されるケースではredo性能の改善ができました。データの暗号化、データ圧縮の有功などのCPU負荷の高いトランザクションredo操作は、serial redoと比較してparallel redoの方が高いスループット(Redone Bytes/sec)が得られます。
さらに、間接的チェックポイントがparallel redoがヘルパーワーカースレッドにディスクIOや遅いディク用のIO waitを委任し、メインのredoスレッドがセカンダリレプリカでログレコードをより受信できるようにします。redo性能を向上させます。

しかし、parallel redoはマルチスレッドモデルでコストが高いです。

  • メインredoスレッドは、各トランザクションログredo操作の実行を停止しますが、各トランザクションログを列挙し、parallel redoワーカースレッドにディスパッチすることを担当します。テーブル(行数の小さい)の狭い範囲の行へのDMLトランザクションのredoのようなCPU負荷がかからないログredo操作のケースでは、それらのログをディスパッチするコストは非常に重いです。
  • 新しいレコードを挿入するためにページを分割するシステムトランザクションは、parallel redoワーカースレッド間でPARALLEL_REDO_TRAN_TURN waitを利用します。頻繁にinsert操作をする場合、かなりparallel redo性能を遅くします
  • 読み取りセカンダリレプリカでread-onlyクエリを実行すると、クエリスレッドはログredo操作を一時停止しようとし、DIRTY_PAGE_TABLE_LOCKでredoワーカースレッドと連携する必要があります。redoとクエリ性能が両方遅くなります。

性能研究に基づくと、次のトランザクションワークロードまたはSQL設定が既定のparallel redo モデルより良い結果となります。

  • 多くの並列の小さいトランザクション
  • 間接的なチェックポイントを伴う負荷のかかるログredo操作(データ暗号化またはデータ圧縮)
  • 読み取りをしないセカンダリレプリカ、またはたまにread-onlyクエリを読み取りセカンダリレプリカで実行する場合

次の場合は、serial redoに切り替えた方がredoスループットがよくなります。

  • 一般的なInsertや同時実効性が限られている長い時間実行するトランザクション:典型的な例は、大きなテーブルのクラスター化インデックスのオンラインIndex再構築
    • parallel redoモデルでの兆候
      • PARALLEL_REDO_TRAN_TURN waitがinsert処理量に比例して生成されます。多くのInsertが多くのpage splitを起こし、PARALLEL_REDO_TRAN_TURN waitを呼びます。
      • 性能カウンターで監視できます。(SQLServer:General Statistics、User Connections)または、プライマリレプリカのDMV(sys.dm_exec_connection、sys.dm_exec_sessions)
  • 頻繁で、長時間のread-onlyクエリをセカンダリレプリカのデータベースに実行する必要がある場合
    • parallel redoでの兆候
      • 頻繁なDIRTY_PAGE_TABLE_LOCK wait
      • 性能カウンターで監視できます(SQLServer:Database Replica、Redone Bytes/sec)クエリを実行している時としてない時でredoスループットを比較します。
  • 小さなデータセットのデータページにセカンダリレプリカでread-onlyクエリが高頻度でスキャンし、プライマリレプリカで頻繁に同じデータセットに変更を加える。クエリとredoスレッド両方に劇的な性能劣化を与えます
    • parallel redoでの兆候
      • 大量のDPT_ENTRY_LOCK wait
      • 最悪のケースでは、Latch timeoutによりSQL ErrorログにTimeout occurred while waiting for latchと記録されます。

新しいWaitの種類

いくつか紹介されていますが、個人的に興味があるものをピックアップ。

  • DPT_ENTRY_LOCK
    • ユーザークエリスレッドから追いつくためのREDOがあるdirty page entryへのアクセスを制御するロックがある時に発生します。
    • parallel redoワーカースレッドとユーザークエリが同時に同じdirty page entryにredo処理をした時のみ発生します。

補足

SQL Serverの事例として紹介されていますが、Azure SQL Database のgeo replicationを使用してセカンダリデータベースを使用しているケースでも同様の問題が発生します。
P15を使っていると、ジオレプリケーションはparallel redoが採用されているので、ここで紹介されたことと同じ問題が発生するのです。