SE の雑記

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

PASS Data Community SUMMIT 2021 で SQL Server 2022 関連の情報の公開が行われています

leave a comment

2021/11/10 から開催されている PASS Data Community SUMMIT 2021 で Ignite 2021 に続き、SQL Server 2022 関連のセッションが実施され様々な情報が公開されています。

今回が、Redgate が PASS のコミュニティオーナーになってからの初めての開催ですね。
今回はオンライン開催で無料で参加 / 登録ができますので、興味のある方は参加してみてはいかがでしょうか。

PASS のキーノートでは様々な新しい発表があるのですが、今回は、Ignite 2021 からの間隔が短いので、Day 1 Keynote — Bridge to a new universe: the end-to-end Azure Data Platform については、Ignite 2021 と同等の発表となっていたように思えます。

 

PASS Data Community Summit 2021 では、Ignite 2021 内でアナウンスのあったように、SQL Server 2022 に特化している個別セッションが開催されています。

Ignite 前後で発表された内容については Ignite 2021 で SQL Server 2022 がアナウンスされました でまとめていますので、本投稿は PASS 開催以降に新しく発表された内容に注目していきたいと思います。

なお、PASS 2021 の各セッションのスライドについては、各セッションの URL 内の他に、 Bob Ward の One Drive で公開されているようです。

Contents

Introducing SQL Server 2022

SQL Server 2022 の基本的なセッションとなり、SQL Server 2022 の概要を把握することができます。

といった内容で、Ignite 2021 の開催に合わせていくつかの情報が公開されています。

本セッションの内容は、これらの情報や、以降でまとめているセッションの内容と重複している箇所がありますので、本セッションで新しいと思った発表にフォーカスをあててまとめておきたいと思います。

 

When and how

image

Public Preview / GA については CY 2022 になるというアナウンスが行われています。2021 年内は Private Preview のみの提供となるようですね。

Public Preview のタイミングについては、QA でも触れられていました。

  • Q : Is there a way for consultants to get private preview access to prepare and try it out for clients ahead of GA?
  • A : The private preview Early Adoption Program (EAP) is limited to customers and partners that want to actively test and preferably deploy SQL Server 2022 in production by General Availability. At public preview (Spring 2022) anyone will be able to access it.

Spring 2022 が Public Preview として計画されているタイミングとなるようです。

エディションに関する情報についても Public Preview での発表となるようで、エディション構成や、エディションで使用できる機能についてのアナウンスは当面無いようです。

 

  • Q : You’ve talked a lot about the SQL Server engine. What about changes to SSIS, SSRS, SSAS for 2022?
  • A : These announcements are all focused on SQL Server. SSAS, SSRS, SSIS have different release rhythms.

データベースエンジン以外の機能についても、それぞれの機能でしかるべきタイミングでのアナウンスとなるようです。

 

  • Q : What will be the minimum supported version of Windows Server for MSSQL 2022 on prem?
  • A : We will support all Windows Server versions still in mainstream support. This means Windows Server 2016 will be minimum.

サポート OS については、メインストリームサポートの Windows が対象となるようで、最小は Windows Server 2016 だそうです。

 

Query Store and Intelligent Query Processing

image

クエリストアと IQP ですが、クエリストアから線が出ている IQP の種類はポイントとなるようで、DOP Feedback / CE Feedback については、クエリストアとの連携を行うことで実現される機能となるようです。

PSP Optmization については、クエリストアと線がつながっていないため、クエリストアとは切り離されクエリプロセッサで実現されている処理となるようです。 (実行の状態はクエリストアからも確認できるようで、実行状態の把握という観点では連携はしているのですが、機能を使用するためにはクエリストアを有効にする必要はないようです)

 

Intelligent Query Processing (IQP) NextGen

image

SQL Server 2022 でで実装される IQP の種類が解説されています。

どの機能がクエリストアとの連携が必要 (クエリストアが有効になっている必要がある) になるのかは、このスライドもわかりやすいですね。

互換性レベル 160 を使用する必要のある機能も明記されています。

PSP Optimization / CE Feedback については、互換性レベル 160 が必要となりますが、

  • 2022 にアップグレードすることで使用できる機能
  • 互換性レベル 140 以降で使用できる機能

というように、既存のアップグレード環境でも SQL Server 2022 のクエリ実行効率の向上の恩恵を受けることができるようです。

 

Approximate Percentile

APPROX_COUNT_DISTINCT (Transact-SQL) の類似機能ですかね。

大量のデータが格納されているテーブルに対して、概算で値を算出することと引き換えに、高速なクエリ実行を可能にする関数のバリエーションが増えるかもしれません。

 

Query Compilation Replay

この IQP の機能について解説が行われたのは本セッションだけのようでした。

クエリストアにコンパイルのステップを記録することで、再コンパイルが発生した場合に、クエリストアに記録されているこの情報を活用することで、コンパイルを高速に処理することができるというようなものとなるようです。

これが、コンパイルストームと呼ばれる問題への解決につながる機能になるという期待があるようです。(過度なコンパイルが発生している環境への最適化の一つのアプローチとなる形でしょうか)

 

Parameter Sensitive Plan (PSP) Optimization

PSP Optmization については、Ignite の発表より詳細にデモで解説が行われていました。

パラメーターによって異なるプランとしてキャッシュ / クエリストアでも認識されることは以前のデモでも実施されていましたが、本セッションでは、クエリストアに格納された、詳細なクエリテキストの表示も紹介されています。

image

PSP Optimization により、パラメーター違いの同一のクエリが実行された場合、PSP Optimization による最適化が行われることで、「PLAN PER VALUE」というヒントが自動的に追加されていることの解説が行われていました。

 

