聽說 SQL Server 2022 開始增加所謂的「Contained Availability Group ( 自主可用性群組 )」，可以讓存在 master 資料庫的登入帳號同步，因此安裝起來測試看看是否跟想像中的相同。
原本對於 SQL Server 2022 並沒有太多的想法，直到前一陣子，剛好有同事在問我有關於如何讓 AG 之間可以有方法來同步登入帳號，原本利用 DDL Trigger 和一些 DMV 來做處理，雖然可以做到同步的機制，但整個過程就有點麻煩。當好在查找文章的時候，無意間看到 SQL Server 2022 有提供所謂的「Contained Availability Group」，就是為了這樣的目的來設計的，因此看到 CTP 2.0 推出的時候，就趕快來測試一下。原本自己沒有想太多，就利用 Azure 的 VM 來搭配 Virtual Network 的機制，來把 Lab 環境給建立起來，但沒有注意到需要設定 VNN Listen ( Virtual Network Name : 相關可參考 網址 )，造成容錯移轉切換之後，無法正確透過 Listen 連接到正確主機上，導致 Lab 起來的狀況怪怪的。因此想說針對 VNN 的部分再找時間來測試，而把整個 Lab 放到我的電腦上來架設 VM 測試，畢竟要一台老電腦開 3 個 VM ，實在是不是很順暢，因此又拖延了一段時間，才把整個環境給弄好。
基本上 SQL Server 2022 在安裝上跟之前就版本的沒有太大的不同，要建立 AG ( Availability Group ) 也是同樣的方法，因此我用 Windows 2022 先建立了三個 VM ，分別是 AD , SQL-1 和 SQL-2 這三台，如果扣除網路傳輸和等待的時間( 主要是因為 Windows Update 和主機的環境並不是很好，因此大概花了 4 小時 )，基本上安裝起來算是很快的。當安裝好預備環境之後，我利用 SSMS v19.2 的 preview 版本來建立 AG，在建立的過程中可以看到多了一個選項「內含 - 重複使用系統資料庫」，而除了這個選項之外，其餘所有步驟都跟之前版本的相同。
而當我建立好我的 AG 之後，原本我只選擇放入一個 DEMO 的資料庫，而因為前面的步驟有選擇「內含」，因此會自動多增加兩個資料庫的副本，會用 「(AG名稱)_master」 和 「(AG名稱)_msdb」，看來一個是針對帳號和權限，而另外一個是針對排程的部分，
從上面的結果看起來蠻特別的，因此我用 SSMS 分別登入 SQL-1 和 SQLListen ( 此次測試 AG 的 Listen ) ，從下面這張圖可以看出，當我登入 AG 中的一台的時候，會看到在資料庫中有多出兩個資料庫一併在此次的可用性群組，但是當我登入 SQLListen 的時候，他會看不到那兩個新增出來的資料庫，同時也沒有 「Always On 高可用性」的節點。
為了更加確認，我就改用 T-SQL 來測試一下
select name,physical_database_name from sys.databases這個是連接 SQL-1 所執行的結果，從 DMV 中可以看到，可以查到有七個資料庫，除了我自己建立的 DEMO 資料庫之外，還有一個 SQLAG_msdb 和 SQLAG_master 的資料庫，而在 SQL 2022 的 DMV 裡面，還多了一個 physical_database_name 的欄位，可以看到目前 name 和 physical_database_name 的欄位值都是相同的
但是當我透過 SQLListen 去連線的時候，結果就有點不一樣了，會看到只有四個資料庫，而且透過 database_id 和 physical_database_name 這兩個欄位，我們可以看到當透過 Listen 去連線的時候，SQLAG_master 資料庫會模擬 master 資料庫，但 SQLAG_msdb 的資料庫會取代 msdb 。
為了確認前面所提出的看法，因此我又做了一個簡單的實驗，我在連接 SQL-1 的時候，此時去建立一個 test1 的登入帳號，並且將該帳號對應到 DEMO 資料庫，使得該帳號屬於 db_datareader 的資料庫角色
接著我又類似同樣的方式，但是此次確認登入 SQLListen 之後才去建立的，此時建立的登入帳號為 test2，也同樣將該帳號對應到 DEMO 資料庫，使得該帳號屬於 db_datareader 的資料庫角色
此時我們用 sqlcmd 來做個測試，會發現當我們用 test1 和 test2 這兩個帳號去登入 SQLListen 的時候，test1 的帳號是無法登入的
此時我們再做一次容錯移轉，將 Primary 移轉到 SQL-2 的 Instance 上面
同樣再使用 sqlcmd 去測試，此時從下面的圖中可以看到 test1 依然無法登入，而 test2 的帳號是可以登入的，也可以確認我們現在所連接的是 SQL-2 的環境。因此我們可以得到一個結論，當我們透過 Availability group listener 去連接的時候，而且該可用性群組有設定為 Contained，則 SQL Server 會將登入帳號存在「(AG名稱)_master」 之下，但如果您是直接連接 SQL Instance 的時候，則 SQL Server 會將登入帳號存在 master 的資料庫
因此透過上述的測試，可以大概知道自主可用性群組 ( contained availability group ) 對於帳號是怎麼樣的處理，但是自主可用性群組除了對登入帳號的處理之外，還會影響排程的處理，但因為那個部分又有不少東西，因此在這一篇中，我就僅先測試帳號的部分做個說明，其他就等下次再另外做個實驗來說明。