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 が使用されているので「主キーに対しての検索なので主キーまたは検索対象のレコードに対して共有ロックが取得される」と考えることがあるのではないでしょうか？
実際には、「取得されるロックは状態によって変わるため、主キーによる検索でも、共有ロックが取得されないケースがある」というのが正解となります。
本投稿ではこの動作についてまとめてみたいと思います
検証用で使用している Intel NUC Gen11 (NUC11TNHv70L) の CPU は、Core i7-1185G7 が搭載されており、VT-x が使用できますので、Nested Hyper-V (入れ子になった仮想化) を使用することができる CPU となっています。
Nested Hyper-V の有効化については、入れ子になった仮想化による仮想マシンでの Hyper-V の実行 で公開されており、今回使用している NUC のような物理ハードウェア上にインストールした仮想マシンで実行するのであれば、
ことで、Nested Hyper-V を使用することができます。
しかし、今回使用している Gen 11 の NUC では、上記の対応を行っても Nested Hyper-V を有効化することができませんでした。
Twitter でつぶやいたところ次のようなアドバイスをいただき、教えていただいた方法を使用することで Nested Hyper-V を有効化することができました。
こちらのコマンドではどうでしょうか？
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V,RSAT-Hyper-V-Tools-Feature,Microsoft-Hyper-V-Management-PowerShell
— いまにゅー (@imanyu) December 17, 2021
今後も何回か同じ事象でハマりそうなので、対応方法を残しておきたいと思います。
Azure Purview では、「ネットワーク」の設定に「パブリックネットワークアクセスを拒否 (Deny Public Network Access)」という設定があります。
デフォルトでは「許可」となっており、初期状態であれば、Purview へのアクセス / Purview からのデータ収集 (インジェスト) を阻害する要因はないのですが、この設定を「拒否」にすると、様々なネットワークアクセスに影響が出てきます。
本投稿では、パブリックネットワークアクセスを「拒否」にした場合の挙動についてまとめておきたいと思います。
SQL Server のアップグレード / マイグレーションを実施する際には、SQL Server の互換性を考慮する必要があります。
SQL Server の互換性についてのドキュメントについては次のような情報があります。
SQL Server のドキュメントは 2016 以降とそれより前のバージョンでドキュメントが分かれており、バージョンによって記載されている互換性レベルのバージョンが異なっているため、いくつかのバージョンのドキュメントを組み合わせる必要があります。(SQL Server 2019 のドキュメントには、SQL Server 2016 以降の情報が含まれています)
現時点で非推奨とさている機能を使用しているかについては、パフォーマンスモニターのオブジェクトとしても情報が提供されており、次のカウンターの情報から使用状況を把握することもできるようになっています。
様々な情報が公開されていますが、「自分が使用している環境でどのような非互換となる情報が該当するか」を一つ一つチェックして影響度を把握することは工数を積んで人海戦術で対応をしようとしても、抜けなく各項目の対応状況を網羅することは現実的には難しいのではないでしょうか？
アップグレード / マイグレーションによる影響を確認するためのツールとして、SQL Server では、Data Migration Assistant (DMA) というツールが提供されています。このツールは SQL Server Upgrade Advisor の後継となり、現在の SQL Server 環境のアップグレード / マイグレーションについては、DMA が使用されます。
このツールをアップグレード対象の SQL Server に対して実行することで、環境を変更することの影響度を評価 (アセスメント) することができ、上述した各種ドキュメントで記載されている内容に対して、どの項目が該当する可能性があるかをツールの実行で機械的に判断することができ、環境の移行に伴う問題の評価を容易に実施することができます。
バージョンの変更 / 互換性レベルの変更についての影響度を評価することができ、新しい環境の SQL Server を使用する際の問題の把握 / 設定の変更の影響度を確認するためには、DMA の利用が推奨されています。
本投稿では、DMA を使用した評価の応用方法についてまとめたいと思います。
Azure Automation の Runbook を任意の環境上で動作させる方法として、Hybrid Runbook Worker があります。
Hybrid Runbook Worker を使用することで、任意の環境上で Automation の Runbook を実行することができるようになりますので、オンプレミスの環境や Azure VM 上で Runbook を実行するということが可能となります。
Hybrid Runbook Worker の導入方法としては、エージェントベースワーカー (v1) と拡張機能ベースワーカー (v2) の 2 種類があります。
エージェントベースについては、Log Analytics ワークスペースへの接続が必要でした。
拡張機能ベースについては、Log Analytics ワークスペースに接続はする必要はなく、オンプレミスの環境であれば、Azure Arc Enabled Server の拡張機能としてインストールをすることができます。(Azure VM の場合は、Arc ではなく、Azure VM エージェントの拡張機能としてインストールできます)
Azure Arc が導入されている環境を Hybrid Runbook Worker でしようとした場合、現時点ではエラーとなるケースがあるようです。
原因都回避策については、次の Q＆A で解説が行われており、現時点では既知の問題となるようです。
追記
2022/1/25 時点では、問題が解決され、Automation アカウントのマネージド ID が有効な状態でも、Runbook が実行できるようになりました。