実行されたクエリが異なる query_id として 認識されていますが、同一の query_hash であり、異なるクエリヒントが指定された別のプランとしてクエリストア上に記録されていることが確認できますね。

image

PSP Optimization により、同一のクエリハッシュでも、パラメーター毎に異なるプランとしてキャッシュができるようになります。

しかし、クエリストアや、クエリキャッシュ上に記録される情報は増えると思いますので、有効化したときのオーバーヘッドとメリットのバランスがどのようになるのかは意識しておきたいですね。

 

More engine innovations

image

このスライドで解説された新しい内容としては「New granular permissions and roles」がありそうです。Purview と連携し、アクセスポリシーを設定する際に活用する新しいロールが実装される感じでしょうか。

 

Always Encrypted の機能向上については、QA で触れられていました。

  • Q : what new features are in Always Encrypted?
  • A : Always Encrypted with secure enclaves in SQL server 2022 will support a few additional confidential query capabilities that are already supported in Azure SQL DB (but not in SQL Server 2019). They include JOIN queries, GROUP BY clause and queries in string columns using UTF-8 collations.

2019 ではサポートされておらず、SQL Database でサポートされるようになった機能が 2022 でも利用できるようになるようです。

 

可用性グループについては興味深い QA がありました。

  • Q : Will we be able to put system databases into an Availability group?
  • A : That is not a current feature of SQL Server 2022.

Big Data Cluster や Arc MI にはシステムデータベースを可用性グループに含める機能が含まれており、「master」「model」が可用性グループに含まれた状態で展開が行われており、ログインやジョブの情報についても Always On の機能で同期が行われるようになっています。

この機能については、現時点では SQL Server 2022 には実装される予定はないようですね。(この辺の連携、k8s 上に展開されているコントローラーも絡んでいそうなので、シンプルな SQL Server では実装できないとういうのもあるのかもしれませんが)

 

Data lake virtualization and object storage

image

データ仮想化の新機能については、Ignite ではなく、Introduction to SQL Server 2022 (Ep.1) | Data Exposed では触れらていましたが、詳細が解説されるのは今回が初めてではないでしょうか。。

SQL Server 2016 で導入された PolyBase が SQL Server 2022 でも更に進化します。

SQL Server 2019 で ODBC のサポートが追加されましたが、SQL Server 2022 では、REST API のサポートが追加され、REST 経由で ADL Gen2 / Azure BLOB / S3 に対して接続して、クエリ実行ができるようになります。

この REST API サポートは OPENROWSET / EXTERNAL TABLE だけでなく、バックアップ / リストアでも活用でき S3 互換の環境に対してバックアップを取得できるようにもなるようです。

  • Q : Will SQL 2022/Polybase Vnext introduce complex data types like structs or arrays commonly found in Big Data products such as Hadoop Impala?
  • A : Hi James,
    Not adding engine-level complex data types to SQL Server but for Polybase we’re adding REST API access to parquet, JSON, CSV, Delta formats and for connectors, s3, ADLS Gen2, Azure Blob Storage.

S3 対応は、REST API のコネクタとしてビルトインされるようですが、REST API アクセスにどこまで自由度があるのかは気になりますね。(ビルトインのコネクタ以外を使用することができるのか?)

imageimage

External Data Source を作成する際に、「s3://」で Location が設定できるようになっていますね。デモでは、S3 互換のオブジェクトストレージとして、MinIO が使用されているようです。MinIO であれば手元で手軽に検証できて便利そうですね。(BLOB 連携を検証する際には、Azurite が使えるのかが気になりますね)

image

 

あとは PolyBase の作法に則せばアクセスが可能です。

image

image

 

バックアップについても BLOB を使用する場合と同じ方法ですね。

image

 

Language enhancements for developers

image

基本的なクエリ実行機能についても改善が行われるようです。

こちらについては、具体的な機能については解説が行われていなかったので、今後もキャッチアップが必要ですね。

  • Q : So there will be new JSON functions. Does that mean there will be a JSON data type?
  • A : We have nothing to announce at this moment.

JSON については、QA でも触れられていたのですが、どのような内容が含まれるのかは現時点ではアナウンスできる内容は無い様です。

 

Azure SQL and SQL Server 2022: Intelligent Database Futures

SQL Sever 2022 のインテリジェントなクエリ処理ではどのような改善が行われるかについての解説が行われています。

SQL Server 2022 では、CTP 1.0 から使用することができ、Azure SQL Database では、2022 年に Public Preview が開始されるとのことです。

この領域では、SQL Server 2022 でクエリストアがデフォルトで有効化されたことで、クエリストアの情報を有効に活用しながら、過去の実行情報のフィードバックや永続化を行うことができるようになります。

 

SQL Server 2022 Intelligent Query Processing

image

  • Parameter Sensitive Plan (PSP) Optmization
  • Cardinality Estimate (CE) Feedback
  • Degree of Parallelism (DOP) Feedback

については以前からアナウンスがありました。

それ以外の IQP の機能として

  • Compilation Replay
  • Approximae Percentile
  • Feedback Persistence

が搭載されることがアナウンスされています。(本セッションでは、Compilation Replay についての解説はありませんでした)

 

Query Store ON by default

image

SQL Server 2022 では新規作成のデータベースではクエリストアがデフォルトで有効となりますが、それについての言及がありました。

SQL Server 2016 で実装されたクエリストアですが、SQL Database では、デフォルトで有効となっており、SQL Server についても新しいバージョンがリリースされるたびに機能の改善が行われ、カスタムキャプチャポリシーなどによる取得情報の制御が可能となりました。

Azure ではデフォルトで有効な状態となっており、何年も実績があり、クエリストアの情報取得の負荷を調整 / 動作を制御するための機能が充実してきたため、SQL Server 2022 からはデフォルトでクエリストアが有効となったようです。

