自分のメモとなるのですが SQL Server で Non-yielding scheduler のエラーが発生した場合に必要となる情報をまとめておきたいと思います。
Archive for the ‘SQL Server’ Category
Ignite 2022 で発表された SQL Server ベースのアップデート
Ignite 2022 が開催されています。更新内容については、Book of News から確認することができます。
SQL Server ベースの環境に関連するアップデートとしてどのようなものがあったかまとめておきたいと思います。
Data Platform 関連のキーノートセッションは次のようなものがあるようです。
SQL Server 2022 New Features: Intel QAT を使用したバックアップの高速化
SQL Server 2022 RC 1 時点の情報となり、今後の Preview / 一般提供開始時には変更されている可能性もあります。
SQL Server 2022 の新機能として、Intel QAT (Quick Assist Technology) を使用した、バックアップの高速化とバックアップの負荷をハードウェアにオフロードするという機能があります。
Intel QAT を使用する場合、Intel® QuickAssist Adapter Family for Servers のようなハードウェアを使用しなくてはいけないのかと思っていたのですが、この機能はソフトウェアモードでも使用することができ、ハードウェア圧縮が使用できない場合でもソフトウェアで処理ができるようになっていました。
この機能を使用した場合の処理特性についてまとめておきたいと思います。
2022年9月下旬の Azure SQL Database Update と SQL Server Update
2022年9月下旬の Azure SQL Database Update の情報がアナウンスされたのでまとめておこうと思います。
- Azure SQL—General availability updates for late September 2022
- Azure SQL—Public preview updates for late September 2022
- Azure Synapse Analytics September Update 2022
アップデートには含まれていないが、当月更新されたものもなりますので、それらも追記しています。
SQL Server の Stretch Database の代替機能が SQL Server 2017 に追加されました
SQL Server 2022 では Stretch Database の機能が非推奨機能となり、将来のバージョンでは削除されることがアナウンスされました。
SQL Sever 2016 から SQL Server 2019 までで Stretch Database を使用している環境の対応についてですが、本日リリースされた SQL Server 2017 CU31 で代替となる機能が追加されました。
CU31 では次の機能が追加されています。
SSDT for VS2017 を Visual Studio なしでインストールする
最新の SSDT については、Visual Studio 2022 / 2019 の Extension として提供がされており、Visual Studio インストール後に Market Place から拡張機能を追加することで SSRS / SSAS / SSIS 向けのプロジェクトを作成することができるようになります。
SSDT for Visual Studio 2017 までは、Visual Studio をインストールしないで導入できるインストーラーが提供されており、次のドキュメント内の情報を参考にすると「SSDT-Setup-JPN.exe」を入手することができます。
この EXE を単純に実行すると、「セットアップに失敗しました ファンクションが間違っています。(0x80070001)」のエラーとなります。
SQL Server 2022 RC0 on Linux で Azure AD 認証が実行できない場合に確認する設定
先日、SQL Server 2022 Release Candidate 0 is now available on Linux のアナウンスがあり、SQL Server on Linux についても、2022 RC0 の提供が開始されました。
RC0 の Linux 版で使用できる機能として、Azure Active Directory authentication (AAD 認証) があるのですが、現時点ではポータルから設定しただけでは動作しなさそうだったので情報を残しておきたいと思います。
今夏使用している環境は次の環境となり、事象については報告してあるので、今後は追加の設定を実施しなくても動作するようになっているかもしれません。
- OS: Ubuntu 20.04
- SQL Server: SQL Server 2022 RC0
- Azure Arc Agent: 1.21.02043.328
SQL Server Standard Edition のメモリリソースの制限を Express Edition で確認する
SQL Server は SQL Server 2016 SP1 からエディション間の機能差が緩和され、従来までは Enterprise Edition でしか使用できない機能の一部が、空以外のエディションでも利用できるようになりました。
また、SQL Server 2014 / SQL Server 2016 では、Standard Edition で使用可能なハードウェアリソースについても上限が緩和されました。
- SQL Server 2014
- メモリサイズ: 64 GB -> 128 GB
- SQL Server 2016
- CPU コア数: 4 ソケットまたは 16 コアのいずれか小さいほう -> 4 ソケットまたは 24 コアのいずれか小さいほう
- 以降、投稿を書いている時点で GA している最新バージョンの SQL Server 2019 まで同一のリソース上限です
SQL Server 2012 では、次のようになっていました。
- CPU コア数: 4 ソケットまたは 16 コアのいずれか小さいほう
- メモリサイズ: 64 GB
最新の SQL Server にすると、ハードウェアリソースの上限もだいぶ変わりますね。
2012 ～ 2016 までのサポート機能は次の情報から確認することができます。
- SQL Server 2012 の各エディションがサポートする機能
- Features Supported by the Editions of SQL Server 2014
- SQL Server 2016 の各エディションとサポートされている機能
SQL Server 2012 から最新の SQL Server に移行する場合、Standard Edition でも使用可能なリソース / 機能が増えているため、現行は Enterprise を使用していても移行後は Standard を使用するという選択肢をとることもあるのではないでしょうか。
Standard を使用する場合、よく聞かれる質問が「128 GB 以上のメモリを搭載していて意味があるか？」というものです。
SQL Server が使用するメモリと OS / SQL Server 以外のアプリケーションが使用するメモリを考慮すると、128 GB 以上のメモリを踏査することの意義は十分にあるのですが、実際に SQL Server Standard Edition でどの程度メモリが使用できるのかの実際の値をとることについては、128 GB を超えるメモリを搭載している環境の準備が難しいので実施してはいませんでした。
メモリリソースの制限ですが、Express Edition でもサイズは異なりますが、上限が設定されています。
- メモリサイズ: 1,410 MB
Standard Edition の上限を超えるメモリの環境を用意できなくても Express Edition の 1.4 GB のメモリ制限がどのように動作するかを確認することで、Standard Edition のメモリ制限がどのように動作するのか把握することができます。
詳細な情報については、次の技術情報を確認してください。
現在の SQL Server のドキュメンでは最大メモリは「インスタンスごとのバッファプールの最大メモリ」という記載になっており、過去のバージョンの SQL Server では、異なる記載になっていますが、これは、
The memory consumed by caches outside buffer pool is not restricted by above memory limits and can grow up to limits defined by "max server memory". This is not specific to SQL Server 2016 SP1 and is also applicable to earlier releases of SQL Server as well.
となっており、基本的な考え方はそれより前のバージョンの SQL Server も同様となります。(表現方法が変わっただけで動作は同一)
Microsoft.Data.SqlClient 4.0 以降で SQL Server に接続する際の暗号化オプション
先日、Microsoft.Data.SqlClient 5.0 がリリースされました。
新機能については、次の情報からも確認することができます。
4.0 の破壊的変更に含まれるのですが、4.0 以降は接続文字列の「Encrypt」が「true」に設定されることがデフォルトとなりました。
これにより、オンプレミスの SQL Server のような環境では、4.0 より前と同一の接続文字列で接続を行うと「 信頼されていない機関によって証明書チェーンが発行されました。」のエラーが発生する可能性があります。(Azure の PaaS については、信頼されている証明書による接続になっているので、PaaS を使っている場合は、本投稿は意識しないでもよかったはずです)
今回は、Windows PowerShell に Microsoft.Data.SqlClient 5.0 を使用できるようにして、この暗号化接続部分について動作を確認してみました。
Windows PowerShell で Microsoft.Data.SqlClient 5.0 を使えるようにするのは面倒ですが、動かしてみたい方は Microsoft.Data.SqlClient 5.0.0.ps1 を実行してみてください。
.NET Data Provider for SQL Server の ConnectRetryCount をサポートする SQL Server のバージョン
.NET Framework 4.6.1 is now available! でアナウンスされた内容となりますが、現在の System.Data.SqlClient や Microsoft.Data.SqlClient には、ConnectRetryCount というオプションが追加されており、接続文字列で再接続の回数を調整することができるようになっています。
サポートされるバージョンについては、
等に記載されているのですが、SQL Server 2014 以降または、Azure の PaaS の SQL Server ベースの環境でサポートされる機能となります。
リトライについては、ライブラリ側で実装されていると思うのですが、SQL Server のバージョンがどのように ConnectRetryCount に再接続と関係しているか、把握できていなかったので、軽く調べてみました。