SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
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 全体の構成はこのようになります。
Build 2021 のタイミングに合わせて発表された内容を。
SQL Server / SQL Database のクエリ情報を確認する際に活用できる クエリストア では、様々な情報を確認することができ、その項目の一つとして「CPU 時間 (ミリ秒) の合計」があります。
この項目は、SSMS から GUI でクエリストアの情報を確認するときに利用することができます。
本投稿では、SSMS からクエリストアの情報を確認する際に利用できる「合計」について触れたいと思います。
本投稿では、CPU 時間についてフォーカスしていますが、他の合計も基本的な考え方は同一です。
SQL Server から SQL Server ベースの環境に移行 (マイグレーション / バージョンアップ) を実施する場合のアセスメントとデータ移行を実施するためのツールとして、Database Migration Assistant (DMA) というツールが提供されています。
このツールを使用すると SQL Server のバージョンアップや Azure SQL Database への移行を行う際のアセスメント / マイグレーションを実施することができます。
DMA では、サポートされているソース バージョンとターゲット バージョン に記載されているソースとターゲットをサポートしており、これらの組み合わせの SQL Server ベースの環境をサポートしています。
SQL Database へのデータ移行時の方法については、本ブログでも Database Migration Assistant (DMA) で SQL Server から SQL Database へのデータ移行方法について で触れたこともありますね。
DMA のアセスメントで、移行のブロッカーとなる要素が検知されると、アセスメントの結果として次のように表示が行われます。
「どのような検索を行い、問題として検知しているか」については、抽出することはできないのですが、「どのようなルールが存在しているか」については、DMA のインストールディレクトリ内のファイルから、一部情報を確認することができます。
本投稿では、ファイルから SQL Database に移行する際のアセスメントで検知されるルールについて確認をしてみたいと思います。
使用しているスクリプトや出力結果については、こちら で公開していますので必要に応じて参考にしていただければと思います。
