ACR に格納した Helm のチャートで SQL Server の展開を行おうとした場合のメモ。
AKS on HCI でも一部の展開には Helm が使用されているので、概要はつかんでおかないとと思った次第です。
この辺の情報を取り掛かりにすれば、手を動かすことはできそうです。
Archive for 9月, 2021
SQL Server でデータが格納されているテーブルに外部キー制約を設定する場合に実行されているクエリ
SQL Server で既にデータが格納されているテーブルに外部キー制約 (Foreign Key Constraint) を設定する際に、デフォルトの設定で外部キーを設定した場合、「WITH CHECK」が既定の動作となるため、テーブル間でデータ整合性のチェックが行われています。
このチェックの際には、どのようなクエリが実行されているのかを本投稿でメモとして残しておきます。(以前から書こうと思っていて忘れていた内容)
変更の追跡 (Change Tracking) のクリーンアップについて
SQL Server では、変更の追跡 (Change Tracking) を使用することで、変更されたデータの主キーの項目を追跡することができます。
変更の追跡は、データベースレベルで保持期間の設定を実施することができます。
データの保持期間を設定することができ、「自動クリーンアップ」の設定を行うことができ、クリーンアップの挙動については、変更の追跡のクリーンアップ に記載されています。
クリーンアップについて調べる機会があったので、調べた内容をまとめておこうと思います。
最初に結論を書いておくと、
- 変更の追跡のクリーンアップを手動で制御することはできない
- 自動クリーンアップが有効になっていないと、変更の追跡のデータを削除できない
となると思います。
変更の追跡の詳細な動作については、次の記事を参照するとよいと思います。
- Deep Dive into Change Data Capture (CDC) in Azure SQL Databases
- Change Tracking Cleanup?Part 1
- Change Tracking Cleanup ? Part 2
- Change Tracking Cleanup?Part 3
手動でクリーンアップを実施したい場合については、次のドキュメントの内容が参考になります。(トラブルシューティングを実施する際に必要となる情報が多数記載されています)
SQL Server で Seek によりREAD COMMITTED で 1 行取得する際には行ロックが必ず取得されるということではないというお話
SQL Server で C1 をクラスター化インデックスとして設定されている次のようなテーブルがあるとします。
SQL Server のデフォルトの READ COMMITTED 分離レベルが設定されている状態に対して、次のクエリを実行した場合にどのようなロックが取得されるのかというのが本投稿の内容です。(SQL Server のデフォルトの動作であるため、READ COMMITTED SNAPSHOT ISOLATION (RCSI) は無効の状態です)
SELECT * FROM [dbo].[CT_01] WHERE C1 = 100001
C1 に対してクラスター化インデックスが設定されていますので、「C1 = 100001」のレコードに対して、Key Lock (行ロック) が取得されると思うかもしれませんが、「取得されているロックの状態で変わり、Key Lock が取得されないこともある」が答えとなります。
取得されているロックの状態によっては、上記の SELECT を実行した際に Key Lock は取得されず、データの検索が行われることもあります。
本投稿では、Clustered Index Seek により、ピンポイントで 1 件のデータを取得する場合に、必ず Key Lock が取得されるという考えは誤りですということを書いておきたいと思います。
Azure Arc Enabled Server の Windows エージェントを Windows Update でアップデート
Azure Arc Enabled Server で Windows Server を管理している場合、Azure Connected Machine Agent によって Azure に接続がされるのですが、エージェントのバージョンが古くなると、Azure Arc 上で次のような表示が行われます。
エージェントのアップグレードについては次のドキュメントに記載されています。
エージェントのアップデート方法については次のような記述となっています。
Windows エージェント
Windows 用 Connected Machine エージェントの更新プログラム パッケージは、以下から取得できます。
Microsoft Update
Microsoft ダウンロード センターから Windows エージェント Windows インストーラー パッケージ。
Azure Arc Enabled Server の Windows エージェントについては、Microsoft Update (Windows Update) 経由でもアップデートができるようになっています。
標準の Windows Update の設定では、検知されないようなので、Windows Update の「詳細オプション」から「Windows の更新時に他の Microsoft 製品の更新プログラムも入手します」を有効化しておきます。
これで、Windows Update を実行した際に、「AzureConnectedMachineAgent」も更新対象として認識され、Windows Update 経由でエージェントを更新できるようになります。
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 を使用することになるのかなとは思うのですが、今回はそこまでは試せていません。