SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
MySQL の場合は、10.1.4 接続文字セットおよび照合順序 のような設定で、クライアント / サーバー間のデータ通信 (クエリ / 結果) で使用される文字コードを設定できるかと思います。
SQL Server の場合は、サーバーに文字データ格納時の文字コード (コードページ) / 文字列を比較する場合のルールを「照合順序」で設定することができますが、クライアント / サーバー間のデータ通信で使用される文字コードについては、明示的な指定を行うことはできません。
SQL Server ではクライアント / サーバー間の通信で使用されるデータではどのような文字コードが使用されているのかについて、まとめてみたいと思います。
本投稿のような内容を調べる場合には、クエリ実行時のパケットをキャプチャして、SQL Server のプロトコルのドキュメント に記載した TDS の使用を確認することになるかと思います。
Windows の OS としての文字コードの扱いについては、Unicode と文字セットについて を参照してください。
SQL Server on Kubernetes Designing and Building a Modern Data Platform という SQL Server on Kubernetes (k8s) に特化した書籍が発売されました。
ざっと一通り目を通したのですが、Windows エンジニアが、Linux 上に k8s の複数ワーカーノードの環境を一から作成して、操作を行うというような流れとなっており、SQL Server のエンジニアが k8s を学習を始めるのに適している書籍ではないかと思います。
私の場合は、Windows Server 2019 がインストールされている環境がいくつかりますので、Azure Stack HCI 検証方法 Tips に記載しているような、Windows Server 上に AKS on Azure Stack HCI を構築して検証を行っていますが、この環境でも書籍内の操作は問題なく行うことができました。
書籍内には、https://www.centinosystems.com/blog/category/kubernetes/ の記事も参照されており、こちらも併せて読むとよさそうです。
k8s 上に展開した SQL Server を Deploymentの更新 で最新バージョンに更新する流れや、NFS を使用した PVC の作成などにも触れられており、単純に Pod を展開する以外のスキルも身に着けることができます。
NFS のマウントオプションについては触れられていなかったので、What are the NFS mount options for databases on NetApp? / Oracle DatabaseのNFSバッファ・サイズ・パラメータの構成 あたりをマウントオプションの参考にするのもよさそうですね。
Service については、LoadBarancer ではなく NodePort を使用するようになっていますので、MetalLB も別に学習するとよいかもしれません。
SQL Server と k8s の組み合わせについては、SQL Server 2017 でコンテナー版の SQL Server の提供が開始された時から情報の公開が始まり、Big Data Cluster (BDC) / Azure Arc Enabled SQL Managed Instance で、k8s に最適化された SQL Server ベースの環境が提供され、いくつかのドキュメントが公開されています。
本投稿では、SQL Server on Kubernetes について、MS から提供されているドキュメントについて記載しておこうと思います。
SQL Server を単体で動作させるもの / Big Data Cluster / Arc Enabled SQL MI / Azure SQL Edge といくつかの利用形態を k8s 上で使用するための情報が公開されています。
SQL Server でイベント発生時の情報を取得する方法としては、拡張イベント (xEvent) があります。
拡張イベントを使用することで、SQL Server で発生する様々なイベントを取得することができます。
拡張イベントは情報を取得する際に強力な機能ですが、「イベントが発生した際に任意の DMV から情報を取得する」ということができなかったかと思います。
「特定のイベントが発生した場合に DMV から追加で情報を取得する」ということを実現したい場合、どのような方法があるか考えてみたところ、イベントによっては「WMI イベント警告」という機能を使えることを思い出したので、WMI イベント警告についてまとめてみたいと思います。
最近さぼっていましたが、Inspire 2021 が開催されたので、アップデートをまとめておこうかと。
Inspire 2021 の発表内容については Book of News が公開されていますので、これから確認できます。
データ関連はこんな感じで、大きな発表はあまりなかった印象です。
大きな発表は Windows 365 に持っていかれた感じですかね。
AKS on Azure Stack HCI を Windows Server 2019 の 1 ノード環境ではありますが、1 台起動したままにすることができそうなので、この機会に勉強を兼ねてメモを残しておきたいと思います。
AKS on Azure Stack HCI は、検証用途であれば 1 台の Windows Server 2019 上で動作させることができます。(Azure のサポート内で AKS on Azure Stack HCI のサポートを受ける場合は、OS に Azure Stack HCI OS を使用していたほうがスムーズになりますので、リソースに余裕がある場合は、HCI OS で環境を構築していたほうが良いかと)
64 GB / 4 Core (HT : 8 Core) の NUC が 1 台あれば、構築することができ、Windows Server 上で Kubernetes を展開することができます。
私のような今まで Windows をメインに触ってきたエンジニアでも Kubernetes の検証環境を容易に作ることができますので、k8s の勉強環境にも活用できるかと。
基本的には、Azure Stack HCI の Azure Kubernetes Service のドキュメント のドキュメントを確認しながら、勉強した内容を適宜更新していきたいと思います。
私の場合は、仕事の領域が「SQL Server のデータベースエンジン」となりますので、AKS on HCI を使用するのは、Azure Arc Enabled SQL Managed Instance を検証することが目的であり、Enabled SQL Managed Instance 観点の情報も記載しています。
SQL Server は、MS DTC (Microsoft Distributed Transaction Cordinator) をトランザクションマネージャーとして使用して、分散トランザクションの実行を行うことができます。
分散トランザクションについては、トランザクションのロックおよび行のバージョン管理ガイド で解説が行われています。
フローについては、1.3.1.2.3.2 Transaction Enlistment and Completion になるかと思いますが、コミットを「準備フェーズ」と「コミットフェーズ」の 2 フェーズで管理を行う 2 フェーズコミット (2PC) により、トランザクションの管理が行われます。
SQL Server の場合、インスタンス内の複数のデータベースにまたがる処理については、管理ガイドでは次のように記載されています。
数のデータベースにまたがる 1 つのSQL Server データベース エンジン内のトランザクションは実質的には分散トランザクションです。 ただし、SQL Server インスタンスは分散トランザクションを内部で処理するため、ユーザーにはローカル トランザクションとして動作しているように見えます。
実質は分散トランザクションではあるのですが、ローカルトランザクションのように見える処理が行われるため、MS DTC は使用されずに、処理が行われていたかと思います。
リンクサーバー / トランザクションスコープ (Transaction Scope) / BEGIN DISTRIBUTED TRANSACTION 等を使用した場合、実行方法によっては、MS DTC を使用した分散トランザクションとして実行され、分散トランザクションで実行される場合には、インダウト (in-doubt) トランザクション (未解決 / 不確定 / 不定トランザクション) の発生についての考慮が必要なケースが出てきます。
コミット時のインダウトトランザクションとしては、上記の図の xa_commit の部分になるかと思います。
分散トランザクションに参加しているトランザクションは最終的には、トランザクションマネージャーからの commit 要求により、各トランザクションのコミットが行われますが、コミットフェーズにおいて、特定のインスタンスでは、コミットが完了しなかったようなケースが発生した場合には、インダウト トランザクションとして、不確定のトランザクションをどのように取り扱うかを決めなくてはいけません。
インダウト トランザクションは 2PC の特定のタイミングでトランザクションを未確定にしなくてはいけないのですが、意図的に発生させる方法について残しておきたいと思います。
なお、windbg を使用して無理やり発生させていますが、本投稿では windbg の使用方法などについては触れませんのでご了承ください。
SQL Server のコールスタック (Call Stack) を確認にはいくつかの方法が利用することができます。
一番詳細な確認としては、WinDbg で確認する方法になるのではないでしょうか。 
それ以外には、Windows Performance Analyzer を使用する方法や、
Process Monitor / Process Explorer を使用する方法です。
これ以外の一つが「拡張イベントの Call Stack を SQL Call Stack Resolver を使用して確認する」という方法です。
拡張イベントの Call Stack については、他の方法でも確認することができるのですが、SQL Call Stack Resolver を使用する方法が容易かと思います。
本投稿では、SQL Call Stack Resolver を使用すると、どのように Call Stack が確認できるかを紹介したいと思います。
私は Windows の SQL Server でしか使っていないのですが、SQL Server on Linux (Docker 含む) で取得した拡張イベントに対しても、Call Stack の解決はできていそうでした。
Tools and Documents for fault analysis in SQL Server-based environments.
Azure Hybrid and Multicloud Digital Event で Azure Arc Enabled SQL Managed Instance (MI) の一般提供開始 (General Availability : GA) が、 2021/7/30 と発表がありました。
Arc に関連するサービスとしては、
が既に GA しており、今回 MI が GA となったことで、Arc 上で動作させることができる SQL Server ベースの RDBMS についても SLA がある状態で利用することができるようになりました。
AKS on Azure Stack HCI と組み合わせることで、Windows 環境をホスト OS として使用した Kubernetes を構築することもできますので、Windows ベースで MI を使用することもできます。(と言っても、Hyper-V 上のゲスト OS として Linux を動かして Kubernetes を構築していますので、実際には Linux 上で構築されているのですが)
料金についても、Azure Arc pricing はまだ更新されていないようですが、イベント内で発表がありました。
今回 GA として提供されるのは、汎用目的 (General Purpose : GP) となりますが、vCore 単位の課金となるようですね。
7 月に GA となりますが、現在、プレビューとして公開されているすべての機能が GA となるわけではないようで、いくつかの機能については、段階的に GA となるようです。
Azure Arc Enabled SQL Managed Instance では、現時点のロードマップでは、7 月に Preview / 10 月に GA となる、AlwaysOn 可用性グループで、高可用性構成をとることができるのですが、今まであまり真面目に調べていませんでしたので、今回 GA するということで、関連情報のキャッチアップを含め調べてみました。
今回発表のあった内容は Bring cloud experiences to data workloads anywhere with Azure SQL enabled by Azure Arc から確認できます。
Windows 11 で TPM 2.0 (Trusted Platform Module) が必須になる (初期公開の Insider Preview では CPU / TPM の最小要件が緩和されていますが、一般手開始されたタイミングでどうなるかは現時点では不明です) のではという話があり、TPM についての話題が一瞬ですが上がる機会が多くなってきました。
ということで TPM についてのメモを。
手元に Thinkpad T440s (20AQ0094JP) がありましたのでこちらを例にして。
この Thinkpad は、2014年6月3日 に発売され、2020年7月3日 に保守が終了しており、7 年前のラップトップとなりますので機種として古めです。