SQL Server のトラブル解析に Bing AI (Bing チャット) / ChatGTP を活用することはできるのかが気になったので簡単にではありますが試してみました。
プロンプトの組み方によってはもっと精度を上げることもできるのかとは思いますが、今回はシンプルな自然言語の入力で試しています。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
SQL Server のトラブル解析に Bing AI (Bing チャット) / ChatGTP を活用することはできるのかが気になったので簡単にではありますが試してみました。
プロンプトの組み方によってはもっと精度を上げることもできるのかとは思いますが、今回はシンプルな自然言語の入力で試しています。
従来からの SSMS (18.x まで) でも Azure Active Directory 認証をサポートしていました。
SSMS 19.x でも引き続き Azure Active Directory 認証をサポートしていますが、認証方式が強化されました。
新しく次の認証方式が追加されています。
サービスプリンシパルとマネージド ID は今まではアプリケーションから使用する目的が多かったかと思いますが、最新の SSMS を使用することで対話型ログインでもこれらの資格情報を使用することができます。
SQL Server 2022 の Azure Active Diretory 認証 でもこれらの資格情報を使用することも可能となっています。
SQL Server 2022 / Azure SQL Managed Instance では、Azure Active Directory ユーザーを使用した認証を実施することができます。
設定をする際には、最初の管理者アカウントを設定する必要がありますが、このアカウントには Azure Active Directory グループを指定することもできますので、最初の管理者にはグループを追加し、以降はグループのメンバーをメンテナンスすることで管理者を設定する運用も可能となっています。
このような「Azure Active Directory のグループを介してメンバーに権限を付与する」場合、データベースメールの利用にはいくつか気を付ける点がありますので、それをまとめておきたい思います。
Managed Instance で問題が発生している場合、同様の設定をした SQL Server 2022 でも問題が発生する可能性が高いので、デバッグにしては様々な情報を取得できる SQL Server 2022 のほうが容易かもしれません。
私もきちんと理解できておらず、最近まで把握できていなかったのですが、Always Encrypted Secure Enclaves を使用するためには、HGS (Host Guardian Service) による構成証明は必須ではないようです。(実運用環境では構成したほうが良いと思いますが、機能検証をしたい場合には HGS を構成しなくても検証が可能です)
最近、SQL Database で VBS (Virtualization based security) Enclaves を使用した Always Encrypted のサポートがプレビューで開始され、次のアナウンスがありました。
これに伴い、Always Encrypted Secure Enclaves のドキュメントを見直していて必須でないことに気づきました。
SQL Server 2022 Standard / Enterprise では、従量課金 (PAYG) による SQL Server の利用が可能となり、従来の永続ライセンス (一括購入) の利用形態だけでなく、使用時間に応じた PAYG による利用が可能となりました。
本ブログでも次のような投稿でも SQL Server 2022 の PAYG について触れてきました。
この PAYG の仕組みについて、SQL Server 2022 だけでなく SQL Server 2012 以降も対象となる機能追加が、2023/1 から Azure Arc 対応 SQL Server で行われました。(SQL Server の従量課金制 では 2014 以降となっていますが、2012 以降が正しいと思います)
従量課金制 (PAYG) ライセンス オプションが SQL Server 2012 以降に拡張されました
2012~2019 を対象とした PAYG についてはまだ情報を確認している最中ですが、現状確認ができていることをまとめておきたいと思います。本利用形態はまだ情報が少ないので今後 MS の公式情報も増えていくのではないでしょうか。
本日は Windows のセキュリティ更新プログラムの提供日となっていましたが、本日はリモートコードの脆弱性対応として SQL Server に対しての更新プログラムの提供も行われています。(脆弱性の例としては CVE-2023-21528 等があります)
SQL Server 2014
SQL Server 2016
SQL Server 2017
SQL Server 2019
SQL Server 2022
今回の問題は広範囲のバージョンの SQL Server に影響しており、拡張セキュリティ更新プログラム (ESU) で更新プログラムの提供がお壊れている SQL Server 2008 / 2008 R2 / 2012 にも関係するものとなっていたようです。
これにより、ESU によりこれらのバージョンでも ESU による更新プログラムの提供が開始されました。(今まではセキュリティ更新プログラムのリリースはなく、サポートでのメリット教授となっていたのですが、今回更新プログラムの提供を受けることができるようになりました)
ESU による更新プログラムの提供は GDR (General distribution release) の更新プログラムとして提供が行われるようです。
SQL Server 2008 ~ 2012 の KB の番号は次のようになるようですが、投稿時点ではまだ情報は公開されていないようです。
特典で ESU によるセキュリティ更新プログラムを無償で受け取るためには条件がありますので、今回は Azure Stack HCI 上に構築した仮想マシンで検証をしています。
SQL Server 2022 から従来からのライセンス買い切りによる購入形態だけでなく、PAYG による従量課金によるコアライセンスの活用ができるようになりました。
SQL Server 2022 で使用する場合には、エディション選択時に「Microsoft Azure を通じて従量課金制の課金を使用します」を選択することで、Azure のコストとして PAYG による SQL Server の利用ができるようになります。
このライセンスの利用形態では、Azure Arc 対応 SQL Server を使用して Azure に接続を行うことで従量課金によるコストが発生します。
コストの発生の条件については、Azure Arc 対応 SQL Server に関するよくあるご質問 に記載されています。
基本的な考え方としては次のようになるかと思います。
SQL Server 2022 ではコアライセンスに変更があり、次の情報に記載があります。
これらの情報には次の記載があります。
Beginning with SQL Server 2022, licensing by virtual machine is an option under subscription licenses or licenses with Software Assurance only.
製品条項を 2019 と比較するとわかりやすいのですが、2022 では個別の仮想マシンでコアライセンスを使用する場合の条件が変更されており、「サブスクリプションライセンスまたは、アクティブな SA 付きライセンスでのみ利用可能」が追加されています。
Enterprise Edition を使用して、ハイパーバイザーの物理コアのライセンスを取得し、それを使用して仮想マシンにライセンスを割り当てる形態は従来通りとなりますが、仮想マシンに直接ライセンスを割り当てる形態については、2019 までと比較して制限が追加されているようです。
これにより、PAYG によるサブスクリプションライセンスを検討しなくてはいけないケースが出てくるかもしれませんね。
以前投稿した 複数サブネット構成を使用した SQL Server on Azure VM の可用性構成について に近いものとなりますが、改めて特徴を把握しておきたいと思います。
SQL Server 2022 では、システムデータベースのディレクトリに、次のデータベース用のファイルが格納されています。
これらのファイルは、SQL Server 2019 でも存在していたのですが、通常のインスタンスでは使用されていませんでした。
SQL Server 2022 になると、状況が変わり、これらのファイルが使用されているデータベースとして model_replicatedmaster / model_msdb というデータベースが SSMS や DMV では表示されませんが内部的に存在するようになり、基本構成としてファイルが使用されるようになりました。
現状、これらのデータベースの情報が公開されているものはないのですが、2022 で新しく追加されたシステムデータベースとなるため、本投稿で現在調べられていることをまとめておきたいと思います。
SQL Server のメモリ管理については、メモリ管理アーキテクチャ ガイド で解説が行われています。
このガイドの中で、メモリ不足の検出 に次の記載があります。
次の 2 つのリング バッファーに、動的メモリ管理に関連する情報が保持されます。
- メモリ不足が通知されているかどうかなど、リソース モニターのアクティビティを追跡するリソース モニター リング バッファー。 このリング バッファーには、現在の
RESOURCE_MEMPHYSICAL_HIGH状態に応じて状態情報が含まれます。RESOURCE_MEMPHYSICAL_LOWRESOURCE_MEMPHYSICAL_STEADYRESOURCE_MEMVIRTUAL_LOW- 各 Resource Governor リソース プールのメモリ通知のレコードが含まれるメモリ ブローカー リング バッファー。 内部メモリ不足が検出されると、メモリの割り当てを行うコンポーネントに対して、メモリ不足を示す通知がオンになり、キャッシュ間でメモリのバランスをとるためのアクションがトリガーされます。
SQL Server のメモリ管理は「動的メモリ管理」によって実施されており、OS / SQL Server のメモリ使用状況に応じて、各役割のメモリを自動的に調整します。
この動的メモリに関する動作については、リングバッファーから確認をすることができるようになっています。