SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
SQL Server のクライアント/サーバー間のデータ通信に使用される文字コードについて に書いた内容と近いものとなりますが、自分の中で情報を整理しておきたいと思ったので投稿を遺しておきたいと思います。
SQL Server 2019 で UTF-8 のサポート が追加されており、SQL Server が UTF-8 をどのように取り扱うかについての確認となります。
SQL Server の文字の取り扱いについては、Windows / SQL Server の両観点から情報を確認する必要があるかと思いますので、次の情報も参照するとよいかと思います。
先日公開された 4 KB を超えるシステム ディスク セクター サイズに関連するエラーのトラブルシューティング で解説が行われていますが、Windows 11 / Windows Server 2022 に対して SQL Server をインストールしようとするとエラーが発生するという事象が報告されています。
SQL ServerでのWindows で Windows 11 / Windows Server 2022 でサポートされる SQL Server については記載されていますが、各 OS がサポートする SQL Server をインストールしようとした場合に、サポートされるバージョンの組み合わせでも環境によっては、インストール時にエラーが発生するケースがあるというのが、現在発生している問題となります。
これについては Answers の SQL Server 2019 – Windows 11 でも報告が行われており、どのような事象が発生するかについては、上述の情報だけでなく、こちらのフォーラムの投稿も参考になるのではないでしょうか。
私は気づいておらず、教えていただいた情報となるのですが、日本語のフォーラムでも SQL Server 2012 インストール失敗 FMVF77F3B で話題になっていたようですね。
エラーの内容としては、インストール時に次のような画面のエラーが発生し、SQL Server のバイナリの配置はある程度完了しているのですが、SQL Server のサービスが起動しないという事象が発生します。
のエラーが発生した場合、SQL Server のインストールは完全には完了しておらず、この状態でエラーを回避するように設定しても動作しないため、一度アンインストールをする必要があります
SQL Server データベース エンジン サービス インスタンス機能 のインストール エラー
データベース エンジンの復旧ハンドルの待機に失敗しました。考えられる原因については、SQL Server エラー ログを参照してください。
この際、OS のイベントログのアプリケーションには、次のようなエラーが出力されているようです。
同期 IO に戻す必要のある不均衡なログ IO が 256 個あります。現在の IO はファイル C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\master.mdf にあります。
sqlservr (776,P,98) SoftwareUsageMetrics-Api: ファイル システムは、C:\Windows\system32\LogFiles\Sum\ のログ ファイルに、サポート対象外のセクターサイズ 32768 があるため、代わりに 4096 のセクター サイズを使用することを報告しました。これにより、トランザクションの持続性が失われる可能性があります。
SQL Server の ERRORLOG には、「同期 IO に戻す～」のメッセージの英語表記の情報が出力されています。
There have been 256 misaligned log IOs which required falling back to synchronous IO. The current IO is on file C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\master.mdf.
冒頭で紹介したドキュメントに記載されていますが、SQL Server がサポートするのは、512 バイト / 4 KB のネイティブセクターサイズとなっており、次の技術情報で詳細が記載されています。
本エラーは、SQL Server がサポートするネイティブセクターのサイズ以外が指定されたドライブに対して、SQL Server をインストールをしようとしたためにエラーが発生しているというのが根本原因となるようです。
SQL Server ベースの環境で使用するストレージの性能検証をする際ですが、
を組み合わせて計測を行うのが、一般的な方法となるのではないでしょうか。
この方法の中で、DISKSPD を使用して検証を行う場合には、I/O サイズ (ブロックサイズ) をどのように設定をすれば、SQL Server の I/O として妥当な検証となるかを考慮する必要があります。
SQL Server で発生する各種操作の基本的な I/O がまとめれている資料は様々なものがあるのですが、その中の一つとして、What is SQL Server’s IO Block Size? があります。
この記事の中では、次のような記載があり、SQL Server の I/O のブロックサイズについて調査すると同様の情報を探すことができます。
DISKSPD で性能検証を実施する際には、これらの I/O サイズを参考にして負荷をかけることで、SQL Server の I/O をエミュレートしてテストを実施することになります。
Azure SQL Managed Instance (MI) で試したいことがあったのでデプロイして触っていたところ、MI でプライベートエンドポイント接続が設定できるようになっていました。
インストールタイプの SQL Server のトランザクション分離レベルのデフォルトは SNAPSHOT が使用されない、READ COMMITTED が使用されており、データの検索を行った際にはロックが取得されるというのが有名な話だと思います。
N_NATIONKEY が主キーとなっているとき、次のようなクエリを実行した場合、どのようなロックがとられるでしょうか？
SELECT * FROM NATION WHERE N_NATIONKEY = '0'
READ COMMITTED が使用されているので「主キーに対しての検索なので主キーまたは検索対象のレコードに対して共有ロックが取得される」と考えることがあるのではないでしょうか？
実際には、「取得されるロックは状態によって変わるため、主キーによる検索でも、共有ロックが取得されないケースがある」というのが正解となります。
本投稿ではこの動作についてまとめてみたいと思います
