SQL Server 2022 では Stretch Database の機能が非推奨機能となり、将来のバージョンでは削除されることがアナウンスされました。
SQL Sever 2016 から SQL Server 2019 までで Stretch Database を使用している環境の対応についてですが、本日リリースされた SQL Server 2017 CU31 で代替となる機能が追加されました。
CU31 では次の機能が追加されています。
SQL Server 2016 SP3 未適用の環境で管理対象バックアップを設定する際の注意点
SQL Server 2016 ではインスタンス内のデータベースのバックアップに管理対象バックアップ (マネージドバックアップ) という機能を使用することができます。
この機能は、SQL Server on Azure VM の IaaS Agent 拡張機能の自動バックアップでも使用されているものとなるのですが、SQL Server 2016 SP3 を未適用の環境で設定を行おうとしたところ次のようなエラーが発生しました。
メッセージ 45207、レベル 17、状態 2、プロシージャ sp_add_task_command、行 102 [バッチ開始行 18]
The operation failed because of an internal error. 値を Null にすることはできません。
パラメーター名:sasToken Command: smartbackup configure_backup_basic 1 xxxxxxxxxxxxx== 30 Please retry later.
場所 Microsoft.WindowsAzure.Storage.Auth.StorageCredentials..ctor(String sasToken)
場所 Microsoft.SqlServer.SmartAdmin.SmartBackupAgent.FileService.VerifyContainerURL(String containerURL, SqlConnection conn)
場所 Microsoft.SqlServer.SmartAdmin.SmartBackupAgent.SmartBackup.CheckAndSetDefaultSettings(SmartBackupConfigParameters config, LogBaseService jobLogger, SqlConnection conn)
場所 Microsoft.SqlServer.SmartAdmin.SmartBackupAgent.SmartBackup.ConfigureDbOrInstance(SmartBackupConfigParameters config, LogBaseService jobLogger, SqlConnection conn)
場所 Microsoft.SqlServer.SmartAdmin.SmartBackupAgent.SmartBackup.ExternalJobHelper(String command, LogBaseService jobLogger)
場所 Microsoft.SqlServer.SmartAdmin.SmartBackupAgent.SmartBackup.ExternalJob(String command, LogBaseService jobLogger)
同様の事象を確認すると、類似の問題がいくつか確認できるのですが、自分が遭遇していたものの明確な内容が、パッと見た限りでは見つからなかったので、本事象についてなぜ発生したのかを残しておきたいと思います。
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
Azure AD 証明書ベースの認証 (CBA) の CDP を構成する
先日投稿した、Azure AD の証明書ベースの認証 (CBA) をスマートカードで検証する環境を準備してみる では 証明書失効リストの配布ポイント (CDP) の構成は行っていなかったのですが、CDP を構成してみたので情報を残しておきたいと思います。
Azure AD の証明書ベースの認証 (CBA) をスマートカードで検証する環境を準備してみる
投稿を書いている時点ではプレビュー機能となりますが、Azure AD では証明書ベースの認証 (CBA) を使用するkとができるようになりました。
CBA を使用したログインの基本的な流れについては Azure AD 証明書ベース認証を試してみた がとても参考になり、基本的な作業の流れはこの記事を確認しておけば問題ないのですが、物理デバイスと組み合わせた場合にはどのようになるのかを検証する必要があり、検証環境を作ってみました。
今回使用しているベースの環境は次のようになります。
- 使用している Azure Active Directory
- Microsoft 365 開発者プログラム で作成した Azure AD テナント
- AAD Premium P2 が使用でき、普段使用している AAD を操作しなくて済むので検証に便利
- Azure AD Connect をインストールし、AD と AAD を同期
- AD CS の役割も合わせて導入
- 証明機関の証明書を AAD の CBA の証明書として設定
- T440s が手元にあったので Windows 10 Pro をクリーンインストールして使用
- CPU / TPM が古くて、残念ながら Windows 11 がインストールできない…
Azure AD 証明書ベース認証を試してみた で解説されている証明書を使用した認証については、AD CS を展開して「ユーザー」の証明書テンプレートを使用してドメインユーザーで証明書を作成することで、CBA の認証をすることができますので、その環境を構築してから検証を実施しています。
今回は証明書の失効については検証していないので、証明書失効リスト (CRL) の配布ポイント (CDP) については構築せずに検証しています。(CDP については、Azure BLOB ストレージを匿名アクセス許可でファイルを公開することでもできるのかなと思いつつ検証していません)
2022年8月下旬の Azure SQL Database Update と SQL Server Update
2022 年 8 月下旬の Azure SQL Database Update がアナウンスされ、それ以外にもいくつかのアップデートが発表されましたのでまとめておきたいと思います。
Azure SQL Database に関連するアナウンスは以下を参照してください。
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 を実行してみてください。
Windows Server BMR バックアップでリストアする際のメモ＋α
UEFI 環境の Windows Server バックアップのリストアについて調べることがあったので、その際のメモを残しておきたいと思います。