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 を使用することになるのかなとは思うのですが、今回はそこまでは試せていません。
高速データベース復旧 (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 の挙動を把握する必要があり、情報を調査した際の内容をまとめておこうと思います。