SE の雑記

Synapse Analytics の SQL on-demand(Serverless SQL Pool) と、Azure Storage の Query Acceleration では、Azure Storage 上のファイルに対して、SQL を実行することが可能です。

どちらもファイル対して、SQL を実行する機能ではありますが、これらの機能ではどのような違いがあるのか気になったので簡単にではありますが比較してみました。

ツールによりデータを取得するか、SDK からクエリを実行してデータを取得するかという、そもそものユースケースに違いがありますので、あまり比較しても意味はないかもしれませんが、ざっとした比較では次のようになるかと。

Ignite 2020 の What’s New in Azure Storage では、Query Acceleration に関しては、次のような解説が行われていました。

「Deeply integrated into Azure Synapse Analytics for improved performance and cost」と説明がされています。
具体的にどのように Synaspe Anaytics と統合されているのかまでは解説されていないのですが、Synapse Analytics で使用されている Polaris という分散 SQL エンジンが内部的には使用されているのかもしれませんね。

Read the rest of this entry »

SQL Server Management Studio 18.7 now generally available でアナウンスされていますが、本日 SSMS 18.7 がリリースされました。

18.7 から、SSMS のインストール時に Azure Data Studio (ADS) が同時にインストールされるようになりました。
これについては リリースノート にも記載されています。

Azure Data Studio がリリースされてから、2 年以上経過しますが、Azure Data ファミリーを使用する際には、SSMS だけでなく、Azure Data Studio を組み合わせて利用する機会が多くなってきており、SSMS を利用しているユーザーが Azure Data Studio の機能の恩恵を受けられるようにするということで、同時にインストールされるようになったようです。

Read the rest of this entry »

DNN については、以前、Lift and Shift Always On SQL Server Failover Cluster Instance (SQL FCI) to Azure VMs で、SQL Server 2019 CU2 を適用することで、Failover Cluster Instance のサポートが行われていました。

今回、Released: Support for Dynamic Network Names (DNN) Listeners for Always On Availability Groups でアナウンスがあり、SQL Server 2019 CU8 を適用することで、SQL Server on Azure VM で AlwaysOn 可用性グループを構築する際に、可用性グループのリスナーで DNN (Dynamic Network Names) Listeners がサポートされるようになりました。

これにより、AlwaysOn 可用性グループにアクセスする際にロードバランサーを使用することなくアクセスができるようになります。
関連情報は次のドキュメントとなります。(投稿を書いている時点では、英語版にのみ情報が公開されています)

• Always On availability group on SQL Server on Azure VMs
• Configure a DNN listener for an availability group
• Feature interoperability with AG and DNN listener

Read the rest of this entry »

Synapse Link for Cosmos DB を SQL Ondemand (Serverless SQL Pool) で操作する場合のメモを。

SQL Ondemand なのか、Serverless SQL Pool なのかがよくわからないので、どちらでもヒットするようにしています (遠い目)

ドキュメントとしては次の内容をベースとしています。

• Azure Synapse Analytics の SQL オンデマンド (プレビュー) のベスト プラクティス
• Azure Synapse Link for Azure Cosmos DB についてよく寄せられる質問

Read the rest of this entry »

Synapse Analytics の Serverless SQL Pool (SQL on-demand) では、BLOB / ADL Gen2 上のファイルに対してクエリを実行することができます。

• Synapse SQL 内で SQL オンデマンド (プレビュー) リソースを使用してストレージ ファイルに対してクエリを実行する
• SQL オンデマンド (プレビュー) のストレージ アカウント アクセスを制御する

同様の内容を実現する機能としては、Azure Data Lake Storage のクエリ アクセラレーション があります。
こちらについては、しばやん先生が Azure Data Lake Storage の Query Acceleration が GA になったので試したら最高だった で機能の解説をされています。

この機能の比較をするために検証していたときに「そういえば、Serverless SQL Pool で、テキストを読むとき文字コードって何にする必要があったっけ？」と思い、軽く検証してみました。

今回は Shift-JIS / UTF8? / UTF16 LE の 3 パターンで検証しています。

