SQL Server 2022 では Stretch Database の機能が非推奨機能となり、将来のバージョンでは削除されることがアナウンスされました。
SQL Sever 2016 から SQL Server 2019 までで Stretch Database を使用している環境の対応についてですが、本日リリースされた SQL Server 2017 CU31 で代替となる機能が追加されました。
CU31 では次の機能が追加されています。
Archive for the ‘SQL Server’ Category
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 に再接続と関係しているか、把握できていなかったので、軽く調べてみました。
SQL Server 2022 Release Candidate 0 (製品候補版) がリリースされました
本日、SQl Server 2022 Release Candidate (RC: 製品候補版) 0 (16.0.900.6) がリリースされました。
RC は、製品候補版となり、RTM に向けての対応が着々と進められていますね。
追加された機能については Release candidate に記載されており、大きな機能追加はないのですが、いくつかの機能改善が追加されています。
RC 0 の改善点については、次のドキュメントを参照。
SQL Server 2022 CTP 2.1 がリリースされました
本日、SQL Server 2022 CTP (Community Technology Preview) 2.1 がリリースされました。
CTP 2.1 ではいくつかの機能が追加されており、上記のアナウンス並びに、What’s new in SQL Server 2022 (16.x) Preview から CTP 2.1 で実装された機能を確認することができます。
大きな内容としては、次のようなものでしょうか。(CTP 2.1 からクエリストアのデフォルト有効化が実装されていたりもします)
- データ仮想化
- データ仮想化で CETAS (CREATE EXTERNALTABLE AS SELECT) をサポート
- Delta Table フォーマットのサポート
- Azure BLOB ストレージに Ledger ダイジェストの自動アップロードをサポート
- 集計 / T-SQL / ビット操作関数の強化
T-SQL の機能強化については、各関数のドキュメントから確認できますので、それ以外のアップデートで確認しておきたいドキュメントをまとめておきたいと思います。
Twitter で気づいたのですが、Stretch Database は 2022 で非推奨機能になったようです。
Awww, Stretch Database is officially deprecated… ??https://t.co/LQ3DfsWYRz
— Randolph West is not here anymore (@_randolph_west) July 27, 2022
Power BI PPU でデータマートを使用できるようになったので SQL Database の構成を確認してみる
本日、Power BI データマートが東南アジア (シンガポール) でも使用できるようになったようで、シンガポールから東日本にテナントをお引越ししなくてもよかったのではと思う今日この頃ですが、私が使用している Power BI Premium Per User (PPU) の環境でデータマートを触れるようになったので、SQL Database の構成を簡単にではありますが確認してみました。（Power BI Embedded でも試すことができ、PPU も Embedded も同じ構成となっているようでした)
考慮事項と制限事項 で東アジアが制限から外れたので、日本の Power BI ユーザーも広範囲で試すことができそうですね。
Power BI データマートの説明については、データマートの概要 のドキュメントツリーを確認していただければと思います。
SSMS インストール時の再起動要求はどの辺の情報を見ているのだろう
SSMS のアップグレードを実行しようとして、インストーラーを起動すると次のような、再起動要求の画面が表示されることがあります。
検証環境に Windows Update を適用した後に SSMS も一緒にアップグレードしておくかと思って、最新のインストーラーをダウンロードしてセットアップすると、これに遭遇することが多いのですが、どの辺の情報を見て判断しているのかが気になったので軽く見てみました。
確認した範囲では、「HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired」のレジストリキーが存在していると、上記の再起動要求の画面が表示されるようでした。
Windows の再起動要求の判断は How to Check for a Pending Reboot in the Registry (Windows) で記載されているようなレジストリを見ているケースもあり、今回確認できたキー以外で判断されるかもしれませんが、Windows Update 直後の環境で上記の画面が表示されていたので、何となくどの辺の情報を見ているのか確認してみました。