イメージのランダム化を強制する(必須ASLR) に「既定でオンにする」を設定した場合、Express Edition の日本語版のインストーラの起動に失敗します
こんにちは。日本マイクロソフト SQL Server サポートチームです。 事象： イメージのランダム化を強制する(必須ASLR) に「既定でオンにする」を設定した場合、SQL Server 2016 ならびにSQL Server 2019 のExpress Edition の日本語版のインストーラ(SQLEXPR_x64_JPN.exe) の起動に失敗します。 なお、イメージのランダム化を強制する(必須ASLR) の規定値は「既定でオフにする」であり、既定値では発生しません。 また、SQL Server 2014、SQL Server 2017、SQL Server 2022 のExpress Edition の日本語版のインストーラー(SQLEXPR_x64_JPN.exe) では発生しません。 ※ 公開時点 イメージのランダム化を強制する(必須ASLR)の設定手順は以下となります。 スタートメニューより[設定] -> [更新とセキュリティ] -> [Windows セキュリティ] -> [アプリとブラウザーの制御] -> [Exploit Protection の設定] -> [システム設定] -> [イメージのランダム化を強制する (必須ASLR)] 図．Windows セキュリティ画面(ご参考) 原因： SQL Server のセットアップは、イメージのランダム化を強制する(必須ASLR) を想定しておらず、SQL Server 2016 ならびにSQL Server 2019 のExpress Edition の日本語版のインストーラ(SQLEXPR_x64_JPN.exe) では、対応が行われていません。 イメージのランダム化を強制する(必須ASLR) に「既定でオンにする」を設定した環境で、インストーラ(SQLEXPR_x64_JPN.exe) の起動に失敗する以外の問題はありません。 回避策： 恐れ入りますが、SQL Server 2016 ならびにSQL Server 2019 のExpress Edition の日本語版のインストーラ(SQLEXPR_x64_JPN.exe) を変更し、再リリースする予定はありません。 そのため、イメージのランダム化を強制する(必須ASLR) に「既定でオンにする」を設定している環境では、次のように一時的に「既定でオフにする」に変更して展開し、SQL Server をインストールします。 1) イメージのランダム化を強制する(必須ASLR)を、「既定でオフにする」に変更します。 2) SQL Server 2016 またはSQL Server 2019 のExpress Edition の日本語版のインストーラー(SQLEXPR_x64_JPN.exe) を起動してファイル群を展開します。 3) イメージのランダム化を強制する(必須ASLR)を、「既定でオンにする」に変更します。 4) SQL Server のインストールを進めます。 なお、SQL Server Express を再配布されている場合、現時点でパッケージを展開して再配布することは、モジュールの変更とはみなされないことを確認しています。
SQL Server 2022 分散型可用性グループにおける同期失敗
こんにちは。SQL Server サポート チームです。 今回は、分散型可用性グループにおける同期が突然失敗する事象についてご紹介します。 事象 SQL Server 2022 で分散型可用性グループを構成し FILESTREAM を使用している環境において、正常に稼働していた分散型可用性グループが突如同期に失敗し、同期の状態が NOT_HEALTHY になります。 <事象発生構成> ・SQL Server 2022 ・分散型可用性グループ ・FILESTREAM 原因 前提として、FILESTREAM の機能はログの順序性が重要になっています。 SQL Server 2022 より、パフォーマンス向上を目的に分散型可用性グループ間で、下記の弊社公開情報に記載している通り複数の TCP 接続を使用できるようになりました。 SQL Server 2022 の新機能により複数の TCP セッションからログを転送することで、FILESTREAM の内部的なログの順序がずれてしまうことで、同期に異常が発生することが原因です。 本事象についてはSQL Server 2022 の動作上の制限になります。 SQL Server 2022 (16.x) の新機能 - 可用性 https://learn.microsoft.com/ja-jp/sql/sql-server/what-s-new-in-sql-server-2022#availability ***** 分散型可用性グループ - tcp 待機時間が長いリモート リンク間のネットワーク帯域幅使用率を向上させるために、複数の TCP 接続を使用するようになりました。 ***** 対処策 本事象の対処策は、トレースフラグ 5597 を設定することです。 トレースフラグ 5597 は、SQL Server 2022の新機能(分散型可用性グループにおける複数TCP使用) を無効するのみで、以前のバージョンと同等な動作となり、他への影響はありません。 変更手順 トレースフラグ 5597 の設定方法は、以下の通りです。 トレースフラグ設定方法 -------------------------------- 1) SQL Server Configuration Manager (構成マネージャー)を起動します。 2) SQL Serverのサービス-> SQL Server (MSSQLSERVER もしくは インスタンス名) を右クリックし、プロパティを開きます。 3) [起動時のパラメーター] タブの[起動時のパラメーターの指定] ボックスに下記の値を入力し、[追加] をクリックします。 -T5597 5) [OK]をクリックし、設定を確定します。設定は、次回SQL Server サービス起動後に有効になります。
DBCC CLONEDATABASE isn't a clone in 2022
We use DBCC CLONEDATABASE currently in SQL Server 2019 and have done in previous versions too. Having recently begun a project to migrate some servers up to SQL 2022 I've found that the use of CLONEDATABASE is no longer giving a "clone" and instead is making some assumptions about my data and implementing (badly) the LEDGER functionality. Example: Say my database has 4 tables, (Table_A, Table_B, Table_C and Table_D) all have the attributes USER_TABLE, NON_TEMPORAL_TABLE and NON_LEDGER_TABLE in sys.tables. Running DBCC CLONEDATABASE creates two of these tables as 'HISTORY_TABLE' types (instead of NON_LEDGER_TABLE), with one being paired to another one of the tables. You can see this relationship as the object_id of say Table_B is present in the 'history_table_id' column of Table_A when looking at sys.tables. The same is true of Table_C and Table_D in my scenario. It is also apparent that on some of the columns in Table_A and Table_C (the ones still created as NON_LEDGER_TABLE types) that the clone has chosen to add 'GENERATED ALWAYS AS ROW END' to some of the fields. I can't run SYSTEM_VERSIONING = OFF as I'm presented with the error that "SYSTEM_VERSIONING is not turned ON" for those tables. I can drop and manually re-create the Table_A & Table_C which removes the 'history_table_id' values, but I still can't drop Table_B and Table_D as they are still seen as a ledger history table. I have no idea why SQL 2022 has made these choices on my behalf and I can't see to get around them, so for now at least I am having to script out the schema of my database and create it that way which leads to its own challenges and isn't as easy as simply specifying 'DBCC CLONEDATABASE' in code.