QA でもこの点については触れられていました。

  • Q : we had issues w Query Store "on" across the board, so we leave it "off". Pedro mentioned enhancements, size constraints & so on. have QS addressed all the previous issues?
  • A : We believe we have addressed most of the common concerns to turn this on by default for new databases in SQL Server 2022

2022 の IQP では、いくつかの最適化は Persisted となっており、Persisted や Feedback 系についてはクエリストアとの連携となるように見えます。

 

クエリストアを中心に新しい機能の実装が行われていることに対しての、メリットとリスクのバランスについては、Preview での一つの注目点ともなっているようです。

  • Q : Lot of new functionality build around query store. Is there risk of it starting slow things down?
  • A : Definitely an engineering challenge to keep this balanced (overhead vs. reward). That is in our focus over preview.

 

クエリストアについては、以下のような要望もあるようです。(TF7745 はデータベースのシャットダウンを行う際に、クエリストアをディスクにフラッシュしないことで、クエリストアのデータの損失と引き換えに再起動等の速度を上昇させるものです)

  • Q : Can we have the TF 7745 behavior on by default in SQL Server 2022?
  • A : Thank you for this quesiton. We will look into if this is possible during the release

 

 

Query Store Hint

imageimage

SQL Database で使用することができるようになっている、クエリストアヒント が SQL Server では、SQL Server 2022 から利用することができるようになります。

SQL Server 2022 では、クエリストアがデフォルトで有効化されていますので、クエリストアヒントも効果的に活用を行うことができるのではないでしょうか。

クエリストアヒントは、実行されているクエリ内に記載されているヒントより優先されるということなので、様々なクエリの調整に活用できるかと。

 

現状、クエリストアヒントは、T-SQL での設定となりますが、GUI での操作も可能になる予定とのことです。

  • Q : Will SSMS give you an easier way of doing the query hints? Identify the query quickly and change it?
    Hi Shahryar,
  • A : Yes we plan on graphical methods to manage Query Store hints.

 

 

Query Store for Secondary Replicas

image

AlwaysOn 可用性グループベースの高可用性環境では、クエリストアの情報はプライマリの情報のみとなっており、セカンダリで読み取りワークロードを実施している場合、セカンダリ上で実行されているクエリについては、クエリストアにキャプチャは行われず、クエリキャッシュから情報を取得する必要がありました。

クエリキャッシュからの情報取得はクエリストアより情報の取得の柔軟性が低く、クエリの問題が発生した場合の効率が低く、独自のクエリ情報の仕組みを実装する必要があるケースがあったのですが、SQL Server 2022 では、セカンダリレプリカでクエリストアが使用することができるようになるため、読み取りワークロードでセカンダリレプリカを使用している場合のクエリの調査の効率が大きく改善されます。

読み取りセカンダリでクエリが実行されると、クエリストアに該当する情報をプライマリに転送し、プライマリのクエリストアに書き込むというような流れになるようです。

クエリストア内では Replica Name が保持されるようになり、どのレプリカで実行されたクエリなのかが判断できるようになるようです。

image

セカンダリレプリカのクエリストアは、プライマリで上記のようなクエリを実行することで設定ができるようです。

 

image

セカンダリのクエリストアでもプラン強制はできるようで、どのレプリカに対してプラン強制を行うかはある程度制御ができるようになるようです。

 

Parameter Sensitive Plan (PSP) Optimization

現在の SQL Server では、クエリテキストに対して一つの実行プランがキャッシュされるため、使用されるすべてのパラメーターに対して最適ではなく、パラメータによってはキャッシュされているクエリでは著しく性能が劣化するという可能性があります。

image

この問題を Parameter Sensitive Plan  (PSP) または、パラメータースニッフィングとよばれ次のドキュメントなどで解説が行われています。

PSP プラン最適化はこのような問題に対してのアプローチの一つとなるものです。

 

image

現状の SQL Server 2019 までは、PSP に対してのワークアラウンドとしては次のようなものが考えられるかと思います。

  • クエリをリコンパイルさせる (COMPILE ヒントや統計情報の更新)
  • パラメーターに使用する値を調整 (OPTIMIZE FOR で特定のパラメーターを想定したプランを生成)
  • パラメータースニッフィングを無効にし、統計情報ベースのでパラメーターの推測にする (UNKNOWN)
  • 特定のプランを強制
  • ヒントで調整
  • 動的なクエリによる実行

というような対応を実施することで、PSP (パラメータースニッフィング) に対しての対応が行われていました。

 

image

 

SQL Server 2022 では、互換性レベルを 160 に設定することで、PSP Optimization を使用することができるようになります。

PSP については、クエリプロセッサにビルトインされた機能となるようで、クエリストアの有効化は必要ないようですね。

  • Q : Is PRP enabled on read-only secondaries that have query store enabled?
  • A : PSP is built into the QP. It doesn’t require Query Store

 

PSP Optimization では、一つのパラメーター化されたステートメントに対して、複数のプランキャッシュを生成することができるようになり、パラメーターの値に応じた実行プランをキャッシュできるようになります。

これにより各パラメーターに応じた実行プランがキャッシュされるようになり、特定のパラメーターで効率が悪いクエリの実行頻度を減らすことができるようになるようです。

ただし、「各パラメーターごとにプランがキャッシュ」されることによる弊害についても、設計上の考慮点として指摘が行われています。各パラーメーターごとにプランをキャッシュするということは、クエリのキャッシュ領域が従来と比較して肥大化する可能性があります。そのため、キャッシュの肥大化を抑えるためにプラン数の制限は行われるようですが、クエリのキャッシュ領域でメモリが使用されることに対しての影響については考慮する必要があります。(PSP によるメリットが他の処理に影響を与えないことの考慮)

