Tools and Documents for fault analysis in SQL Server-based environments.
SQL Server 2016 SP3 で DNN がサポートされるようになりました
SQL Server では、AlwaysOn 可用性グループ / FCI (Failover Cluster Instance) で、DNN (分散ネットワーク名 : Distributed Network Name) という接続方法を使用することができます。
この接続方法を使用すると、Azure の IaaS で可用性環境を作成する際に Azure Load Balancer を使用せずに、接続のためのエンドポイントを作成することができます。(オンプレミスで DNN を使用することもでき、この場合は、エンドポイント用の仮想 IP を用意せずに接続ができるようになります)
この機能ですが、各バージョンの SQL Server の初期状態から使用することができるのではなく、累積修正プログラムを適用することで使用することができるようになります。
この DNN を使用した接続ですが、SQL Server 2016 については、先日リリースされた SP3 で AlwaysOn 可用性グループ / FCI のサポートが開始されました。
2021/9/20 時点では、Windows Server 2019 と次のバージョンの SQL Server で DNN がサポートされています。
AlwaysOn 可用性グループ
FCI
KB4537868 – Improvement: Enable DNN feature in SQL Server 2016 and 2019 FCI
2021/9/20 時点では、SQL Server 2017 で FCI の DNN のサポートが行われていないようですね。
SQL Database の最終起動日時を取得する
Azure の PaaS の SQL Server である、SQL Database は計画メンテナンスにより、メンテナンスが発生した際には、SQL Server のサービスの再起動が発生します。
計画メンテナンスの情報については、Azure SQL Database および Azure SQL Managed Instance での Azure メンテナンス イベントの計画 に記載されています。
最新のドキュメントでは、記載内容が変わっていますが、古いドキュメント では、次のように記載されていました。
頻度
平均すると、1 か月に 1.7 回の計画メンテナンス イベントが発生します。
今は、次のような機能が追加されており、計画メンテナンスが以前より把握しやすいようになっていますが、どこかのタイミングで計画メンテナンスによる再起動を発生し、再起動を完全に抑えることはできません。
計画メンテナンスによる瞬間的な接続の切断が行われたかの状況については、標準のメトリックの「Failed Connections」を使用して確認することができるそうです。
このメトリックを使用したアラートルールを設定して接続の失敗を把握することで、メンテナンスが行われたのかを把握するという方法をとることもできるのではないでしょうか。
それ以外の方法として、DMV から SQL Server の起動時間を取得するという方法をとることもできます。
今回の投稿ではこの方法についてまとめておきたいと思います。
SQL Server 2019 on Windows の Language Extension で .NET 5 C# が動作するようになりました
Open sourcing the .NET 5 C# Language Extension for SQL Server で発表がありましたが、SQL Server 2019 から使用することができるようになった Language Extension で .NET 5 C# が使用できるようになりました。
今回のアナウンスは、次のアナウンスの続きにあたるものになるのではないでしょうか。
- Open sourcing the Java language extension for SQL Server
- Open sourcing the R and Python language extensions for SQL Server
SQL Server では、このような機能を使用したデータ分析を Advanced Analytics と呼ぶこともありますが、機能を活用することで、標準の T-SQL では難しい分析を行うことが可能となります。
今回の C# の発表を読みながら、この領域の情報をまとめてみたいと思います。
使用方法のステップバイステップについては GitHub のコンテンツを参照すると実際に試すことができます。
AKS on Azure Stack HCI (Windows Server 2019) に対して Azure DevOps でパイプラインを実行するためのメモ
AKS on Azure Stack HCI (OS は HCI OS ではなく、Windows Server 2019) に対して、Azure DevOps パイプラインを実行しようと思った際の作業した内容のメモを。
最終的には Azure Arc Enabled Kubernetes の GitOps を使用することになるのかなとは思うのですが、今回はそこまでは試せていません。
高速データベース復旧 (ADR) の動作を把握するために必要となる情報
SQL Server 2019 以降と Azure SQL Database では、データベースの高速な復旧を可能とする高速データベース復旧 (ADR : Accelerated Database Recovery / CTR : Constant Time Recovery) という機能が搭載されています。
SQL Server 2019 では手動で有効化する必要がありますが、現在の Azure SQL Database ではデフォルトで有効化されており、無効にすることはできませんので、SQL Database を使用している場合には、必ず ADR が使用されています。
この ADR の挙動を把握する必要があり、情報を調査した際の内容をまとめておこうと思います。
SQL Server で特定テーブルに1件のレコードを最初にINSERTした場合、アクセスが発生するファイルを調べてみる
MySQLエキスパートyoku0825が目指す、DBAとしての未来像 を興味深く読ませていただいたのですが、記事の中の次の質問がとても面白い内容でした。
インストールされたばかりのMySQLがあるとして、特定テーブルに1件のレコードを最初にINSERTした場合、アクセスが発生するファイルとその理由をすべて教えてください
MySQLに初めてINSERTするとアクセスが発生するファイルは何かという質問をどう調べるのか で MySQL についてまとめられていますが、SQL Server ではどのようになるのかまとめてみました。