使用しているデータは、本ブログのアクセスログを CSV に出力したものです。

シンプルな構成にするのであれば、次のような構成をしておけばいいのではないでしょうか。

• ファイルは UTF8 のエンコードを使用する
• データベースの照合順序は _UTF8 を使用する
  • 日本語環境の SQL Server の照合順序と同様にするのであれば、次の照合順序のいずれかを使用しておけば、最新のUnicode を考慮した文字コード体系になる
    • Japanese_XJIS_100_CI_AS_SC_UTF8
    • Japanese_XJIS_140_CI_AS_UTF8
      • Synapse SQL でのデータベースの照合順序のサポート では、140 系はサポートされていないということになっていますが、本投稿を書いているタイミングでは、設定はできます。(サポート対象なのかは要確認ですが)
  • 基本的な検索であれば、任意の照合順序に「_UTF8」を設定したものであれば、ある程度カバーできるはず
• 検索条件で、文字列リテラルを使用する場合、「N’xxxxx’」の Unicde 変数で検索を行う。

Read the rest of this entry »

インサイトテクノロジーさんの db tech showcase ONLINE 2020 で、次のセッションを担当させていただきます。

本セッションでは、パフォーマンスモニターや、動的管理ビュー (DMV) の情報を使用したベースライン取得の基本的なアプローチについてお話をさせていただく予定です。

セッション資料を作成していて「そういえば Windows Server 2019 でデータコレクションの自動起動が動かない件があったな」ということを思い出したので情報をまとめておこうかと。

基本的には、次の記事を把握しておけば問題ないはずです。

• データ コレクター セットの停止に時間がかかる事象について
• Windows Server 2019: working with Performance Monitor data collector sets

今回は、スクリプトは作成せずに、GUI からの操作でできる範囲で対応していますが、本来は、logman 等を使用したタイマー起動 / 終了と、スクリプトによるファイルの削除を実施したほうが良いかと思います。

Read the rest of this entry »

2020/10 時点で Windows Server 2008 の検証環境を構築(サポートが切れていても検証で環境を構築しないといけないときがあるのです)していた際に気づいた内容のメモを。

久しぶりに古い OS を Windows Server 2019 から触ろうとしたら、いろいろと設定忘れていました。

本投稿では、Windows Server 2008 SP2 インストール直後の環境にたいして、最新の Windows Update を適用している Windows Server 2019 で接続を行っています。

Read the rest of this entry »

SQL Server でパラメーター化クエリ (パラメータークエリ) を使用した場合、「クエリコンパイル時のパラメーター」を意識することがあるかと思います。（パラメーター化クエリだけでなく、ストアドプロシージャも同様ですが)

これは、「パラメーター スニッフィング」という、クエリのコンパイルが発生した際に、コンパイル時に使用されたクエリのパラメーターを傍受し、オプティマイザーがクエリの最適化を行うためです。

次のクエリを実行したタイミングでコンパイルが発生したとします。

sp_executesql 
N'SELECT * FROM LINEITEM WHERE L_ORDERKEY >= @orderkey', 
N'@orderkey int',
@orderkey = 300000000

この場合、パラメーター スニッフィングにより、「@orderkey = 300000000」というパラメーターによって最適化されたクエリとしてコンパイルが行われます。。

今回は上記のクエリのハッシュ値がわかっているため、キャッシュされているクエリの情報を取得してみます。

SELECT 
    qp.query_plan
FROM 
    sys.dm_exec_query_stats AS qs
    OUTER APPLY sys.dm_exec_query_plan(plan_handle) AS qp
WHERE 
    query_hash = 0x3B2744F6B4DC1A74

キャッシュされているクエリの実行プランには、「パラメーター リスト」という情報が含まれています。

実行プランの XML で確認した場合には、次のような情報です。

            <parameterlist>
              <columnreference Column="@orderkey" ParameterDataType="int" ParameterCompiledValue="(300000000)"></columnreference>
            </parameterlist>

この情報から、キャッシュされているパラメーター化クエリの実行プランは、どのようなパラメーターによって、生成されたのかを確認することができます。

Read the rest of this entry »