PSP によるキャッシュの肥大化を防ぐということも、機能実装の中でも注目点となっているようです。

  • Q : With PSP should I worry about new memory problems or is it handled somehow?
  • A : we absolutely handle this and do not bloat your cache

 

内部的な上限は設けられており、述語 / 変数 / プランの数に基づき制御がされるようです。

  • Q : Is there a maximum number of plans that will be generated per unique query? Will this feature be throttled if the plan cache gets too large?
    Hi Bryan,
  • A : There will be a limit. Pedro’s session will go into some details on this – but we’ll base that limit internally on the number of high skew predicates and associated variants/plans.

 

また、クエリストアのプラン強制と互換性があるようですので、PSP Optmization だけでなく、従来のアプローチとの併用 (または、クエリストアヒントの活用) についても、考慮しておく必要があるのではないでしょうか。

 

Predicate selection

述語のどのパラメーターを PSP によるリスクのあるパラメーターと判断するかについては、等値述語 (=) / 統計情報が考慮されているようです。

image

利用可能な述語のうち最大で 3 種類までが、指定された内容によって実行効率を低下させるリスクのあるパラメーターとして利用されるのでしょうかね。

 

Dispatcher

ディスパッチされたプランは、データの分布に大きな変化があった場合には再構築されるとのことで、PSP Optmization は、単純にパラメーターごとにクエリをキャッシュするのではなく、キャッシュした後の運用面での考慮も行われているようですね。

検証する際には、これらの動作 (通常の動作と同様で各クエリへ数にのキャッシュについて、必要に応じて再コンパイルされる) についても意識しておく必要があるかもしれません。

実行プラン内の情報にも追加があり、Dispatcher というセクションが追加されるようです。

image

 

Query Variant

各クエリ変数は個別のクエリの実行プランを持つことになり、これらの実行プランはクエリストア内の情報として区別が行われます。パラメーターが異なっていてもクエリハッシュは同一となるため、「該当のクエリの分析」については、クエリハッシュを基にして十すればよいようです。

QueryPlan の要素内に、QueryVariantId が追加され、どのクエリ変数が使用されている場合のプランなのかの判断ができるようで鵜s。

image

 

 

image

パラメーターを範囲で使用している場合の PSP Optimize のフローはこのようになるようです。パラメータの範囲によって、適切なメモリサイズで動作するようになるというのも同時実行性の観点ではポイントとなりそうですね。

 

Memory Grant Feedback – Persistence and Percentile

image

SQL Server 2017 で、バッチ モード メモリ許可フィードバック という機能が、列ストアを対象にして実装され、2019 になって行ストアも対象になったことで、クエリで使用されるメモリの動的な調整が様々なケースで可能となりました。

この機能が SQL Server 2022 で Persistent / Percentile という 2 つの観点で機能向上が行われるようです。

 

Persistence

image

従来までのメモリ許可フィードバックは永続化されていないため、キャッシュアウトやフェールオーバーが行われると、メモリの調整を行ったという記録が失われ、メモリの調整には再度同様のワークロードが実行された後の再学習が必要でした。

この部分が、クエリストアと連携することで、永続化が行われるようになり改善されるようです。

 

Fixing Oscilation

imageimage

メモリ許可フィードバックで、異なるパラメーターが指定され、メモリ付与の上下の揺れ幅が続き、適切なメモリサイズとならないような場合の対応も行われるようです。

揺れ幅が大きい場合、過去の実行時のメモリの使用履歴に基づき、メモリ許可サイズを平準化し、パーセンタイルベースの計算で、メモリがあふれることを最小限に抑えるように最適化が行われるようです。

メモリ許可フィードバックを無効にして対応を行うのではなく、最適ではないかもしれませんが、より影響が少ない状態にすることができる形でしょうか。

この機能が使用された場合には実行プランの「MemoryGrantInfo」の「IsMemoryGrantFeedbackAdjusted」に「YesPercentileAdjusting」が出力されるようになるようです。

image

 

CE Feedback

ここは私の理解も低いところなので中々に厳しいです…。(クエリエンジン回りはそもそもとしての理解度が低いのですよね…。)

image

CE (Cardinality Estimation : 基数推定) はクエリオプティマイザがクエリプランを生成する際に、各操作によりどれくらいの行が対象となるのか (推定行数) を算出するためのプロセスであり、SQL Server のバージョンの進化に合わせて基数推定にも一部変更が入っています。

ドキュメントとしては次のドキュメントが公開されており、SQL Server 2014 で新しい基数推定モデルが導入された際に様々な情報が公開されていたのではないでしょうか。

SQL Server 7.0 から始まった CE モデル70 からはじまり、SQL Server 2014 の互換性レベル 120 で導入された CE モデル 120 以降は、各互換性レベルに対応した CE モデルが導入されており、行数の推測の方法もバージョンによって進化しています。

 

クエリのコンパイル時には、基数推定により、各種情報を基にして、処理対象となる行数の予測を行い、実行プランを生成しますが、この時に行数として推測された内容によっては、効率の悪い (品質の悪い / 最適解ではない) プランにつながる推定が行われている可能性があります。

データの推測を行う場合、一つのモデル (パターン) による推定だけでは、すべてのシナリオに適応することができないというのが、今日の基数推定の課題となっています。

この問題に対して SQL Server 2022 のチャレンジが「CE Feedback」となるようです。

 

image

CE Feedback では、どの CE モデルが適切なのかを、過去の実行の情報から学習し、より正しい推測を適用するためのフードバックを行うことができるようです。

