SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
2022年7月は、投稿を書いている時点では、Azure Updates には、SQL Database の更新のまとめはアナウンスされていませんが、Azure SQL Blog のまとめや、Azure Updates に機能単位のアナウンスは行われていますので、情報をキャッチアップしておきたいと思います。Azure Updates にまとめがアナウンスされたら、本投稿に追記を行いたいと思います。(今月はバタバタしていて、情報をキャッチアップできていないので、そろそろまとめないと更新が把握できない…）
現時点のリリースノートには記載されていないのですが、SQL Server 2022 では、ラッチ (ページラッチ / バッファーラッチ) で待機が発生している場合の情報の出力内容が強化されています。
SQL Server では、ラッチは、
の二種類に大別されますが、今回は「バッファーラッチ」を例として情報を記載しています。
SQL Server のラッチについては、SQL Server でラッチの競合を診断および解決する で解説されていますので、ラッチについての詳細はこちらを確認してください。
ラッチについては SQL Server 以外の RDBMS でも実装されています。
SQL Server ではラッチというと非バッファラッチを差すケースが多いですが、RDBMS における一般的なラッチは、SQL Server ではバッファーラッチとなり、メモリ上のページの保護をするために使用されている同期プリミティブを刺すことになると思います。
SQL Server バッファー プール内のページのデータの書き込みまたは読み取りが行われるときは常に、ワーカー スレッドにおいて最初にそのページのバッファー ラッチを取得する必要があります。 バッファー プール内のページにアクセスするために使用できるバッファー ラッチには、排他的ラッチ (PAGELATCH_EX) や共有ラッチ (PAGELATCH_SH) など、さまざまな種類があります。
本日、Power BI データマートが東南アジア (シンガポール) でも使用できるようになったようで、シンガポールから東日本にテナントをお引越ししなくてもよかったのではと思う今日この頃ですが、私が使用している Power BI Premium Per User (PPU) の環境でデータマートを触れるようになったので、SQL Database の構成を簡単にではありますが確認してみました。（Power BI Embedded でも試すことができ、PPU も Embedded も同じ構成となっているようでした)
考慮事項と制限事項 で東アジアが制限から外れたので、日本の Power BI ユーザーも広範囲で試すことができそうですね。
Power BI データマートの説明については、データマートの概要 のドキュメントツリーを確認していただければと思います。
SSMS のアップグレードを実行しようとして、インストーラーを起動すると次のような、再起動要求の画面が表示されることがあります。
検証環境に Windows Update を適用した後に SSMS も一緒にアップグレードしておくかと思って、最新のインストーラーをダウンロードしてセットアップすると、これに遭遇することが多いのですが、どの辺の情報を見て判断しているのかが気になったので軽く見てみました。
確認した範囲では、「HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired」のレジストリキーが存在していると、上記の再起動要求の画面が表示されるようでした。
Windows の再起動要求の判断は How to Check for a Pending Reboot in the Registry (Windows) で記載されているようなレジストリを見ているケースもあり、今回確認できたキー以外で判断されるかもしれませんが、Windows Update 直後の環境で上記の画面が表示されていたので、何となくどの辺の情報を見ているのか確認してみました。
Azure SQL Managed Instance に SQL Server のデータベースバックアップを連続的に復元してを移行する際には、次の機能を使用することができます。
これらの機能では、
を継続的に復元することで、Managed Instance にデータベースをリストアすることができ、Managed Instance にデータベースの移行時にダウンタイムを抑えた移行に活用することができます。
ログ再生サービスを使用しようとした場合に、コンテナー名に制限があることが分かったことと、問題が発生した際に確認すべき情報について把握できて来たので情報をまとめておきたいと思います。
LRS と ADS + DMS のどちらも再生可能なリストア (Resumable restore) の機能が使用されているため本内容はどちらのリストア方法でも該当します。
参考としては次の情報を確認しておくとよいかと思います。
直近で実施された改善として、次のアナウンスで 36 時間の実行時間の制限については 30 日に拡大されているようなので、この機能の最新情報については次の情報も確認しておくとよいかと思います。
SQL Server 間のデータベース移行 / バージョンアップを実施する際のアセスメントに使用することができるツールとして Data Migration Assistant が提供されています。
DMA を使用することで環境が変更されたことによる機能互換性と、データベースの互換性レベルを変更した場合の影響を確認することができ、データベースの互換性レベルを変更した場合の影響調査には、「構文チェック」が行われています。
この構文チェックでは、「DMA に内包されているルールによるチェック」と「一般的な構文チェック」の二種類が行われているようなのですが、後者の「一般的な構文チェック」がどのように実施されているのか (どの程度網羅性があるのか) が気になったので、方式を確認してみました。
ライフサイクルサポートが終了した、Windows Server / SQL Server については、2008 以降は ESU (拡張セキュリティ更新プログラム) が提供されます。
ESU は有償のプログラムですが、Windows Server 2012、2012 R2、および SQL Server 2012 のサポート終了に備える で次のように記載されている通り、Azure のサービスと組み合わせることで無償で提供を受けることができます。
無料の拡張セキュリティ更新プログラムは、Azure Virtual Machines、Azure 専用ホスト、Azure VMWare Solution、Azure Nutanix Solution、Azure Stack Hub/Edge/HCI などの Azure のお客様が利用できます。
今回、検証で使用する Azure Stack HCI も対象となっており、Azure Stack HCI 上で動作している仮想マシンについても無償で ESU を受けることができる環境となります。
Build 2022 で Azure Stack HCI 単一ノードクラスターの一般提供 (GA) がアナウンスされました。
以前、別の評価に使用していた NUC8v7PNH が 1 台空いたので、この Azure Stack HCI 単一ノードの評価用としてセットアップして、ESU の適用を行うことろまで確認できましたので、情報をまとめておきたいと思います。
ESU については、次のドキュメントを参考にするとよいかと思います。
SQL Server 2022 CTP 2.0 時点の情報となり、今後の Preview / 一般提供開始時には変更されている可能性もあります。
SQL Server 2022 では Always On 可用性グループの機能強化として、「セカンダリレプリカのクエリストア」があります。
Always On 可用性グループとクエリストアを組み合わせることは、以前から可能でしたが、クエリストアで取得可能なクエリ情報は「書き込み可能なプライマリレプリカに対して実行されたクエリ」のみとなっていました。
そのため、「セカンダリレプリカに対して実行された読み取りワークロード用のクエリ」については、クエリストアに情報が蓄積されず、セカンダリレプリカで実行されているクエリについては、クエリキャッシュをベースとした解析を行う必要がありました。(これは、SQL Server だけでなく、PaaS の SQL Server ベースの環境でも同様の動作となっています)
SQL Server 2022 では、この点が改善され、セカンダリレプリカに対して実行されたクエリについてもクエリストアに情報を格納できるようになりました。
Log Analytics API について少し整理しておきたい内容がありましたので、調べた内容をメモとして残しておきたいと思います。
Microsoft Defender for Cloud を有効化する方法には「サブスクリプションレベル」「Log Analytics ワークスペースレベル」の 2 種類があります。
設定については、環境設定 から実施することができるのですが、このブレードでサブスクリプションを選択するか、Log Analytics ワークスペースを選択するかによって、どのレベルで設定するかが変わってきます。(既定のワークスペース については Microsoft Defender for Cloud の個別の設定を行うことができないようです)
Microsoft Defender for Cloud について問い合わせをしていて、サブスクリプションレベルと Log Analytics ワークスペースレベルの設定の違いを教えていただくことができましたので、情報をまとめておきたいと思います。