2024 年に入ってからの SQL Server / SQL Database のアップデートをキャッチアップできていなかったので、一度まとめておきたいと思います。
- Azure Updates
- Preview
- GA
- Azure SQL Blog
- SQL Server Blog
- SQL Server
- SQL Database
- Azure Arc
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
2024 年に入ってからの SQL Server / SQL Database のアップデートをキャッチアップできていなかったので、一度まとめておきたいと思います。
SQL Server ベースの CI/CD に活用できるツールとして SqlPackage があります。
SqlPackage は、データ層アプリケーション (DAC) を操作するためのツールとなり、DACPAC / BACPAC の操作を行うことができます。
このツールのアクションとして「Script」があり、SqlPackage スクリプト パラメーターとプロパティ の機能により、DACPAC や SQL Server ベースの環境とスキーマ比較をし、増分更新で状態を反映するスクリプトの作成ができます。(Publish パラメーターを使用することで直接発行することができます。基本は増分更新ですが、オプション (/p:DropObjectsNotInSource=true) で削除スクリプトを生成するかを調整することができます。)
この機能を、SQL Database に対して SQL 認証のログインで実行しようとした場合には注意点があったため本投稿でまとめておきたいと思います。
SQL Server はクエリの実行時には 統計情報 を使用してクエリの実行プランを生成しています。
統計情報は、以下のような情報で構成されており統計情報の作成を行うテーブルのデータを参照して情報を作成する必要があります。
統計情報を更新する際に実データに対しての検索が行われますがどのようにデータ取得が行われているかについてまとめておきたいと思います。
SQL Server のストアドプロシージャでは次のようなタイミングでコンパイル / リコンパイルが発生します。
上記のケースの中で「1.」「2.」については発生すると複数のセッションで同時実行性の低下につながるケースがあります。
どのような情報が出力されていると、「1.」「2.」のケースで同時実行性が低下している可能性があるのかをまとめておきたいと思います。
今回はストアドプロシージャを対象としており、アドホッククエリやパラメーター化クエリについてはこの動作とは異なってきます。
SQL Server では別名を作成する機能があり、リンクサーバーで別のサーバーに接続を行う場合などにサーバー名のエイリアスを作成して使用することができます。
SQL Server 2019 までは、SQL Server 構成マネージャーで設定を行うことができました。
SQL Server 2022 の構成マネージャーでも同様の UI が提供されているのですが、新しい別名を作成することはできなくなっています。(新規に別名を作成しようとしても、サーバー名の入力等ができなくなっています)
SQL Server 2022 以降でも別名を使用することはできますが、作成方法が変わっていますので、本投稿で触れておきたいと思います。
SQL Server の ログ配布 のリストア時の設定として「バックアップの復元時にデータベースのユーザーを切断する」(disconnect_users=1) という設定があります。
この設定は、ログ配布でリストアをしているデータベースに対して「スタンバイ モード」を使用してリストアを行い読み取りが可能なデータベースに対して使用することができるオプションとなります。
読み取りが可能な状態でログ配布を使用している場合、ログをリストアする際にログ配布のプロセス (logship.exe) がデータベースを排他的に利用できない場合、リストアを行うことができないため上記のオプションを設定することでリストアの直前に既存の接続を切断することで、ログ配布が排他的にデータベースを設定することができます。
しかし、この設定を有効にしていてログ配布のプロセスが排他的にデータベースを利用することができず、「エラー: データベースは使用中なので、排他アクセスを獲得できませんでした。RESTORE LOG が異常終了しています。(.Net SqlClient Data Provider)」というエラーが発生するケースがあります。
本投稿では「バックアップの復元時にデータベースのユーザーを切断する」を有効にしていても、リストア時の上述の排他エラーが出る理由についてまとめておきたいと思います。
本事象は「スタンバイモード」を使用する場合に発生するものとなり、「復旧モード無し」にしている場合は、リストア状態のデータベースにアクセスすることはできないため、スタンバイモードを利用していない場合には発生しないはずです。
クエリストアの状態については sys.database_query_store_options で情報が公開されています。
操作モードの中には「ERROR」という状態があり、ERROR を解消するためには「sp_query_store_consistency_check」を実行する必要があります。
このストアドプロシージャの動作確認を実状態と合わせて行う場合には、クエリストアの状態を ERROR にする必要があります。
イレギュラーな操作となりますが、クエリストアを意図的に ERROR にすることは可能ですので、操作方法を残しておきたいと思います。
Ignite / PASS で発表された Azure Arc 対応 SQL Server (Azure Arc Enabled SQL Server) の新機能となる、モニターによるメトリック収集 (パフォーマンスダッシュボード) について情報を残しておきたいと思います。
本日、PASS Data Community SUMMIT 2023 / Ignite 2023 が開催され、SQL Server / Azure SQL の様々な Update が発表されましたのでまとめておこうと思います。
発表の全体については、次の情報から参照することができます。
Ignite 2023
PASS Data Community SUMMIT 2023
クエリストアにより情報が取得される仕組みについては クエリ処理 で解説が行われています。
基本的な仕組みとしてはこのドキュメントで解説されている次の図となります。
クエリ実行実のいくつかのタイミングでクエリストアの情報にアクセスがされるのですが、処理のタイミングによってはクエリストアに対してロックの取得が行われます。
実行されているワークロードによりますが、クエリストアに対して取得されるロックが同時実行性に影響を与え、クエリストアに関係するロックの解析が必要となるケースがあります。