SE の雑記

Azure では、Marketplace から SQL Server インストール済みの VM イメージが公開されており、Azure VM で SQL Server を使用する場合は、このイメージで展開して PAYG で利用するのが一般的かと思います。

イメージは英語版を使用して構築されているため、日本語化する場合には、当ブログで書いた SQL Server on Azure VM (インストール済みイメージ) の日本語化 (2021/1 版) の方法や、SQL Server Support Blog で公開されている次の記事の対応を行う必要があります。

• Azure 仮想マシン上に作成した SQL Server の日本語化手順（Windows OS 版 SQL Server 2019 / 2022 対応手順）

基本的な作業としては、次の流れとなるのではないでしょうか。

1. OS に日本語の言語パックをインストールし、各種言語設定を日本向けに設定
2. 導入済みの英語版 SQL Server / SSMS をアンインストール
3. SQL Server の日本語版評価版メディアをダウンロードして「C:\SQLServerFull」内のプロダクトキーでインストール
4. 日本語版の SSMS をインストール
5. SQL Server IaaS Agent 拡張機能を Remove-AzSqlVM 等で登録解除
6. New-AzSqlVM で SQL Server IaaS Agent 拡張機能を登録

基本的な作業の流れとしてはこのようになりますが、この手順だけでは、VM の展開時に指定した SQL Server 構成の設定はクリアされた状態となってしまっています。

展開時に指定した内容と同等の設定で IaaS Agent を導入するためには、New-AzSqlVM で様々なオプションを指定して再導入をする必要があるのですが、オプションを一つ一つ設定するのは手間がかかるため、今回はその設定を Bicep で実施してしまおうというのが今回の趣旨となります。

Read the rest of this entry »

JDBC で接続をする際のコネクションプールで使用するライブラリとして HikariCP があります。

HikariCP を使用して SQL Server に接続をする際の挙動について、いくつか調査する必要があったのでその時に確認した内容を残しておきたいと思います。

Read the rest of this entry »

Build 2024 が開催されています。

キーノートについては次の情報から確認できます。

• Build 2024 Book of News
• Microsoft May 2024 events
• Full Keynote: Satya Nadella at Microsoft Build 2024

SQL Server についてはアップデートはなかったのですが、Azure SQL Database についてはアップデートがアナウンスされていますのでまとめておきたいと思います。

Read the rest of this entry »

SQL Server ベースの環境に対しての CI/CD で活用できるツールとして SqlPackage があります。

Visual Studio Code の Dev Container (開発コンテナー) 上に SqlPackage の実行環境を作成しようかなと思って試してみました。

SqlPackage に問題がある場合は DacFx のリポジトリ から Issue で報告ができます。

Read the rest of this entry »

前回の Update: SQL Server / SQL Database Update (2024/01～2024/03/03)

前回の投稿以降の Update をまとめておきたいと思います。

• Azure Updates
  • Preview
    • Public Preview: Azure SQL updates for mid-March 2024
    • Public preview: Database watcher for Azure SQL
    • Public Preview: Azure SQL Database Mirroring in Microsoft Fabric
    • Public Preview: Azure SQL updates for late-March 2024
  • GA
    • General availability: Azure SQL updates for late-March 2024
    • General availability: Azure SQL updates for mid-April 2024
• Azure SQL Blog
  • Azure SQL Blog
  • Azure SQL Devs’ Corner
• SQL Server Blog
  • SQL Server Blog
• SQL Server
  • SQL Serverの最新の更新プログラムとバージョン履歴
• SQL Database
  • Azure SQL Database の新機能
• Azure Arc
  • リリース ノート ? Azure Arc 対応データ サービス
  • リリース ノート ? Azure Arc によって有効化された SQL Server

Read the rest of this entry »

SQL Server 2019 以降のクエリストアでは、カスタムキャプチャの設定を行うことができるようになりました。これにより、クエリのキャプチャモードを「ALL」「AUTO」以外に「CUSTOM」で設定することができるようになります。

「CUSTOM」を使用した場合、キャプチャされるクエリの条件を従来より柔軟に設定することができます。

「CUSTOM」を設定した場合の設定観点について少しふれておきたいと思います。

クエリストアの活用については次のドキュメントが参考になります。

• クエリ ストアを管理するためのベスト プラクティス
• クエリ ストアを使用してパフォーマンスを監視する

Read the rest of this entry »

