SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
SQL Server の tempdb のチューニングとして、次のような考え方があります。
日本語の情報としては、DO’s&DONT’s #17: やっておいた方がいいこと – tempdb データファイル数を CPU 数に一致させる が有名ではないでしょうか。
昨今の CPU は 1 ソケットで、40 物理コア / HT 80 論理コアのモデルもあり、複数ソケットを使用すると 100 コアを超える環境も出てきます。
そのような Many Core 時代でも tempdb のデータファイルの分割は「論理 CPU コア数」で行うべきでしょうか？
本投稿では現在の tempdb のデータファイルの分割について触れたいと思います。
sSQL Server ベースの環境で NULL を登録した場合、どのように格納されていたかを忘れていたので、書いておきたいと思います。
SQL Server NULL の取り扱いについては、集計関数 の NULL 値の取り扱いや NULL と UNKNOWN (Transact-SQL) に記載されており、NULL 値については次のように記載されています。
null 値は、通常、認識されないデータ、適用できないデータ、または後から追加されるデータを示します。
SQL Server の NULL 値は インデックス / 統計情報の対象となり、NULL を使用する目的については、私の認識としても上記のとおりです。
NULL を使うべきかどうか / 何らかの初期値を指定するかについては、データの意味と取り扱いに依存しますので本投稿では触れません。
Dash 2021: Datadog の最新発表 でアナウンスされました データベース モニタリング の SQL Server の Beta でのサポートですが、先日、Datadog を確認したら、私のアカウントでも使用できるようになっていましたので試してみました。
発表されてからかなり日が経っているのですが、Azure VM で SQL Server の可用性構成を構築する場合に、複数サブネット (マルチサブネット) 構成を使用することで、従来の構成と比較して構成の簡略化が行うことができるようになっています。
アナウンスとしては次の内容となり、
技術情報としては次の内容となります。
基本構成としては下図のようになり、複数のサブネットに VM を配置し、ロードバランサーは不要で、可用性グループにアクセスを行うことができる構成を Azure 上に展開することができます。
FCI についても、複数サブネットを使用して同様の構成を行うことができ、単体のチュートリアルは提供されていないのですが、https://docs.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/failover-cluster-instance-prepare-vm?view=azuresql&tabs=multi-subnet#subnets で情報が公開されています。
本投稿ではこの複数サブネット構成について触れたいと思います。
なお、今回の投稿のメインとなる内容は Windows の SQL Server を使用した Always On 可用性グループについてとなります。
昨年からリリースされている Microsoft 社提供の SQL Server 向けのデータアクセスコンポーネントで、暗号化設定の既定が変更されています。
私が確認した範囲では、次のコンポーネントを使用している場合に影響が出る可能性があります。
これらのデータアクセスコンポーネントでは「破壊的変更」として「Encrypt = true, by default」の変更が行われており、各コンポーネントの既定の接続が暗号化設定が有効になっています。
SQL Server では sp_helptext というオブジェクトの定義を取得するためのストアドプロシージャが提供されています。類似の機能としては次のようなものも活用することができます。
私は sp_helptext を使用することが多いのですが、このストアドプロシージャでは一部の情報を見ることができません。
SQL Server / SQL Database を使用しており設定を初期状態で使用していると、インスタンス / データベースの照合順序は、
のいずれかを使用しているケースが多いのではないでしょうか？
これらの照合順序は列レベルの照合順序の初期設定として、引き継がれますので列の比較をする際の挙動にも影響をしてきます。
照合順序については、次のドキュメントの内容を確認することになります。
SQL Server では Unicode の文字の比較を考慮する際には、照合順序の次のような内容を意識する必要があるのではないでしょうか。
SQL Server では、nchar / nvarchar / char (UTF-8 サポートあり) / varchar (UTF-8 サポート) を使用することで、Unicode の文字列を格納することができ、どの照合順序を使用していてもこれらのデータ型を使用している場合は、次のようなエンコードで文字を格納することができます。
ただし、格納と文字の比較は別であり、照合順序の設定によって「格納はできても想定した比較結果にならない」ということがあります。
日本語圏で考えた場合、
というような設定が関係し、「新しい Unicode のバージョンで追加された文字」については、「基本多言語面 (BMP)」である「000000 – 00FFFF」に追加されることもありますので、BMP の範囲の文字についても、照合順序の設定によっては正しく比較されないことがあります。
Unicode の情報については、https://home.unicode.org/ から確認することができ、Unicode のバージョンや、文字のコードポイントを確認する場合には、次の情報を使用するとよいのではないでしょうか。
SQL Server は文字の格納については、Unicode をサポートしたデータ型を使用していれば、柔軟にデータを登録することができますが、データの比較 については、照合順序の設定が大きく影響してきます。
本投稿では、以前のバージョンの照合順序となる BIN / Unicode は使用しない前提で記載していますので、バイナリ照合順序といえば BIN2 となり、Unicode サポートの照合順序といえば、照合順序名に Unicode がついていないものを前提としています。
ロンドンで開催されている SQLBits 2022 というイベントで MS のセッションで Azure SQL のアップデートの発表が行われたようです。
発表内容については、Azure SQL News Update | Data Exposed Live @SQLBits 2022 で動画が公開されています。
機能追加としては、SQL Managed Instance の MI Link が Public Preview になったことが大きいかと思います。
同時期には、次のような記事も公開されていますのでこれらの情報も確認してみるとよいかと思います。
SQLBits のキーノートとして実施された Level Up with Azure Data については、SQLBits の Youtube に公開されています。
このセッションの中で、SQL Server 2022 の Public Preview についても触れられ、2022 年の 1Q の終わりまでに、公開が行われる計画となるようです。
以下のブログの記事もとても参考になりますので、こちらも確認しておくとよいのではないでしょうか。
SQLBits 2022 でアナウンスがありましたが、SQL Server から Azure SQL Managed Instance （MI) とデータ同期をするための機能となる、Azue Managed Instance のリンク機能 (Link feature for Azure SQL Managed Instance / Managed Instance Link) が Public Preview となりました。
SQL Server 2022 と同時にこの機能のアナウンスも行われていたのですが、当初は Limited Preview となり限定されたプレビューでの公開となりました。(アナウンス時の情報は、Managed Instance link – connecting SQL Server to Azure reimagined となります)
今回、Public Preview となり、任意の環境で検証ができるようになりましたので、情報をまとめておきたいと思います。
追記
Tech Community でもアナウンスが行われました。
