最近さぼっていましたが、Inspire 2021 が開催されたので、アップデートをまとめておこうかと。
Inspire 2021 の発表内容については Book of News が公開されていますので、これから確認できます。
データ関連はこんな感じで、大きな発表はあまりなかった印象です。
大きな発表は Windows 365 に持っていかれた感じですかね。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
最近さぼっていましたが、Inspire 2021 が開催されたので、アップデートをまとめておこうかと。
Inspire 2021 の発表内容については Book of News が公開されていますので、これから確認できます。
データ関連はこんな感じで、大きな発表はあまりなかった印象です。
大きな発表は Windows 365 に持っていかれた感じですかね。
SQL Server は、MS DTC (Microsoft Distributed Transaction Cordinator) をトランザクションマネージャーとして使用して、分散トランザクションの実行を行うことができます。
分散トランザクションについては、トランザクションのロックおよび行のバージョン管理ガイド で解説が行われています。
フローについては、1.3.1.2.3.2 Transaction Enlistment and Completion になるかと思いますが、コミットを「準備フェーズ」と「コミットフェーズ」の 2 フェーズで管理を行う 2 フェーズコミット (2PC) により、トランザクションの管理が行われます。
SQL Server の場合、インスタンス内の複数のデータベースにまたがる処理については、管理ガイドでは次のように記載されています。
数のデータベースにまたがる 1 つのSQL Server データベース エンジン内のトランザクションは実質的には分散トランザクションです。 ただし、SQL Server インスタンスは分散トランザクションを内部で処理するため、ユーザーにはローカル トランザクションとして動作しているように見えます。
実質は分散トランザクションではあるのですが、ローカルトランザクションのように見える処理が行われるため、MS DTC は使用されずに、処理が行われていたかと思います。
リンクサーバー / トランザクションスコープ (Transaction Scope) / BEGIN DISTRIBUTED TRANSACTION 等を使用した場合、実行方法によっては、MS DTC を使用した分散トランザクションとして実行され、分散トランザクションで実行される場合には、インダウト (in-doubt) トランザクション (未解決 / 不確定 / 不定トランザクション) の発生についての考慮が必要なケースが出てきます。
コミット時のインダウトトランザクションとしては、上記の図の xa_commit の部分になるかと思います。
分散トランザクションに参加しているトランザクションは最終的には、トランザクションマネージャーからの commit 要求により、各トランザクションのコミットが行われますが、コミットフェーズにおいて、特定のインスタンスでは、コミットが完了しなかったようなケースが発生した場合には、インダウト トランザクションとして、不確定のトランザクションをどのように取り扱うかを決めなくてはいけません。
インダウト トランザクションは 2PC の特定のタイミングでトランザクションを未確定にしなくてはいけないのですが、意図的に発生させる方法について残しておきたいと思います。
なお、windbg を使用して無理やり発生させていますが、本投稿では windbg の使用方法などについては触れませんのでご了承ください。
SQL Server のコールスタック (Call Stack) を確認にはいくつかの方法が利用することができます。
一番詳細な確認としては、WinDbg で確認する方法になるのではないでしょうか。 ![]()
それ以外には、Windows Performance Analyzer を使用する方法や、
Process Monitor / Process Explorer を使用する方法です。
これ以外の一つが「拡張イベントの Call Stack を SQL Call Stack Resolver を使用して確認する」という方法です。
拡張イベントの Call Stack については、他の方法でも確認することができるのですが、SQL Call Stack Resolver を使用する方法が容易かと思います。
本投稿では、SQL Call Stack Resolver を使用すると、どのように Call Stack が確認できるかを紹介したいと思います。
私は Windows の SQL Server でしか使っていないのですが、SQL Server on Linux (Docker 含む) で取得した拡張イベントに対しても、Call Stack の解決はできていそうでした。
Tools and Documents for fault analysis in SQL Server-based environments.
Query Store Hints Preview でアナウンスがありましたが、SQL Database でクエリストアヒントがプレビュー機能として使用できるようになりました。
今まで、クエリストアを使用した実行プランの補正としては、プランの強制という機能があり、同一のクエリで複数の実行プランがある場合、特定のプランを使用するようにプランを強制することができました。
この機能を実行プランの補正に使うことができたのですが、プランの強制は「強制したい実行プランの情報がクエリストアに格納されている」必要があり、使用したい実行プランの情報がクエリストア上に格納されている必要がありました。
今回使用できるようになった「クエリストアヒント」については、クエリストアに格納されている実行プランのクエリについて「クエリヒントを適用することができる」機能となっており、「強制したいプランがクエリストアに存在していない」状態でも、プランの補正を柔軟に実施することができます。
類似の機能としては「プランガイド」を使用して、クエリヒントをアタッチすることができましたが、クエリストアヒントはプランガイドより容易にクエリヒントを適用することが可能です。(プランガイド、設定するのに少し手間がかかるんですよね…。)
公式のドキュメントは次の内容を確認してください。
日本語版の SQL Server をインストールした環境の文字コード / 文字コードに関連するドキュメントについてまとめておきたいと思います。
今回はインストールタイプ (Box) の SQL Server を日本語版でインストールした環境をベースに考えていますが、これは、SQL Server のデータベースエンジンをベースとしている環境で共通の考え方になります。
過去のバージョンの情報にはなりますが、次の情報も参考になります。
SQL Server のクエリストアには「サイズベースクリーンアップ」という機能があります。
これについては、クエリ ストアを使用する際のベスト プラクティス に次のように記載が行われています。
重要
[最大サイズ (MB)] の制限は、厳密には適用されません。 ストレージ サイズは、クエリ ストアでディスクにデータが書き込まれる場合にのみ確認されます。 この間隔は、 [データのフラッシュ間隔 (分)] オプションによって設定されます。 クエリ ストアでストレージ サイズの確認の合間に最大サイズの制限を超えた場合は、読み取り専用モードに移行します。 [サイズ ベースのクリーン アップモード] が有効になっている場合は、最大サイズの制限を適用するクリーンアップ メカニズムもトリガーされます。
クエリストアの設定には最大サイズを指定する必要があり、この最大サイズに達した場合に、サイズベースのクリーンアップを行うことができます。(デフォルトはサイズベースクリーンアップが有効)
この動作について調べる必要があったので、確認した内容をまとめておきたいと思います。
SQL Server 2012 SP1 CU2 から、Backup to URL という機能がサポートされ、SQL Server のバックアップを Azure BLOB ストレージ上に直接取得することができるようになりました。
SQL Server 2012 / 2014 での実装では、ページ BLOB に対しての取得であり、制限事項 に記載されているようにストライピングでの取得ができないため、バックアップファイルの最大サイズは 1TB までとなります。
SQL Server 2012 ではバックアップの取得は次のようなクエリとなります。
CREATE CREDENTIAL azurestorage WITH IDENTITY = '<ストレージアカウント名>' , SECRET = '<アクセスキー>' ; BACKUP DATABASE AdventureWorks2012 TO URL = 'https://xxxxx.blob.core.windows.net/backup/adventureworks2012.bak' WITH CREDENTIAL='azurestorage',STATS=10
今回、Windows Server 2008 + SQL Server 2012 SP4 の環境を使用していたのですが、デフォルトの状態では、次のエラーが発生して、バックアップを取得できませんでした。
メッセージ 3271、レベル 16、状態 1、行 4 A nonrecoverable I/O error occurred on file "https://xxxxxx.blob.core.windows.net/backup/adventureworks2012.bak:" Backup to URL received an exception from the remote endpoint. Exception Message: リモート サーバーがエラーを返しました: (400) 要求が不適切です. メッセージ 3013、レベル 16、状態 1、行 4 BACKUP DATABASE is terminating abnormally.
Build 2021 後にアップデートの発表が続いているので、Build 前後で発表された内容を後で見るようにメモ。
Build 2021 で SQL Database の新機能として Ledger (台帳) がプレビュー機能として発表されました。
Ledger の初出は PASS Summit 2020 の Day2 Keynote になるのではと思いますが、実機でこの機能を検証することができるようになりましたので、試してみたいと思います。
公式ドキュメントは次の内容となるかと。
最終的にはすべての地域でプレビュー機能が利用できるようですが、投稿を書いている時点では「米国中西部」の論理サーバーでのみ利用することが可能です。(SLO は Basic でも使用できたので、従量課金で検証する場合も、基本機能検証であればコストは抑えられると思います)
そのため、Ledger データベース / CREATE TABLE の LEDGER=ON を実行するためには、米国中西部の論理サーバーに作成したデータベースで検証を行う必要があります。
学習の最初のステップとして Azure SQL Database ledger の内容を見ながら、Ledger がどのようなものなのかを学習したいと思います。
Ledger 全体の構成はこのようになります。