SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
今月、PASS Summit 2020 が開催されており、SQL Server ベースのデータベースエンジンに対して追加が予定されている、クエリストアヒント / Ledger という、2 つの機能の紹介が行われていました。
現在、最新バージョンの SQL Server は SQL Server 2019 CU8 ですが、このバージョンではこれらの機能の実装の片鱗を見ることはできません。
しかし、Azure SQL Database / Azure Arc Enabled SQL Managed Instance のクラウドベースの SQL Server のデータベースエンジンでは、これらの機能はまだ使用することはできないのですが、機能の実装が進んでいることが把握できる情報を確認することができるようになっています。
現在利用可能な SQL Server ベースの環境では、Azure Arc Enabled SQL Managed Instance (Azure Arc SQL MI)? が機能をより確認できそうですので、ざっくりと情報を見てみました。
調べ物をしていたところ、SQL Server で最終ページの挿入 PAGELATCH_EX 競合を解決する方法 (How to resolve last-page insert PAGELATCH_EX contention in SQL Server) というドキュメントが公開されていることに気づいたので、少しまとめておこうかと思います。
本投稿は、データベースを遅くするための８つの方法 で解説されている、「シーケンスナンバーに PK を使用する」の Right Growing Index に関してのSQL Server での基本的な考え方になります。
SQL Server / Azure SQL Database (SQL DB) で、データベースのデータファイル (mdf/ndf) に対しての書き込みの発生状況を確認するための方法として「SQL Server: Buffer Manager オブジェクト」の「Page writes/sec」の情報を調べるという手法があります。
Page writes/sec の説明は次のようになっています。
物理的なデータベース ページ書き込みが実行される 1 秒あたりの回数を示します。
SQL Server では、物理的なデータベース ページへの書き込みが発生する一般的な要因としては、次のような内容があります。
クエリストアは少し例外的なパターンですが、基本的には、メモリ上では変更されているが、データファイルには書き込みが行われていないデータを書き込み、ディスクに永続化する際に Page writes/sec が発生します。
ただし、特定の状況下では、非効率な SELECT によっても Page writes/sec が発生するケースがあります。
2020/11/9～13 の期間で開催されていました。
今年は全セッションがオンライン化された Virtual Summit として開催されており、Keynote についても、開催時間に合わせての事前録画の公開となっていました。
仕事の関係でリアルタイムで参加はできていないのですが、録画で内容を確認することができましたので、発表内容をまとめておきたいと思います。
2020/9 に Ignite 2020 があったばかりですので、その時のアナウンスと重複しているものが多いですね。
しばやん先生が Hack Azure! #4 – Synapse と Cosmos で実現するサーバーレスデータ分析 フォローアップ で紹介していますが、Synapse Analytics の Serverless SQL pool の分散クエリ処理エンジン (Distributed Query Processing Engine : DQP) については、POLARIS として、Microsoft Research から、「POLARIS: The Distributed SQL Engine in Azure Synapse」として、論文が公開されています。
論文を読むのはしんどいのですが、VLDB 2020 では、動画の公開も行われていましたので、こちらも合わせながら、ざっくりと眺めてみました。
Azure Arc enabled SQL Server (Azure Arc 対応 SQL Server) は、オンプレミスの SQL Server や Azure 外で動作している SQL Server の管理を Azure に拡張することができます。
構成については、Azure Arc 対応 SQL Server (プレビュー) で解説が行われており、全体的なとしてはこのドキュメント内で解説されている下図のアーキテクチャとなります。
Azure Arc enabled SQL Server については、Azure Arc で実現する SQL Server Anywhere をまとめる際に触れてはいたのですが、軽く確認しただけでしたので、この機会にもう少し触れてみたいと思います。
Azure Arc enabld SQL Server については、Windows / Linux の両環境の SQL Server をサポートしていますが、Windows 部分をメインに検証しています。
来週から PASS Summit 2020 が開催されますが、その前に、先月の更新情報を確認しておかないとなと思いチェックしてみましたとさ。
更新情報のまとめは、毎週は無理なので月次でやろうと思いました(遠い目)
Synapse Analytics (Workspace) の SQL on-demand (Serverless SQL Pool) では、次の形態の DB を利用することができます。
従来の、Azure SQL Database では「論理サーバー」を使用した環境の場合、サーバーはエンドポイントとなっていました。
エンドポイント内に複数のデータベースを作成することはできるのですが、各データベースは独立したリソースで動作しているため、データベースを跨いだクエリの実行にはかなり制限がありました。
SQL on-demand の場合、Azure SQL Database の論理サーバーモデルとは異なり、データベースを跨いだクエリの実行ができるようです。
Azure Synapse SQL でサポートされる Transact-SQL 機能 で、サポートされる T-SQL の機能が記載されているのですが、SQL on-demand では、データベース間のクエリはサポートとなっています。
SQL on-demand (Serverless SQL Pool) では、共有メタデータテーブル という形で Spark Pool で作製した Parquet フォーマットを使用したテーブルを、SQL on-demand で参照することができます。
先日投稿した、Synapse Analytics の Serverless SQL Pool (SQL on-demand) でテキストを参照する際の文字コードの設定 (おまけで Synapse Link for Cosmos DB) でも Synapse Analytics の照合順序に触れましたが、共有メタデータテーブルでも照合順序はポイントとなる点がありますので、触れておきたいと思います。
ドキュメントについては、SQL オンデマンド (プレビュー) で Apache Spark for Azure Synapse の外部テーブル定義を同期する を参照すると良いかと。
