2 回目にして毎週更新ができていません (orz) が、前回更新から本日までの更新情報を。
Author Archive
SQL Server 2019 CU6 でクエリストアの強制 OFF が可能になりました
本日、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 と Log Analytics による SQL Database のメトリック収集 (EZMonitor)
Azure Functions が PowerShell 7.0 をサポートしたこで、PowerShell をランタイムとして使用した関数で、ForEach-Object の Parallel が使用できるようになり、スクリプトブロックを並列で実行することができるようになりました。
以前は Runspace を作成して、並列処理を自分で組む必要がありましたが、ForEach-Object でシンプルな記述で並列に実行できるようになったのはうれしいですね。
このような並列処理は、DB のメトリックを取得するときの収集処理で活用することができ、メトリック収集用のクエリを一つ順次実行するのではなく、いくつかのクエリを並列で実行することで、処理時間を短縮することができ、鮮度の良い情報の取得を行うことができます。
SQL Database では、標準でいくつかの方法で情報が取得されています。
- Azure SQL Database の Query Performance Insight
- Azure SQL Analytics (プレビュー) を使用した Azure SQL Database の監視
- Azure SQL Database と Azure SQL Managed Instance での監視とパフォーマンス チューニング
これらの標準機能を使用しても、情報の収集を行うことも、もちろん可能ですが、特定の状況かで必要となる情報が不足していることがあり、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 / 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
エクステント数による DROP INDEX の動作の違い
twitter で、DROP INDEX (Transact-SQL) の次の記載についてのつぶやきがあり、興味を持ったので、軽く動作確認をしてみた際の内容を。
128 以上のエクステントを持つインデックスを削除すると、データベース エンジンは、トランザクションがコミットされるまで実際のページの割り当て解除と関連するロックを遅らせます。
2020/7/20～7/26 の SQL Server / SQL Database 関連の更新情報
最近、情報のキャッチアップの速度が遅くなっているので、(できたら) 一週間に一度ぐらいは、自分に関係しそうな更新情報をまとめたいなと思います。
Synapse Workspace の Manged VNET への関連付けについてのメモ
Synapse Workspace では、ワークスペースのリソースをデプロイする際に、Managed VNET に関連付けができます。(デプロイ時にのみ設定することができ、ワークスペースの作成後に設定を変更することはできません)
詳細については、Azure Synapse Analytics のマネージド仮想ネットワーク (プレビュー) に記載されているのですが、この辺の設定がいまいちわかっていなかったので、情報を整理しておこうかと。
Azure Shared Disk を使用した SQL Server Failover Cluster Instance (FCI) の構築
先日 Preview support for Azure Shared Disks for SQL Server failover cluster instance on Azure IaaS is now available というアナウンスがありました。
詳細なアナウンスについては Lift and Shift Always On SQL Server Failover Cluster Instance (SQL FCI) to Azure VMs でも公開されています。
SQL Server 2019 CU2 以降+ Windows Server 2019 以降を使用することで Azure 上で、共有ディスク型の Failover Cluster Instance (フェールオーバー クラスター インスタンス : FCI) を構築できるようになりました。
軽く構築をしてみてみましたのでその際のメモを。
構築方法については、Create an FCI with Azure shared disks (SQL Server on Azure VMs) を参照してください。
Azure Functions で PowerShell 7.0 が使用できるようになりました
アナウンスされていたのかがわかっていないのですが、以前から manually specify powershell version (e.g. 7) という Issue があり、Azure Functions の PowerShell 7.0 のサポートについてディスカッションが行われていました。
The rough ETA for official GA (including portal and tools support) is the beginning of July.
正式な GA は 7 月上旬ということになっていたので、ポータルを確認してみたところ、7.0 を選択できるようになっていました。 
Windows 上で動作している PowerShell 7.0.0 として認識されていますね。
PowerShell 7.0 になると、ForEach-Object に追加された並列実行 が使用できるようになるのがうれしいですね。
(Foreach の Parallel については Example 11: Run slow script in parallel batches 以降の情報も参考になります)
Azure Functions の PowerShell のランタイムスタックですが、昔は関数のテンプレートは HTTP / Timger Trigger 程度だったと思っていたのですが、今は使用できるテンプレートが増えており、各種トリガーや Preview で Durable Functions のテンプレートも選択できるようになっています。 
まだドキュメントは読めていないのですが、Durable Functions Support for PowerShell で Issue が上がっており、Github 上で、How to try Durable PowerShell functions として、チュートリアルが公開されています。
SQL Database 関連の関数を Timer トリガーで作ることは結構あるのですが、それ以外のトリガーは使っていなかったので、色々なトリガーを触ってみないとですね。
Visual Studio Code を使用した PowerShell の関数開発でも、PowerShell 7.0 を使用することができるようです。
PowerShell 7.0 を使用するためには、ランタイムバージョンは 3.0 を使用するようにして、次のような設定を行う必要があるようです。
1. Azure Functions Core Tool 3.x をインストールする
npm install -g azure-functions-core-tools@3
2. 「.vscode\settings.json」 の「azureFunctions.projectRuntime」を「~3」に変更
(Core Tool 3.x が入っていれば、デフォルトで ~3 になっていると思います)
3. 「local.settings.json」に「"FUNCTIONS_WORKER_RUNTIME_VERSION": "~7"」を追加
これで、VS Code で PowerShell Functions の開発を行った際の PowerShell のバージョンを 7.0 にすることができます。
SQL Server / SQL Database パフォーマンスチューニング & トラブルシューティング シリーズ : SOS_SCHEDULER_YIELD の基本的な考え方について
SQL Server / SQL Database で CPU 使用状況が高い場合に発生する「待ち事象」としては、「SOS_SCHEDULER_YIELD」が有名ではないでしょうか。
待ち事象については、sys.dm_os_wait_stats (Transact-SQL) で解説が行われており、SOS_SCHEDULER_YIELD については、次のように解説が行われています。
タスクが、他のタスクの実行にスケジューラを自主的に解放したときに発生します。 この待機中、タスクはクォンタムの更新を待機しています。
これはどのようなことを表しているのでしょうか？
本投稿では、SOS_SCHEDULER_YIELD の基本的な考え方について見ていきます。