推測が正しくない場合は、新しい CE モデル (異なる基数推定) を検証し、それにより効率が良くなるかをテストし、効果がある場合には実行プランを置き換えるというような動作となるようです。

これにより、現時点のインテリジェントなクエリ処理では実装されていない、クエリの実行効率が後退する原因となりうる、次のようなシナリオに対応ができるようになるとのことです。

  • Independence vs correlation assumptions
  • Join containment assumptions (simple vs base)
  • Row goal

image

CE Feedback については互換性レベル 160 が必要となるようです。

 

パフォーマンスの低下に発展する、重大なモデル推定エラーとなる場合にのみフィードバックを適用し、既存のクエリ調整の機能との併用が可能となっているようです。

フィードバックについては永続化され、効率が低下した場合 / キャンセルしたクエリは後退したとみなされ、フィードバックを戻す機能も含まれるようですね。

 

image

上述の処理効率の低下は、既存の機能である上記のクエリで有効にできる自動チューニングの機能でも同様の考え方が用いられています。

自動チューニングにより強制されたクエリについても、以降のクエリで実行効率が低下した場合は、強制をキャンセルするという処理が行われています。今回の CE Feedback も同様の考えとなると思いますが、自動チューニングを有効にしておく必要があるのかは少し気になりますね。

 

CE Feedback 向けの拡張イベントがあり、これらのイベントを確認することで、CE Feedback の動作が行われたのかを確認することができるようです。

image

 

デモでは、次のようなクエリの実行が行われていました。

image

 

これにより、拡張イベントでは次のようなイベントが検知され、フィードバックによるヒントの分析と、それによる効果の確認が行われているようです。

image

 

デモのクエリであれば TOP が指定されていたため、ROWGLOAL による行数の目標が使用されたプランが生成され、Merge Join になっていたものが、CE Feedback により、ROWGOAL を指定しない推定のほうがより負荷が低いのではと分析が行われ制御するためのヒント句がフィードバックとして取得れていました。

このフィードバックにより Hash Match の実行プランが生成されるようになったことで、CPU 使用時間の減少につながる可能性があると検証されたというケースになるのかと思います。

CE Feedback は理解が薄いので、実機で確認ができるようになった場合には、デモの内容を見直しながら検証して理解を深めたいですね。
本セッションで言われていた、モデルというのが CardinalityEstimationModelVersion なのか、実行プランが生成された際の基数推定に使用されたロジックや行数推測の内部的な手法さしているのかは把握しておく必要がありそうだと感じています。

Bob Ward の Intrducing SQL Server 2022 では、次のような説明がありましたので、今回のデモのようなクエリヒントを使って問題を調整するというもの CE Feedbak の一つの機能となるようです。

  • Feedback loop for CE model choices and query excution
  • Use query hints to adjust problems

 

CE フィードバックについてはこのような QA もありました。古い基数推定では使用できなさそうな感じです。

  • Q : Is CE Feedback only in play, when LEGACY_CARDINALITY_ESTIMATION = OFF?
  • A: We need to verify this but I believe yes

 

 

DOP Feedback

最後に紹介されたのが DOP (MAXDOP) Feedback です。

image

今日の DOP の状況としては、はこのようになっています。

SQL Server 2019 から DOP はインストール時に CPU 数に応じて算出されたものが設定されるようになりました。

分析やレポーティング系のクエリでは、複数の CPU を使用したクエリのほうが効率が良いですが、OLTP 中心のワークロードでは高すぎる DOP は同時実行性の低下につながる可能性があり、適切な値を検討する必要があります。

 

image

DOP Feedback では、CPU / 経過 / 待機時間に基づき、非効率な並列クエリの特定し、DOP を 2 ~ MAXDOP の設定値の中で調整することで、最適化を行うことができます。

 

最小を 1 にしてしまうと並列クエリではなくなってしまうため、1 ではなく、2 を最小値としているとのことです)

  • Q : DOP Feedback, why min is 2 and not 1 to turn off?
  • A : 1 means no DOP so the min is 2

 

並列性を高めるための待機時間を短縮することを目的としているため、Feedback によって、実行時間が長くなる可能性がありますが、同時実行性を向上させることができるようになるようです。

 

SQL Server 2022: The hybrid data platform

SQL Server 2022 の機能の中でも、Azure との連携部分についての解説が行われており、ハイブリッド連携の各機能が掘り下げられて解説されています。

Link Feature Azure SQL Managed Instance

Link Feature による SQL Server 2022 と MI の連携については、QA で興味深い内容があります。

現在、デモで使用されている v1 では、クラウドからのフェールバックは、Backup / Restore の機能を使用したものを使用できるようですが、2022 年にリリースされる際には、双方向シナリオのサポートを検討しているということなので、現在の発表内容は、現時点でのデモ内容としてとらえておく必要はありそうですね。

  • Q : other than backup, can you failover from SQLMI back to on-prem?
  • A : As Bob already said in the introduction, in v1 today you can use B/R hands-on, whereas by the release of 2022 we’d be looking to address bidirectional.

 

  • Q : Hi, So you can only restore to sql server 2022 from the managed instance?
  • A: Today in the preview v1 this is what you can do right away – restore to SQL Server 2022 (we will not be supporting restore to any lower versions). As Bob announced, two way DR will be addressed in a future CTP.

 

  • Q : since MI link is bi-directional, why not make failover from azure to -premise also one click type of operation instead of go through the restore from file approach?
  • A : Bob already covered this in the intro. Today in the preview this is what you can do – B/R back. We would be targeting to address this by the end of the release of 2022. Thanks

 

  • Q : Since Azure Managed Instance (AMI) is managed by Azure, what if AMI is running on higher version over the year and now our on prem version is lower? We cannot restore the database from AMI to on-prem.
  • A : No worries, starting with SQL Server 2022 we will make sure Managed Instance version (although updated with the latest bits), will always is compatible to restore back to the latest in-market version is SQL Server.
    —-
    In terms of the other comment – Bob already said in the intro that today in the preview we do not have fail back, but by release of 2022 we would be looking into it. The engineering complexity to implement this is super hard, it is not a simple thing. Thanks.

 