SSMS は接続情報として入力した内容が保存されており、接続を行おうとした場合に再利用することができます。

自サーバー上の SQL Server にのみ接続をしているのであれば、この情報が増えるということはあまりないですが、クライアントからいくつかのサーバーに接続している場合にはこの情報が増えていき、今は接続が不要になったサーバーの情報も残った状態となっていることがあります。

接続の情報は SSMS の構成ファイルである 「UserSettings.xml」に記録が行われており、この XML から接続情報を削除することで、表示が行われなくなります。

ファイルは「%USERPROFILE%\AppData\Roaming\Microsoft\SQL Server Management Studio」に SSMS のバージョンごと (18.0 / 19.0 / 20.0 等のディレクトリ) に保存されています。

不要となった情報は

1. SSMS を起動していない状態にする
• SSMS を起動していると、SSMS を閉じた場合に修正した情報が初期化されてしまう可能性があるため
2. UserSettings.xml を直接編集し、不要となったサーバーの接続情報を削除

することでクリアすることができます。

XML の階層としては「SqlStudio > SSMS > ConnectionOptions > ServerTyes > Element」配下に保存されています。

UserSettings.xml は情報量が多い XML ですので、メモ帳で修正するよりは、Visual Studio Code で XML を編集して、不要となったサーバー情報の Element をブロック単位で削除したほうが効率が良いかと。

SQL Server では フィルター選択されたインデックス (フィルター化インデックス) というインデックスを作成することができます。

このインデックスはインデックスの作成を行う際に、以下のクエリのように、インデックス作成時に WHERE 句を指定することで、特定の範囲のデータのみが含まれたインデックスを作成することができます。

CREATE NONCLUSTERED INDEX [NCIX_accesslog2_01] ON [frontdoor].[accesslog2]
(
	[time] ASC
)
WHERE ([time]>='2020-01-01' AND [time]<'2021-01-01')

フィルター選択されたインデックスは、特定のデータ範囲のみがインデックスに含まれますので次のようなメリットがあります。

• インデックスで使用されるストレージサイズの削減
• フィルター外のデータを追加 / 変更する場合のインデックス更新コストの削減
• 該当データ範囲で Index Scan が発生した場合の、Scan コストの削減

特定のデータ範囲の検索向けに作成するインデックスとして便利な機能となるのですが、作成したインデックスが使用されるかどうかについては考慮が必要な点がありますので、本投稿で触れておきたいと思います。

フィルター選択されたインデックスの詳細な情報については次のドキュメントが参考となります。

• フィルター選択されたインデックス
• フィルター選択されたインデックスの作成
• フィルター選択されたインデックスのデザイン ガイドライン

Read the rest of this entry »

ストアドプロシージャを明示的にリコンパイルさせる方法として ストアド プロシージャの再コンパイル に記載されている sp_recompile を使用するという方法があります。

ストアドプロシージャはコンパイル時に指定されたパラメーターによって実行プランが生成されるため、コンパイル時に指定されたパラメーターが大多数の実行に対してマイノリティな設定の場合、頻繁に実行するクエリに対しては効率の悪い実行プランが生成されることがあります。

このような場合は、ストアドプロシージャをリコンパイルさせることで新しい実行プランを生成することがあります。

このリコンパイルを同時実行性の低下をできるだけ抑えて実行するにはどのような方法が考えられるでしょうか。

Read the rest of this entry »

SSMS からクエリを実行した場合と、アプリケーションからクエリを実行した場合の違いとして、Qiita で書いた アプリから動かすと遅いが SSMS から動かすと速いのは ARITHABORT の違いという情報の動作を理解する というような動作があります。

SET オプションが異なっていると、異なる実行プランとしてキャッシュが行われるため、SSMS とアプリケーションで同一のオプションを使用するというのが記載した内容となります。

この投稿では、「SET ARITHABORT OFF」を SSMS から実行し、アプリケーションと同一の SET オプションの状態とすることで SSMS とアプリケーションで同一のプランキャッシュを使用していました。

クエリの多重実行と SSMS から実行したクエリで同一のプランキャッシュを使用したかったので「SQLQueryStress」と「SET ARITHABORT OFF に設定した SSMS」でクエリを実行したところ、同一のプランキャッシュが使用されないという事象が発生しました。

そこで、同一の SET オプション以外にどのような要因が同一のプランキャッシュが使用されないことにつながっているのかを確認してみました。

Read the rest of this entry »