SQL Server で既にデータが格納されているテーブルに外部キー制約 (Foreign Key Constraint) を設定する際に、デフォルトの設定で外部キーを設定した場合、「WITH CHECK」が既定の動作となるため、テーブル間でデータ整合性のチェックが行われています。
このチェックの際には、どのようなクエリが実行されているのかを本投稿でメモとして残しておきます。(以前から書こうと思っていて忘れていた内容)
Archive for the ‘SQL Server’ Category
変更の追跡 (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 が取得されるという考えは誤りですということを書いておきたいと思います。
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 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 のコンテンツを参照すると実際に試すことができます。
高速データベース復旧 (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 ではどのようになるのかまとめてみました。