アプリケーションの接続文字を単一にするためのエイリアス機能の開発についても検討されているようです。

  • Q : as you failover on-premise to SQL MI, do you have a listener running on AG for the applications connect?
  • A : Not possible to engineer it this way with listener running on AG on SQL Server, because on-prem and Azure are two very different environments. We will be addressing this through working on alias functionality to make a single connection string for apps. (coming in some future CTP release, not today in CTP1)

 

  • Q : Will there be a Distributed Availability Group listener so connection strings don’t have to be updated in a failover scenario?
  • A : Hi Jeff, we will have an alias technology to handle that, as we have two very separate environments (on-prem and the cloud).

 

リンクはユーザーデータベースのみとなり、システムデータベースに含まれるオブジェクトはサポートされないとのことです。

  • Q : Are we going to start moving Master and MSDB objects between servers, jobs, logins and etc in Availability Groups
  • A : Was your question SQL-Server to SQL Server, or SQL Server to Managed Instance? I will assume the latter. This will not be supported for the Managed Instance link. SQL Server 2022 to Managed Instance will support replication of user databases only. MI is a PaaS environment due to which system databases are not fully controllable by customers — this is why we can’t support this at this time.

システムオブジェクトの同期については、Azure SQL Managed Instance – Sync Agent Jobs and Logins in Failover Groups のような連携を検討する必要が出てくるのかもしれませんね。

 

Synapse link for SQL Server

Synapse Link for SQL Server のアーキテクチャについて、解説が行われています。

image

Synapse へのデータ連携については、Buffer Area として、Azure Stroage が使用され、これがデータ連携のランディングゾーンとなるようです。

初期データについては、スナップショットを使用してユーザークエリのブロッキングが発生しないように取得が行われるとのことです。新しい変更フィードによりトランザクションログから変更されたデータを補足して、連携することでデータの同期が行われるようです。

 

セッション内のデモで表示された画面には、Synapse Link を設定する際の Landing zone として、Azure Storage (おそらく Gen2 ですかね) を指定する項目がありますね。
image

SQL Server のテーブルと Dedicated SQL Pool のテーブルをマッピングすることで、Synapse Link による同期を行うことができるようです。

image

 

Synapse Link for SQL Server では、データ連携だけでなく、スキーマ変更についてもサポートされるようです。

  • Q : How do we manage schema changes with Synapse Link?
  • A : Hi Navnish, We plan to support replicating Add column, Drop column and Update Column Data type changes to Synapse Link Tables.
    With that, most frequent DLL will be replicated as part of Synapse Link, other schema changes can be replicated manually.

 

ランディングゾーンはストレージなので、ユーザーが連携されているデータにアクセスすることはできるようですが、Synapse Link に影響を与える可能性があるため、この領域に置かれている連携用データを二次使用することは推奨されないようです。

  • Q : When using Azure Synapse Link for SQL Server, how is the data structured in the data lake where it lands?
  • A : Landing zone is a temporary storage for Synapse Link, the final destination is Synapse database – so data is in columnar format. For SQL Server 2022 you’ll be able to access the landing zone but it’s not recommended to not impact the link.

 

Synapse Link for SQL Server については、Data Exposed の Welcome to SQL Server 2022 Live! | Data Exposed Live でも新しい内容の解説がありましたので、本投稿で合わせてまとめておきたいと思います。

Synapse Link は、Integrate の Link Connection から操作を行うことになるようです。データソースとなる、SQL Server に対しての接続はセルフホステッド統合ランタイムも使用できるので、柔軟な接続が可能ですね。

imageimage

Synapse Link for SQL Server は、現状リリースされている他の Synapse Link とは異なり、データの同期を行うものとなりますので、Monitor からリンクの稼働状況を確認することもできるようになるようです。
imageimage

 

Buffer Area となる、Landing Zone の Azure Storage については、Gen2 が使用され、連携先には、Dedicated SQL Pool が使用されます。Synapse Link for SQL Server で、Dedicated SQL Pool を SQL Server が保有しているデータの、データハブとして活用することができるようになり、Dedicated SQL Pool 上では、Synapse Link Table として読み取り専用のデータとしてアクセスを行います。imageimage

SQL Server 2022 Live では、Synapse Link for SQL Server のアーキテクチャについても解説が行われました。

下図は、これまで解説されていた内容と近い図ですね。
image

興味深かったのは、こちらのスライドです。

image

Synapse Link for SQL Server の同期のアーキテクチャが解説されたのは初めてではないでしょうか。

  1. 完全なスナップショットの公開
    • SQL Server のデータの初期スナップショットを BLOB Storage に Parquet フォーマットで取得
  2. 変更のキャプチャ
    • トランザクションログから変更内容を取得し、トランザクションの一貫性のあるバッチ内ですべての変更をキャプチャし、メモリ上にキャッシュ
  3. 変更の発行
    • 変更内容を CSV にシリアライズし、利用者が指定した BLOB ストレージに書き込み
  4. 変更の確定
    • マニフェストファイルでバッチによりコミットされた変更を追跡できるようにする

このような処理が行われることで、Synapse Link for SQL Server の変更の追跡が実現されているようです。

 

Azure Purview Integrate

SQL Server 2022 と Azure Purview の統合についてもアナウンスされていましたが、実際の機能についても発表が行われました。

