SE の雑記

SQL Server 2016 以降 / SQL Database で利用することができるクエリストアでは、実行されたクエリの種類を、

query_store_runtime_stats から、次のような内容で判断することができます。

アプリケーションから実行されたクエリの状態が、クエリストア上で通常実行として認識される状態の理解が少し足りていなくて、調べたので本ブログでもまとめておこうと思います。

Read the rest of this entry »

2 回目にして毎週更新ができていません (orz) が、前回更新から本日までの更新情報を。

Read the rest of this entry »

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 使用率を上昇させた場合は、取得間隔や並列度数を調整してください。

Read the rest of this entry »

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

Read the rest of this entry »

twitter で、DROP INDEX (Transact-SQL) の次の記載についてのつぶやきがあり、興味を持ったので、軽く動作確認をしてみた際の内容を。

128 以上のエクステントを持つインデックスを削除すると、データベース エンジンは、トランザクションがコミットされるまで実際のページの割り当て解除と関連するロックを遅らせます。

Read the rest of this entry »

最近、情報のキャッチアップの速度が遅くなっているので、(できたら) 一週間に一度ぐらいは、自分に関係しそうな更新情報をまとめたいなと思います。

Read the rest of this entry »

SQL Server / SQL Database で CPU 使用状況が高い場合に発生する「待ち事象」としては、「SOS_SCHEDULER_YIELD」が有名ではないでしょうか。

待ち事象については、sys.dm_os_wait_stats (Transact-SQL) で解説が行われており、SOS_SCHEDULER_YIELD については、次のように解説が行われています。

タスクが、他のタスクの実行にスケジューラを自主的に解放したときに発生します。 この待機中、タスクはクォンタムの更新を待機しています。

これはどのようなことを表しているのでしょうか？

本投稿では、SOS_SCHEDULER_YIELD  の基本的な考え方について見ていきます。

Read the rest of this entry »

書こう、書こうと思っていながらかけていなかったのですが、What is MaxDOP controlling? という記事が公開されたので、良い機会と思い、CXPACKET が発生している実行中のクエリのリソース情報の取得についてまとめたいと思います。

Read the rest of this entry »

2020/7/1 に SQL Database で次のような障害が発生しました。

7/1

Azure SQL Database – Japan East – Mitigated (Tracking ID CLCK-LD0)

Summary of Impact: Between 09:30 and 11:15 UTC on 01 Jul 2020, a subset of customers using SQL Database in Japan East may have experienced service connection failures or possible timeouts. Services utilizing SQL Databases may have also been impacted.

Preliminary Root Cause: We determined that instances of a gateway service responsible for handling traffic to and from some SQL Databases became unhealthy. This prevented some connections from completing as expected and caused downstream impact to services leveraging SQL Databases.

Mitigation: We performed a manual restart of the impacted gateways to mitigate the issue.

Next Steps: We will continue to investigate to establish the full root cause and prevent future occurrences. A full Root-Cause Analysis will be provided in the next 72 hours. Stay informed about Azure service issues by creating custom service health alerts: https://aka.ms/ash-videos for video tutorials and https://aka.ms/ash-alerts for how-to documentation.

最終的な RCA (Root Cause Analysis : 根本原因解析) としては、次のような内容が公開されています。

Summary of impact: Between 09:24 and 11:15 UTC on 01 Jul 2020, a subset of customers using Azure SQL Database, Azure SQL Data Warehouse/ Synapse analytics in Japan East may have experienced service connection failures or possible timeouts. Services utilizing SQL Databases may have also been impacted.

Root cause: Connections to Azure SQL Database and related data services go through a load balanced set of front-end nodes (Gateways) that provide directory lookup services and reroute the incoming connections to the intended backend-end nodes hosting the database. For scalability and zone redundancy purposes, there are multiple active SQL Gateway clusters in a region. During this incident, one of the SQL Gateway clusters became unhealthy having an intermittent impact on login availability. A specific network traffic pattern combined with a networking stack configuration on the SQL Gateway instances triggered an imbalance on the CPU processing of new connection requests. The persistence of such CPU imbalance over a long period of time caused high response latency and increased timeouts on connection requests. The error condition propagated across multiple instances of the SQL Gateway cluster in this region, sometimes causing a service restart.

Mitigation: Multiple SQL Gateway instances became healthy upon the triggered service restart. On further investigation, we were able to isolate the specific network pattern and the configuration setting that caused this incident and were able to reconfigure the traffic to prevent a recurrence.

Next Steps: We apologize for the impact to affected customers. We are continuously taking steps to improve the Microsoft Azure platform and our processes to help ensure such incidents do not occur in the future. In this case, this includes (but is not limited to):

• Fix the underlying issue that causes service restart when such a condition occurs.
• Improve the alerting logic and add identified telemetry to diagnose this kind of issues faster.
• Activate a newer SQL Gateway cluster in this region with a more efficient networking stack configuration that reduces the chances of hitting a processing imbalance.

障害の原因としては、「SQL Gateway クラスタ」の一つで問題が発生し、新規接続要求の CPU 処理の問題や、エラーが複数の SQL Gateway クラスターに伝搬しサービスが再起動してしまい、ログインと可用性に断続的に影響を与えたということになっています。

この障害が発生していた際には、既存の接続ついては接続が維持できていたが、新規の接続が許可されないというような状態になっていた環境もあったのではないでしょうか。

障害が発生している最中に、新規の接続を試してみたのですが、SQL Database の論理サーバー名への接続を行おうとしてもタイムアウトが発生 / Pre-Login のフェーズまでは進んだが、そこから先に進むことができず、エラーとなるというような状態となっており、新規の接続を確立することができませんでした。

障害が回復した後に、SQL Database のセッションの状態や起動タイミングを確認してみたところ、データベースについては再起動が行われておらず、いくつかのセッションについては接続が切断されず残ったままとなっていましたので、私の環境については、データベースでは問題は発生しておらず、ゲートウェイ経由での接続のみ問題が発生していたようでした。

以前、SQL Database v12 の接続のリダイレクトについて という投稿を書いたのですが、改めて、SQL Database に接続する際には、どのような動作が行われているのかをまとめてみたいと思います。

Read the rest of this entry »

Build 2020 のセッションでは、発表はなかったようなのですが、先月開催されていた、DataPlatformGeeks Virtual Symposium ので Start modernizing your workloads at scale with Managed Instance でSQL Database Managed Instance (マネージドインスタンス) のロードマップが公開されました。

このセッションで、どのような機能強化が予定されているのかが発表されたのかをまとめておきたいと思います。

現時点で実装されている機能については、次のようになっています。

Read the rest of this entry »