SE の雑記

SQL Server では実行プランを生成する際には、統計情報を基にして、処理対象となるデータの推定 (基数推定) が行われます。

• カーディナリティ推定 (SQL Server)

SQL Server の統計情報は、

• データ件数
• 最大 200 に分割されたデータ分布 (ヒストグラム) により構成される

• 分割の上限値 / 分割範囲の行数 / 分割の上限と同一値の行数 / 個別の値を持つ行数 / 重複する値を持つ行数の平均
• ヒストグラムは統計情報の先頭列のみで構成され、複数列統計を作成した場合でも複数列のヒストグラムは作成されない

• どの程度ユニークな値で構成されているか (密度が 1 になっている場合は、すべてのデータが同一の値となる)
• 複数列統計の場合、密度は列の組み合わせによって作成される
• SQL Server 2008 との互換性維持となる情報については、統計ヘッダーの密度であり、最新の SQL Server でも列単位の密度は使われている

が基本的な情報となり、この情報は以前の SQL Server から変化していないという認識です。

統計情報については、STATS_STREAM (STATS_BLOB) が実際の情報となりますが、次の情報からユーザーが視認できる形で確認を行うことができます。

• DBCC SHOW_STATISTICS (Transact-SQL)
• sys.dm_db_stats_histogram (Transact-SQL)

与えられたクエリのステートメントに対して、この統計情報を使用して行数を推定することで、クエリの実行プランが組み立てられ、この時の処理対象となる行数の推定が基数推定 (カーディナリティ推定: Cardinality Estimation: CE) となります。

本投稿では、この行数の推定である基数推定がどのように判断されているかを確認する際に参照する必要のある情報をまとめておきたいと思います。

Read the rest of this entry »

Non-yielding scheduler エラーの調査を実施する際の参考情報 の続きの投稿となるのですが、SQL Server で Non-yielding scheduler となる状態を作り出すため、スレッドと強制的に中断状態にして

• リングバッファーに RING_BUFFER_NONYIELD_COPIEDSTACK を出力
• 拡張イベントに scheduler_monitor_non_yielding_ring_buffer_recorded を出力

させるための方法のメモです。

本来は、スケジューラーモニターで次の状態を検知させ、ダンプを出力させるところまで再現したかったのですが、私の理解度が低く、そこまでは再現できていません。

 # Child-SP          RetAddr           Call Site
00 00000006`b2ddbc28 00007ffd`db9185c3 ntdll!NtWaitForSingleObject+0x14
01 00000006`b2ddbc30 00007ff6`cb98bb2e KERNELBASE!WaitForSingleObjectEx+0x93
02 00000006`b2ddbcd0 00007ff6`cb98b8a3 sqlservr!CDmpDump::InvokeSqlDumper+0x1ee
03 00000006`b2ddbdd0 00007ff6`cb98b5a4 sqlservr!CDmpDump::DumpInternal+0x1b3
04 00000006`b2ddbe80 00007ffd`c356e743 sqlservr!CDmpDump::Dump+0x24
05 00000006`b2ddbec0 00007ffd`c420d1b5 sqllang!SQLDumperLibraryInvoke+0x1f3
06 00000006`b2ddbf00 00007ffd`c420e046 sqllang!SQLLangDumperLibraryInvoke+0x185
07 00000006`b2ddbfc0 00007ffd`c41d8c42 sqllang!CImageHelper::DoMiniDump+0x6f6
08 00000006`b2ddc1e0 00007ff6`cb963eb5 sqllang!stackTrace+0xa42
09 00000006`b2dddc00 00007ffd`c5956840 sqlservr!SQL_SOSNonYieldSchedulerCallback+0x465
0a 00000006`b2dfdea0 00007ffd`c592e59b sqldk!SOS_OS::ExecuteNonYieldSchedulerCallbacks+0xe0
0b 00000006`b2dfe150 00007ffd`c58c54ef sqldk!SOS_Scheduler::ExecuteNonYieldSchedulerCallbacks+0x1ab
0c 00000006`b2dfe330 00007ffd`c58c47b2 sqldk!SchedulerMonitor::CheckScheduler+0x25e
0d 00000006`b2dfe4d0 00007ffd`c58c3d72 sqldk!SchedulerMonitor::CheckSchedulers+0x1ea
0e 00000006`b2dfee40 00007ffd`c59c47c9 sqldk!SchedulerMonitor::Run+0xc2
0f 00000006`b2dfef40 00007ffd`c58b9e53 sqldk!SchedulerMonitor::EntryPoint+0x9
10 00000006`b2dfef70 00007ffd`c58ba28f sqldk!SOS_Task::Param::Execute+0x232
11 00000006`b2dff570 00007ffd`c58ba05e sqldk!SOS_Scheduler::RunTask+0xbf
12 00000006`b2dff5e0 00007ffd`c58d79a2 sqldk!SOS_Scheduler::ProcessTasks+0x39d
13 00000006`b2dff700 00007ffd`c58d7b9f sqldk!SchedulerManager::WorkerEntryPoint+0x2a1
14 00000006`b2dff7d0 00007ffd`c58d83fa sqldk!SystemThreadDispatcher::ProcessWorker+0x42a
15 00000006`b2dffad0 00007ffd`df0c7974 sqldk!SchedulerManager::ThreadEntryPoint+0x406
16 00000006`b2dffbc0 00007ffd`df7ea2f1 kernel32!BaseThreadInitThunk+0x14
17 00000006`b2dffbf0 00000000`00000000 ntdll!RtlUserThreadStart+0x21