image

これについては、先日公開された Private Preview: controlling access to Azure SQL at scale with policies in Purview 相当の動作となるようです。

Purview のポリシー管理を使用して、Purview で設定した内容を基にして、SQL Server に対しての操作を制御することができる機能となるようです。

image

 

初期の機能としては、DMV / テーブルとビューの読み取りアクセス権のポリシー設定が事前に定義され提供されるようになるようですね。

  • Q : What is the relation of these purview features, with SQL Server 2022? Does these security management features work today with Purveiw?
  • A : The initial capability is intended to provide access in SQL Server vNext based on pre-defined roles such as (subject to change by GA of SQL Server 2022):

      – SQL Performance Monitor – read-only access to DMVs and management of XEvent sessions
      – SQL Security Auditor – read-only access to DMVs
      – SQL Data Reader – read-only access to tables and views

      This is a “secondary” access control system which translates into a cumulative result for SQL permissions. Deny from either system “wins” regarding permissions.

Purview のような外部のサービスで管理されているポリシー向けの DMV が追加され、そこで、権限設定の設定状況を確認することもできるようになるようです。(以下の画像は、SQL Database でのデモで実施されていたものなので、SQL Server 2022 では内容が変更されるかもしれませんが)

image

 

Azure Active Directory for SQL Server

セキュリティ面では、Azure Active Directory との連携機能が強化されるようで、オンプレミスの SQL Server / SQL Server on Azure VM で Azure Active Directory による認証のサポートが追加されるようです。

image

Azure Purview のポリシー制御が RBAC で行われているようなので、AAD 連携は Purview 統合とも関係があるかもしれませんね。

 

Microsoft Defender for SQL

Azure Defender が Microsoft Defender にリブランドされたことと合わせて紹介が行われていました。

image

Microsoft Defender for SQL は、Microsoft Defender for SQL の概要 で解説が行われていますが、Azure Arc Enabled SQL Server を導入することで、Azure 以外場所で動作している SQL Server でも使用することができます。

SQL Server 2022 がネイティブに Microsfot Defender for SQL との連携が行われるのかについては言及されていなかったようにも見えたのですが、どのように連携されるかは使用できるようになってからの確認ですね。

 

SQL Server 2022 Storage Engine Capabilities

SQL Server 2022 のストレージエンジンの機能についての解説が行われています。

新機能の全体についても冒頭で触れられていました。

imageimage

image

 

tempdb のパフォーマンス向上

SQL Server の tempdb は負荷の発生が高いデータベースとなり、新しいバージョンがリリースされるたびにパフォーマンス向上の様々な施策が行われています。

image

現状の最新バージョンでは、In-Memory OLTP の技術の適用と、PFS の競合に対しての改善が行われていました。

 

SQL Server 2022 では、次のような GAM の競合によるページラッチの発生による同時実行性の問題についての改善が行われているようです。

image

 

image

  • 一時テーブルの作成
  • テーブル変数
  • カーソルの使用
  • GROUP BY
  • ワークファイル
  • Hash プラン

のような様々なワークロードで tempdb が使用されますが、これらの処理の際のページ割り当ての同時実行性についての改善が行われるようです。

SQL Server 2019 と比較して、同一のワークロードを実行した場合、SQL Server 2022 の tempdb の GAM (2:[file_id]:2) に対しての PAGELATCH_UP の競合は大幅に減少されていました。

 

Shrink Database with Low Priority

SQL Server に対してのいくつかの操作については、WAIT_AT_LOW_PRIORITY を設定することができ、同時実行性の低下を招く競合が発生した場合に、該当の操作の優先度を低くすることで、待機となるタスクの優先度を調整することができました。

この待機発生時の優先順序を低くする制御が、SHRINK DATABASE でも指定できるようになるようです。SHRINK DATABASE はオンライン操作ですが、瞬間的なロックは発生するはずですので、その緩和策となる形でしょうか。

image

 

XML Compression

XML データ型に対しての圧縮ができるようになるようです。

image

SQL Server の内部でも様々な情報は現在も XML で格納されており、大容量の構造化データを格納する際には XML を使用することもあるかと思います。

SQL Server 2022 では、データ圧縮をする際に、XML についても圧縮ができるようになるようです。XML データ型と、XML インデックスの両方に対して、圧縮を行うことができるようで、両方を圧縮すると、かなり、圧縮の効率が高くなりそうですね。
image

DMV の実行プランをダンプする際などには、この圧縮の効果は期待できるかもしれませんね。

 

従来から、XML は行外の LOB として格納されているため、圧縮の対象外となっていたのですが今回から対象とすることができるようです。

  • Q : I thought XML was already compressed due to special storage format (whitespace elimination, dictionary compression for tags etc.). What was changed in 2022? Any estimation on CPU impact?
  • A : XML is a specific type in SQL and stored as LOB data off-row. Because it is off-row it is not compressed by row/page compression, hence the need for the new feature.

 

その他のストレージエンジンの新機能

ストレージ全体としては、次のような改善が予定されているようです。

image

Buffer Pool Parallel Scan については、Azure の M シリーズのような、Many Core / Large Memory 環境でのデータベースバックアップ / リストア / AlwaysOn のフェールオーバー / DBCC CHECKDB / チェックポイントのような処理の性能向上に効果があるようです。

 

行ストア / 列ストアという観点でも確認が必要となるようですね。

  • Q : Is the Buffer Pool parallel scan improvement in rowstore buffer pool only, or is there a similar improvement in the columnstore object pool?
  • A : This would be the rowstore buffer pool. The columnstore object pool is a very different structure, so improvements would be separate from each other,

 

Resumable ADD CONSTRAINT も新しい制約を作成する際のオプションとして興味深いですね。

 

