SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

SQL Server / SQL Database アーキテクチャ ドキュメント

without comments

Written by Masayuki.Ozawa

1月 13th, 2020 at 11:36 pm

Posted in SQL Server

Tagged with

SQL Server Management Studio 18.7 から Azure Data Studio が同時にインストールされるようになりました

without comments

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

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

image

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

Read the rest of this entry »

Written by Masayuki.Ozawa

10月 21st, 2020 at 9:11 pm

Posted in SQL Server

Tagged with

SQL Server on Azure VM の AlwaysOn 可用性グループで DNN がサポートされました

without comments

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

Read the rest of this entry »

Written by Masayuki.Ozawa

10月 20th, 2020 at 9:34 pm

Synapse Link for Cosmos DB を SQL Ondemand で操作する場合のメモ

without comments

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

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

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

Read the rest of this entry »

Written by Masayuki.Ozawa

10月 20th, 2020 at 8:51 am

Synapse Analytics の Serverless SQL Pool (SQL Ondemand) でテキストを参照する際の文字コードの設定 (おまけで Synapse Link for Cosmos DB)

without comments

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

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

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

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

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

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

  • ファイルは UTF8 のエンコードを使用する
  • データベースの照合順序は _UTF8 を使用する
  • 日本語環境の SQL Server の照合順序と同様にするのであれば、次の照合順序のいずれかを使用しておけば、最新のUnicode を考慮した文字コード体系になる
  • Japanese_XJIS_100_CI_AS_SC_UTF8
  • Japanese_XJIS_140_CI_AS_UTF8
  • 基本的な検索であれば、任意の照合順序に「_UTF8」を設定したものであれば、ある程度カバーできるはず
  • 検索条件で、文字列リテラルを使用する場合、「N’xxxxx’」の Unicde 変数で検索を行う。
  • Read the rest of this entry »

    Written by Masayuki.Ozawa

    10月 18th, 2020 at 12:20 am

    Posted in Synapse Analytics

    Tagged with

    Windows Server 2019 でパフォーマンスモニターのログの世代管理を実施

    without comments

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

    image

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

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

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

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

    Read the rest of this entry »

    Written by Masayuki.Ozawa

    10月 14th, 2020 at 5:04 pm

    Windows Server 2008 の検証環境作成時についてのメモ

    without comments

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

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

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

    Read the rest of this entry »

    Written by Masayuki.Ozawa

    10月 12th, 2020 at 8:37 pm

    Posted in Windows Server

    Tagged with

    「実行中のクエリ」で実行時のパラメーターを取得する

    without comments

    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
    
    

     

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

    image

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

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

     

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

    Read the rest of this entry »

    Written by Masayuki.Ozawa

    10月 6th, 2020 at 11:06 pm