先日、SQL Server 2019 CU13 がリリースされました。
CU13 に含まれる内容の中に次の機能があります。
SQL Server 2019 CU13 では、ピアツーピアレプリケーションで、データ競合時に Last Writer Wins による競合の解決ができるようになったことと、可用性グループでピアツーピアレプリケーションがサポートされるようになりました。
Archive for the ‘SQL Server’ tag
SQL IaaS Agent 拡張機能がアップデートされています
Azure の VM (仮想マシン) でインストールタイプの SQL Server を使用する場合、SQL IaaS Agent 拡張機能を使用することで、IaaS の運用負荷を軽減させることができる様々な機能を無料で利用することができます。
Azure の VM で SQL Server をインストールする場合には、Marketplace の SQL Server インストール済みイメージを使用することが胃のではないでしょうか。Marketplace のイメージを展開する際には、「SQL Serer の設定」のタブで、SQL Server 向けの設定を行うことができますが、この時の設定を行ってくれているのが SQL IaaS Agent 拡張機能となります。
利用できる機能については、Azure portal を使用して SQL Server VM を管理する で紹介されている様々な内容となるのですが、この IaaS Agent 拡張機能でいくつかのアップデートが行われていたようなので本投稿で紹介したいと思います。
SQL IaaS Agent 拡張機能について知りたい場合には、次のドキュメントを確認するとよいかと思います。
ACR と Helm と SQL Server のメモ
ACR に格納した Helm のチャートで SQL Server の展開を行おうとした場合のメモ。
AKS on HCI でも一部の展開には Helm が使用されているので、概要はつかんでおかないとと思った次第です。
この辺の情報を取り掛かりにすれば、手を動かすことはできそうです。
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 が取得されるという考えは誤りですということを書いておきたいと思います。
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 ではどのようになるのかまとめてみました。