SQL Server 2016 で Managed Instance Link がサポートされるようになりました で書きましたが、SQL Server 2016 SP3 + Azure Connect Feature Pack で Managed Instance Link がサポートされるようになったので、実際に設定をしてみました。
今回は SQL Server 2016 SP3 Standard Edition で検証をしています。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
SQL Server 2016 で Managed Instance Link がサポートされるようになりました で書きましたが、SQL Server 2016 SP3 + Azure Connect Feature Pack で Managed Instance Link がサポートされるようになったので、実際に設定をしてみました。
今回は SQL Server 2016 SP3 Standard Edition で検証をしています。
Connecting SQL Server 2016 to Azure – SQL Managed Instance link | Data Exposed でアナウンスがありましたが、SQL Server 2016 で、Managed Instance に対してデータベースの複製を行う、Managed Instance Link がサポートされたようです。
Link feature for Azure SQL Managed Instance (preview) に SQL Server 2016 のサポートが追加されています。
SQL Server 2016 SP3 以降に、SQL Server 2016 Azure Connect pack (KB 5014242) をインストールすることでサポートされるようです。
現状、SQL Server 2019 では Enterprise のサポートでしたが、2016 では Standard もサポート対象となっています。
Data Exposed では次の情報が提示されていました。
SSMS については 18.12 以降でのサポートとなるようで、それまではクエリベースでの設定となる形でしょうかね。
SQL Server の 分散型可用性グループ のアーキテクチャは Geo Replication / Azure Arc Enabled SQL MI / Managed Instnace Link で使用されているので、そろそろ改めて学習しようかなと思いました。
JdbcRunner には、テストキットとして、Tiny sysbench / Tiny TPC-B / Tiny TPC-C のシナリオが含まれており、このテストキットでは Oracle / MySQL / PostreSQL を対象として実行ができるようになっています。
JdbcRunnert と SQL Server の組み合わせについて調べてみたところ、データベース負荷テストツールまとめ (5) (公開版) で HP ProLiant Server + InfiniBand + IOアクセラレータ + CLUSTERPRO 検証報告 で SQL Server に対して実行したことが紹介されており、この検証では Tiny TPC-C を使用して SQL Server 2008 R2 に対して実行されていました。
私も SQL Server に対して実行してみたので、その際の作業メモを。
SQL Server on Azure VM (IaaS) の環境を Azure Backup でバックアップしようとした場合に、今はどのようになっているのかを把握することができていなかったので、軽くまとめてみました。
以前、Azure Backup で SQL Server がインストールされている仮想マシンをバックアップする際に意識しておきたいこと という投稿を書いたのですが、4 年前ですので自分の頭の中の整理もかねて。
今回のターゲットは Windows 環境で実行している SQL Server の単一ノードでの構成となり、Always On 可用性グループ / FCI はターゲットにはしていません。。
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 を使用することが多いのですが、このストアドプロシージャでは一部の情報を見ることができません。