Multi-Write replication

image

これについては、以前からアナウンスされているものと同一ですね。

セッション内容を聞く限りは、ベースとなる機能は Replication Enhancements in the SQL Server 2019 CU13 Release となっているようです。

 

その他の可用性の新機能

image

可用性については、これまで発表された機能以外にもいくつかの追加があるようです。

可用性グループの REDO の改善も行われ、処理が効率化されたことで、いち早く DB をアクティブにできるようになるようですね。

  • Q : Could you say something more about the availability group redo improvements?
  • A : We’ve improved the thread allocation algorithms to avoid thread starvation and make more efficient use of resources.

 

 

Azure AD Authentication

image

セットアップについては、Azure Portal と Arc エージェントから実施できるようですね

Azure AD 認証を使用することで、Azure SQL の AAD 認証相当の認証が、SQL Server でも使用することができるようになるようです。

 

Purview Integrated

image

SQL Server ベースの環境だけでなく、Cosmos DB も対応するようですね。

SQL Server については、Arc enabled SQL Server が必要になる可能性がありそうですね。

 

その他のセキュリティ機能

image

Always Encrypted の検索柔軟性 / パフォーマンス向上が計画されているようです。他にも SQL Database で既に導入がされている DDM の詳細な権限設定なども 2022 に含まれるようですね。

Linux のセキュリティ向上としては、AD 認証の設定の改善などが含まれるようです。

 

 

SQL Server and Intel: Unlock Better SQL Performance and Scalability

Intel のハードウェアとSQL Server の組み合わせのについての解説が行われています。

SQL Server 2022 の機能向上としては次のような内容が挙げられており、この中で、Intel のハードウェアを組み合わせて実現するものについて解説が行われています。

image

 

DCPMM 対応の機能向上

SQL Server では、バージョンの進化に合わせて最新のハードウェアの効果的な活用についても改善が行われており、DCPMM (Intel Optane DC Persistent Memory / PMEM) の活用についても進められています。

ドキュメントとしては、次の内容になるかと。

本セッションでは、SQL Server の DCPMM サポートについて新しい発表がありました。

SQL Server 2019 では、Linux 版については PMEM を使用する場合のエンライトメントされた I/O (Enlightened IO) がサポートされており、OS の I/O スタックをバイパスして、データベースファイルにアクセスをすることが可能でした。

SQL Server 2022 では、Windows Server 2022 と組み合わせた場合に、Windows 環境でエンライトメントされた I/O のサポートが追加されるようです。

image

 

Soft RAID を使用すると、エンライトメント I/O が使用できなくなるということは覚えておく必要があるようですね。

  • Q : Can you / should you be using RAID for Optane?
  • A : Hi Ola, only software RAID is possible like NVMe. Using software RAID prevents Direct Access (DAX) or enlightened I/O that Dave will discuss shortly. However, it can still be used as block storage with software RAID. I would recommend software RAID for transaction logs.

 

 

バックアップ圧縮のハードウェアアクセラレーション

SQL Server では、バックアップの圧縮を実施することができますが、SQL Server 2022 ではバックアップ圧縮に Intel QuickAssist テクノロジー (Intel QAT) を使用することで、バックアップ圧縮のオーバーヘッドをハードウェアアクセラレーションにより、改善することができるようになるようです。

バックアップアルゴリズムに「QAT-DEFLATE」を使用することで Intel QAT を使用したバックアップ圧縮となり、「MS-XPRESS」を使用すると従来のバックアップ圧縮となるようです。

image

Intel の C62x のチップセットであれば、Intel QAT をサポートしているようですので、この恩恵を受けることができるのではないでしょうか。それ以外のチップセットでは、QuickAssist Adapter を搭載することになるのでしょうかね。

 

本セッションでのテストについては、QuickAssist Adapter を使用したようです。

  • Q : What is the timeframe for QAT being available in standard servers with Intel processors?
  • A : It is currently available on Lewisburg and above chipsets on QAT enabled SKUs but Darren was referring to further enhancements in the next generation of Intel hardware (Sapphire Rapids). Testing was performed using a PCIe adapter card.

 

VM でも SR-IOV を使用することで、QAT を使用することができるようですね。

  • Q : why is the benefit considerable less in a VM compared to bare metal ?
  • A : The graphs shown were from a bare metal installation but QAT is supported for VMs using SR-IOV which has minimal latency. We have seen very little performance overhead for VMs using QAT.

 

SQL Server 2022 Storage Engine Capabilities で紹介されていたのですが、サーバーレベルの構成で、デフォルトで QAT を使用した圧縮の有効化や、SERVERPROPERTY で、QAT が使用可能かを確認することもできるようです。

imageimage

 

Introducing SQL Server 2022 では次のような QA もありました。

バックアップファイルのフォーマット自体は QAT を使用しても変わらない (= QAT が搭載されていない環境でもリストアができる) ようですね。

  • Q : If you are using QuickAssist will the backup file itself change? AMD vs Intel? Linux vs Windows?
  • A : QuickAssist doesn’t change the file format. It’s just a more efficient way to create and compress the backups.

 

 

次のイベント

PASS Summit での SQL Server 2022 の情報公開はこれでひと段落だと思いますが、次のイベントとしては、SQL Server & Azure SQL Conference が、2021/12/7~9 に開催されます。

こちらは有償のイベントですので、参加していないユーザーにどの程度情報が公開されるのかがわからないのですが、SQL Server 2022 のセッションとしては次のようなものが予定されているようですので、このイベントの開催以降にも様々な情報が公開されるかもしれませんね。

Share

Written by Masayuki.Ozawa

11月 11th, 2021 at 8:55 am

Leave a Reply