Read the rest of this entry »

Windows Server 2022 + SQL Server 2022 RC1 + SSMS 19.0 Preview 3 の環境で、ローカルの SQL Server に対して ostress.exe を実行した場合に、次のエラーが発生し、負荷をかけることができませんでした。

10/27/22 09:20:01.124 [0x00000D2C] SQLState: 08001, Native Error: 18
[DBNETLIB]SSL セキュリティ エラー

10/27/22 09:20:01.125 [0x00000D2C] SQLState: 01S00, Native Error: 0
接続文字列の属性が正しくありません。

今まで見たことがないエラーだったので、なぜ発生しているのかを調べてみました。

Read the rest of this entry »

自分のメモとなるのですが SQL Server で Non-yielding scheduler のエラーが発生した場合に必要となる情報をまとめておきたいと思います。

Read the rest of this entry »

Ignite 2022 が開催されています。更新内容については、Book of News から確認することができます。

SQL Server ベースの環境に関連するアップデートとしてどのようなものがあったかまとめておきたいと思います。

Data Platform 関連のキーノートセッションは次のようなものがあるようです。

• Microsoft Intelligent Data Platform により、迅速なイノベーションを実現し、より高い俊敏性を実現する
  • Tailwind Traders の構成、一度勉強しないとなと思いました。
  • なとなく調べたら、List of fictional companies used in Microsoft material が興味深かったです。
• Microsoft Azure でアジリティを高め、ビジネスを最適化し、データ主導型のエクスペリエンスを実現

Read the rest of this entry »

SQL Server 2022 RC 1 時点の情報となり、今後の Preview / 一般提供開始時には変更されている可能性もあります。

SQL Server 2022 の新機能として、Intel QAT (Quick Assist Technology) を使用した、バックアップの高速化とバックアップの負荷をハードウェアにオフロードするという機能があります。

• 統合された高速化とオフロード
• 統合された高速化とオフロードを構成する

Intel QAT を使用する場合、Intel® QuickAssist Adapter Family for Servers のようなハードウェアを使用しなくてはいけないのかと思っていたのですが、この機能はソフトウェアモードでも使用することができ、ハードウェア圧縮が使用できない場合でもソフトウェアで処理ができるようになっていました。

この機能を使用した場合の処理特性についてまとめておきたいと思います。

Read the rest of this entry »

サンプルアプリケーションを使って ADFS から Azure AD への認証移行ステップを確認する で解説されている AD FS を使用しているアプリケーションから Azure AD への移行を実施する際に使用できるデモを動作させる際のメモを。

久しぶりに AD FS を触ったら何も覚えていませんでした…。

AD FS 上のアプリをさらに Azure AD に移行するための新機能の提供 がどのような内容を表しているのかを検証するための下準備となります。

AD FS 上に WS-Federation 認証でサインインするサンプル アプリを登録するために必要な手順 も合わせて読んでおくとよいかなと思いました。

Read the rest of this entry »

Azure AD の証明書ベースの認証 (CBA) をスマートカードで検証する環境を準備してみる からの継続した検証のメモを。

CBA は、モバイルデバイスもサポートされており、Android / iOS でも使用することができます。

• モバイル デバイス (Android と iOS) での Azure Active Directory の証明書ベースの認証 (プレビュー)

普段使用している iOS / Android とは別に、使用していない昔の機種が手元になったので、これらを使用して検証ができるのかを確認してみました。

今回使用したのは次の機種となっており古いものなのですが、CBA の要件は、Android 5.0 以降 / iOS 9 以降と要件は厳しくないので証明書のインストールから Office ポータルへのアクセスについてはこれらの機種でも対応することが可能でした。

• Android: GALAXY S5 (SC-04F)

• OS: Android 6.0.1
• 2014 年モデル

• OS: iOS 9.3.6
• 2012 年販売

Android については、Android Studio をインストールし、Android Emulator を使用することでも検証することはできます。

Read the rest of this entry »

2022年9月下旬の Azure SQL Database Update の情報がアナウンスされたのでまとめておこうと思います。

• Azure SQL—General availability updates for late September 2022
• Azure SQL—Public preview updates for late September 2022
• Azure Synapse Analytics September Update 2022

アップデートには含まれていないが、当月更新されたものもなりますので、それらも追記しています。

Read the rest of this entry »

先日、AWS で RDS Proxy が SQL Server をサポートしました。

• Amazon RDS Proxy が Amazon RDS for SQL Server のサポートを開始

RDS Proxy を使用せずに Lambda と RDS を組み合わせた場合には、

• なぜAWS LambdaとRDBMSの相性が悪いかを簡単に説明する
• LambdaとRDSで爆死してみる
• Lambda+RDSはアンチパターン

というような影響を受け、リクエストごとにコネクションを生成してしまうため RDS Proxy を介して接続をすることで接続を最適にすることができることは把握していたのですが、Azure Functions の HTTP Trigger を使用した場合には、どうなるのかを今まで気にしていなかったので、この機会に確認をしてみました。

しばやん先生からフィードバックいただいた、こちらの内容のとおりではありますが、実際に挙動を確認して把握しておこうかと。

Consumption Plan でも 200 までしかスケールしないので、Azure Functions では Connection Pool を使うようにしておけばまず問題にならない認識です（最近は Consumption Plan が必要な場面ではまず Cosmos DB しか使ってませんが

— Tatsuro Shibamura (@shibayan) September 20, 2022

Read the rest of this entry »