SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
2020/9/14 に 11 年前に発売された 平山さん の著書である 絵で見てわかるSQL Serverの内部構造 の改訂版となる 絵で見てわかるSQL Serverの仕組み という SQL Server の書籍が発売されました。
Kindle 版の販売がまだ先だったので、紙の書籍を購入したものが今日届き、一通り目を通すことができましたので感想などを。
最新の SQL Server をターゲットとして、日本語で内部の動作に触れている書籍は、現時点ではこの書籍だけで、前作と同様に今回の改定版も良著ですので、「SQL Server を単純に操作するのではなく、内部動作を理解して製品を使用できるようになりたい」という思いがある方にとっては、最適な書籍ですので一度読まれてみてはいかがでしょうか。
本投稿の内容を使用すると、クエリの実行プランに大きく影響を与えますので、検証目的でクエリの実行プランを変更する場合以外、本投稿の内容は使用しないでください。
ドキュメントにも「サポートされていない」ことが明記されており、本番環境で実行して、クエリの実行に大きく影響を与えても一切の責任は取りません。
クエリの実行に影響があると、本業務に影響を与える環境に対して実施する場合は自己責任で実施してください。
ということで、検証以外では、本投稿の内容は使用しないでください。
この投稿の内容は、クエリの実行プランが大きく変わり、性能にダイレクトに影響を与えます。
本来の目的はクローンデータベースを作成する際に、検証目的で統計情報の復元を行うためのものですので、統計情報の固定に使おうとすると、予期せぬ動作を引き起こす可能性が十分にあります。
以前書いた、SQL Server のクエリプロファイリングの活用 の応用ではありますが、この方法は、非クラスター化インデックスを新規に作成するときにも活用することができます。
Enterprise Edition であれば、オンラインのインデックス操作でインデックスを作成することもできますが、データ量が大きい場合、実際のインデックス作成の状況がどこまで進んでいるのかを確認したいということはあると思います。(クエリの処理状況がわかると、メンテナンス作業を実行している最中の心理的安定性にもつながりますので)
クエリ プロファイリング インフラストラクチャ の機能を使用しており、SQL Server 2016 SP1 / Azure SQL Database であれば、オーバーヘッドを抑えて使用することができるかと。
定期的な更新とか、僕には無理だったんだ…。
ということで 2 週間分をまとめておこうかと。
SQL Server の Enterprise Edition を使用している場合は、「オンラインでのインデックスメンテナンス」を実行することができます。
オンラインインデックスのメンテナンスの動作については オンライン インデックス操作の動作原理 で解説が行われていますが、オンラインのインデックスの最後のフェーズでは、瞬間的ではありますが、「SCH-M」のロックが取得されます。
SQL Server 2016 以降 / SQL Database で利用することができるクエリストアでは、実行されたクエリの種類を、
query_store_runtime_stats から、次のような内容で判断することができます。
アプリケーションから実行されたクエリの状態が、クエリストア上で通常実行として認識される状態の理解が少し足りていなくて、調べたので本ブログでもまとめておこうと思います。
2 回目にして毎週更新ができていません (orz) が、前回更新から本日までの更新情報を。
本日、SQL Server 2019 で Cumulative Update 6 (CU6) がリリースされました。
その中で興味深い改善として次の内容があります。
SQL Server 2019 CU6 から、クエリストアを無効 (OFF) にする際に、同期的なフラッシュを行うことなく、即時にクエリストアを無効化するようにできるようになりました。
How to Turn Off Query Store…in an emergency でも話題に挙げられていますね。
構文としては、次のクエリの実行が可能となるようです。
<br />ALTER DATABASE SET QUERY_STORE = OFF (FORCED) <br />
追記 :
SQL Server 2016 SP2 CU12 でもこの機能がサポートされたようです。
Azure Functions が PowerShell 7.0 をサポートしたこで、PowerShell をランタイムとして使用した関数で、ForEach-Object の Parallel が使用できるようになり、スクリプトブロックを並列で実行することができるようになりました。
以前は Runspace を作成して、並列処理を自分で組む必要がありましたが、ForEach-Object でシンプルな記述で並列に実行できるようになったのはうれしいですね。
このような並列処理は、DB のメトリックを取得するときの収集処理で活用することができ、メトリック収集用のクエリを一つ順次実行するのではなく、いくつかのクエリを並列で実行することで、処理時間を短縮することができ、鮮度の良い情報の取得を行うことができます。
SQL Database では、標準でいくつかの方法で情報が取得されています。
これらの標準機能を使用しても、情報の収集を行うことも、もちろん可能ですが、特定の状況かで必要となる情報が不足していることがあり、SQL Database の状態を確認するためは、追加でメトリックの収集を行う必要が出るケースがあります。
そのような場合、私は PowerShell で SQL Database に対してクエリ実行を行いメトリックの収集を行い、そのメトリックを Log Analytics に格納することで確認をしているのですが、情報を取得 / 可視化を毎回一から作るのも面倒ですので、ある程度まとまった仕組みを EZMonitor (Easy Monitor) として作成してみました。
(情報収取のクエリについては、ざっくりしたもののみ追加しているため、まだ修正の必要がありますが)
↓ GitHub のリポジトリからも、こちらのアイコンからもデプロイできます。
展開時に情報の取得を行う、SQL Database を指定することで、Log Analytics に取得を行ったデータを、次の画像のように可視化することができます。
標準では、5 秒間隔で 4 スレッドで情報を取得しており、Basic / S0 のような低い性能のサービスレベルでは、CPU の使用率を上昇させる要因になります。
CPU 使用率を上昇させた場合は、取得間隔や並列度数を調整してください。
SQL Server / SQL Database の実運用環境では、ロックについて悩まされることが多々あるのではないでしょうか。
SQL Server のロックの基本的な動作の理解はトラブルシューティングでは重要となりますので、SQL Server のロックの基礎について、本シリーズでもまとめておきたいと思います。
今回は次のようなテーブルを例にして、解説を行いたいと思います。
SET NOCOUNT ON
GO
DROP TABLE IF EXISTS LockTEST
CREATE TABLE LockTEST(
C1 int identity primary key,
C2 varchar(36) DEFAULT NEWID(),
C3 float DEFAULT RAND() * 10,
C4 float DEFAULT RAND() * 100
INDEX NCCIX_LockTEST_C3 (C3),
INDEX NCCIX_LockTEST_C4 (C4)
)
GO
INSERT INTO LockTEST DEFAULT VALUES
GO 10000