如何設定 SQL Server Merge Replication 透過 HTTPS/SSL 進行遠端同步

        SQL SERVER 合併式複寫，可以讓二台 SQL Server 進行資料的同步，此技術非常的適合許多跨地區的資料庫進行，通常許多公司會透過 VPN 的方式進行綁定不同的網路(路由)，所以其實基本上還是有互通的，所以當資料庫同步時，都是通過預設的 1433 Port 進行同步，但如果彼此之間因為網路的不同時，如果要進行資料同步時，由於異質網路的關於，所以就需要在防火牆開啟 1433 Port，這對許多公司的政策都是不允許的，因為會有安全性的問題。

本篇介紹的，就是要解決這個問題，其實就是散發的資料/數據，透過網頁 HTTPS/SSL 進行同步的動作，本篇測試時雖然有許多參考資料，但其實在自已進行測試時，你會發現有許多的問題，所以我才會特別的整理此篇，希望提供給大家參考。

環境說明：

• SQL Server 2019 為發行與散發
• SQL Server 2017 為訂閱端

在選擇 IIS 進行同步的部份，基本上可以不用與 SQL Server 在同一台上，但此次我是與 SQL Server 設定在同一台上進行。

1. 預用 Web Server (IIS) 的功能，在啟用時，除了預設的項目外，也需要啟用下列的項目。

• Web Server (IIS) -> Web Server -> Security -> Basic Authentication 
• Web Server (IIS) -> Web Server -> Application Development -> .Net Extensibility 3.5
• Web Server (IIS) -> Web Server -> Application Development -> .Net Extensibility 4.7
• Web Server (IIS) -> Web Server -> Application Development -> ISAPI Extensions
• Web Server (IIS) -> Web Server -> Application Development -> ISAPI Filters 

2. 設定 Web 複寫目錄

在設定 Web Synchronization 的部份，其實也是可以透過 SSMS 的工具來進行設定，但在設定後發現仍有問題，而且其中有一些限制，所以我還是手把手的逐一設定，至少那一個部份有錯，也比較好找出錯誤的部份，下列是一些例圖，所以大家在參考一下就好，當然要用這個進行也是可以的。

2-1 IIS 啟用後，請在下列的位置下新增一個目錄，名稱為 "SQLReplication"

C:\inetpub\wwwroot\

請盡可能的將資料夾建立在此，要不然後面要設定相關的安全性，問題有點多會不好排除問題。

2-2 我的 SQL Server 版本為 2019，所以請至下列的目錄，將 "replisapi.dll" 的檔案複制到 2-1 中的 "SQLReplication" 中。

C:\Program Files\Microsoft SQL Server\150\COM\

由於 SQL Server 2019 為 64位元，所以此元件也是 64 位元的，這 "非常" "非常" "非常" 的重要，千萬不要搞錯了。

2-3 請透過系統管理者的權限開啟一個 Dos Command 視窗後，然後輸入下列的指令註冊此元件。

regsvr32 C:\inetpub\wwwroot\SQLReplication\replisapi.dll

3. 設定 IIS 站台目錄

3-1 請先確認 IIS 的預設站台可以正常瀏覽。

https://cary-sql2019/iisstart.htm

3-2 新增一個目錄針對此 SQLReplication

3-3 新增時，請點選 "Test Settings" 確認沒有任何的錯誤。

4. 設定 IIS 站台目錄(SQLRrplication) 啟用 HTTPS/SSL 的功能，這部份可以透過申請的 SSL 憑證或憑證伺服器進行，但這部份我透過自我簽署的憑證進行。

4-1 請至 主機 -> Server Certificates -> Create Self-Signed Certificates

4-2 請至預設站台 (Default Web Site) -> Bindings -> Add -> https

4-3 設定 SSL Settings，勾選 Require SSL 的設定，當使用者存取網頁都必須透過 HTTPS/SSL 進行存取。

5. 設定站台目錄(SQLRrplication)的驗證項目，為了安全性，所以必須啟用 Basic Authentication，並停用 Anonymous Authentication。

6. 設定 replisapi.dll 模組對應至此站台目錄(SQLReplication)中。

7. 測試是否可以正常的執行模組 (replisapi.dll)

https://cary-sql2019/SQLReplication/replisapi.dll

https://cary-sql2019/SQLReplication/replisapi.dll?diag

請確認 "Class Initialization test" 的狀態 (Status) 都是 SUCCESS 而且沒有任何的錯誤，要不然後續在進行同步時，會有問題。

8. 由於是自我簽署的憑證，所以在訂閱端透過瀏覽器進行訪問時，會出現如下列的錯誤訊息，所以一定要把憑證匯出從 IIS 端後，再匯入至用戶端(訂閱端)，確認此錯誤訊息不會出現，要不然後續進行資料同步時，就會發生問題。

8-1 憑證匯出

請至 IIS -> Server Certificates -> Export，建議設定密碼進行保護。

8-2 憑證匯入

請將匯出的憑證複制至用戶端(訂閱端)，然後選擇 "Install PFX"

匯入的位置，請手動選擇，將憑證匯入至 "Trusted Root Certification Authorities" 中即可，我選擇第一項時，其實無效，透過瀏覽器確認時，仍有錯誤，所以請選擇手動匯入。

另外在匯入時，選擇 Current User or Local Machine 都可以，我這邊是選擇匯入至 Current User.

完成上述的設定後，基本上就完成大半部，後續的複寫的部份，簡單的透過介面進行 SQL Replication 的建立就可以了。

9. 建立合併式複寫 (Merge Replication) 的發行與散發的部份，這部份沒有特別需要注意的，所以我就不特別截圖說明。

10. 針對剛剛建立好的合併式複寫設定 Web Synchronization 的功能，請將網址填入至下列的欄位中。

11. 建立訂閱端設定，基本上也透過介面進行設定，我就將特別的幾個畫面整理如下。

11-1 請選擇 pull subscriptions 的方式

11-2 請勾選 Use Web Synchronization 的方式

11-3 設定透過 Web Synchronization 時，相關的設定

12. 設定完成，可以發現在同步後，可以透過訂閱端上的 SQL Agent -> Job History 來進行確認，訂閱端是如何進行同步，如下列的資訊。

Date 12/26/2023 5:44:38 PM

Log Job History (CARY-SQL2019-db-replication-nodomain-replication-WIN-VB0R8UQVUA2-db-replication- 0)

Step ID 1

Server WIN-VB0R8UQVUA2

Job Name CARY-SQL2019-db-replication-nodomain-replication-WIN-VB0R8UQVUA2-db-replication- 0

Step Name Run agent.

Duration 00:00:01

Retries Attempted 0

Message

-XSERVER WIN-VB0R8UQVUA2

-XCMDLINE 0

-XCancelEventHandle 0000000000001ADC

-XParentProcessHandle 0000000000001CE4

2023-12-26 09:44:38.896 Connecting to Subscriber 'WIN-VB0R8UQVUA2'

2023-12-26 09:44:38.943 The upload message to be sent to Publisher 'CARY-SQL2019' is being generated

2023-12-26 09:44:38.943 The merge process is using Exchange ID '947521E2-682C-429A-B87A-8CD68F331656' for this web synchronization session.

2023-12-26 09:44:38.990 Uploading data changes to the Publisher

2023-12-26 09:44:39.068 No data needed to be merged.

2023-12-26 09:44:39.068 Request message generated, now making it ready for upload.

2023-12-26 09:44:39.068 Upload request size is 2058 bytes.

2023-12-26 09:44:39.397 Uploaded a total of 1 chunks.

2023-12-26 09:44:39.397 The request message was sent to 'https://cary-sql2019/SQLReplication/replisapi.dll'

2023-12-26 09:44:39.397 Downloaded a total of 3 chunks.

2023-12-26 09:44:39.397 The response message was received from 'https://cary-sql2019/SQLReplication/replisapi.dll' and is being processed.

2023-12-26 09:44:39.397 Connecting to Subscriber 'WIN-VB0R8UQVUA2'

2023-12-26 09:44:39.412 The changes contained in the message downloaded from Publisher 'CARY-SQL2019' will be applied after having collected and displayed the upload statistics.

2023-12-26 09:44:39.412 Downloading data changes to the Subscriber

2023-12-26 09:44:39.694 [100%] Downloaded 1 change(s) in 'test-db1' (1 insert): 1 total

2023-12-26 09:44:39.709 [100%] Web synchronization progress: 99% complete.

=============================================================

Article Download Statistics:

============================

test-db1:

Inserts: 1

Relative Cost: 100.00%

Session Statistics:

============================

Download Inserts: 1

Change Delivery Time: 0 sec

Schema Change and Bulk Insert Time: 0 sec

Delivery Rate: 0.00 rows/sec

Total Session Duration: 0 sec

=============================================================

2023-12-26 09:44:39.709 Connecting to Subscriber 'WIN-VB0R8UQVUA2'

2023-12-26 09:44:39.709 The upload message to be sent to Publisher 'CARY-SQL2019' is being generated

2023-12-26 09:44:39.709 The merge process is using Exchange ID '63480F83-5715-4207-8BF7-9E94D78F0A86' for this web synchronization session.

2023-12-26 09:44:39.756 Uploading data changes to the Publisher

2023-12-26 09:44:39.756 [100%] Request message generated, now making it ready for upload.

2023-12-26 09:44:39.756 [100%] Upload request size is 2073 bytes.

2023-12-26 09:44:39.803 [100%] Uploaded a total of 1 chunks.

2023-12-26 09:44:39.803 [100%] The request message was sent to 'https://cary-sql2019/SQLReplication/replisapi.dll'

2023-12-26 09:44:39.803 [100%] Downloaded a total of 3 chunks.

2023-12-26 09:44:39.803 [100%] The response message was received from 'https://cary-sql2019/SQLReplication/replisapi.dll' and is being processed.

2023-12-26 09:44:39.803 Connecting to Subscriber 'WIN-VB0R8UQVUA2'

2023-12-26 09:44:39.819 The changes contained in the message downloaded from Publisher 'CARY-SQL2019' will be applied after having collected and displayed the upload statistics.

2023-12-26 09:44:39.819 [100%] Downloading data changes to the Subscriber

2023-12-26 09:44:39.819 [100%] Web synchronization progress: 99% complete.

2023-12-26 09:44:39.834 [100%] Merge completed after processing 1 data change(s) (1 insert(s), 0 update(s), 0 delete(s), 0 conflict(s)).

=============================================================

Article Download Statistics:

============================

test-db1:

Inserts: 1

Relative Cost: 100.00%

Session Statistics:

============================

Download Inserts: 1

Change Delivery Time: 0 sec

Schema Change and Bulk Insert Time: 0 sec

Delivery Rate: 0.00 rows/sec

Total Session Duration: 0 sec

=============================================================

如何進行 SQL Server 效能資料收集與分析 - 以 LogScout, PSSDiag, SQL Nexus 工具為例

         前面的文章，有介紹過該如何透過 TroubleShootingScript toolset (TSS) 收集系統資訊，這個通常主要用於分析如資料庫為何 Failover，意外重啟等情況，但如果要進行效能分析時，該如何進行，因為很多時候效能的問題無法立即重現與立即觀察，所以本篇要來特別介紹該如何來收集效能資訊與收集到的資訊後，該如何進行工具幫忙進行分析並給出建議。

Windows 資料收集工具介紹 - TroubleShootingScript toolset (TSS)
https://caryhsu.blogspot.com/2023/11/windows-troubleshootingscript-toolset.html

這三套工具都是由 Microsoft 所推出與維護的，而且也是 Microsoft 的工程師在分析時的工具之一，所以可以安心的使用。

一般在效能分析上，我們簡單的分成長時間的收集與短時間的收集，這個取決於問題多久重現一次，如客戶反應每天的凌晨的排程與相關作業都會變慢，這種有特定的時間點，而且很快的會重現的，我們就可以透過短時間的收集，而如果是很久才會重現一次，而且不確認時間的話，就需考慮透過長時間的觀察來找到問題，長時間與短時間最重要的是在收集時對系統的效能影響，一般來說可能會有5-10%的影響(也有可能更高，取決於系統的使用情況)，所以如果系統一直透過長時間的進行，反而會影響到系統，也會造成因為收集而空間耗用的情況，所以需要簡單先區分類型。

在收集的工具上分成 LogScout 與 PSSDiag 二種，二種都是都用來進行 SQL Server 的效能收集，而且收集後的資訊也都可以透過 SQL Nexus 進行分析。

二者在對最後的分析上沒有一定要使用上那一個工具才可以，但在收集的使用上，坦白說我比較推薦選擇 LogScout，一來此工具比較新，二來 LogScout 不需要像 PSSDiag 要先配制好相對的SQL Server 版本，而且可以在執行時才設定收集的項目等，所以在使用上比較彈性，但我在本篇中也會對二個工具都逐一的介紹。

PS: PSSDiag 可以額外的設定要收集多久的資訊，如1個小時或2個小時，算是一個比較方便的部份。

收集方式：
==============

1. LogScout:

最小需求：

• Windows 2012 or later (including Windows Server Core)
• Powershell version 4.0, 5.0, or 6.0

說明網址：https://github.com/microsoft/SQL_LogScout

此工具已有內建在 SQL Server on Windows VM 上，所以不需要額外的進行下載。

檔案在下載解壓縮後，只需執行該目錄下的 SQL_LogScout 即可，當下可以選擇透過 GUI 的介面或文字模式進行收集的設定，如下圖，如果透過文字的方式進行時，可以透過數字來選擇需要進行的項目，如進行效能收集，我就會選擇 0+1+4+6+11 進行。

圖型介面

文字介面

如果看到下列的文字，即代表目前已在收集中，所以可以請客戶進行問題的重現，此時請不要關閉視窗，待完成後，再輸入 STOP 就可以完成收集。

收集完成後，您就可以看到指定的目錄中會產生一個 output 的目錄，裡面就是收集的相關檔案。

2. PSSDiag:

最小需求：

Diag Manager

• Windows 7 or Windows 10 (32 or 64 bit)
• .NET Framework 4.5

說明網址：
https://github.com/microsoft/DiagManager

此工具分成二個部份，第一是需要先確認要收集的 SQL Server 版本，與需要收集那些資料，而且如果是叢集的話，收集方式也會不同，當如果配置錯誤，在執行時就會發生錯誤，如下列所示。

此配置的部份，可以找一台符合最小需求的電腦，不需安裝 SQL Server 即可進行，下載壓縮檔並解開後，執行 DiagManager 的執行檔後，即可進行配置，如下圖，待配置好後，即可點選 Save 進行儲存，儲存後即會在指定的目錄下產生一個檔案，此為主要進行的程式。

將配置好的檔案複制到 SQL Server 上，然後進行解壓縮，並執行 .\pssdiag.ps1 即可進行收集， 此時也是請不要關閉視窗，待完成後，輸入 CTRL+C 的組合鍵進行停止即可。

上述的二個收集方式，建議要收集最少15分鐘以上，以免最後在透過 SQL Nexus 進行分析時，無法進行。

分析方式：
==============

SQL Nexus :

在使用 SQL Nexus 前，可以找隨意一台進行，只需符合下列的條件即可，在使用時，需要安裝多個不同的組件，還需要找一台 SQL Server 進行中介處理，所以通常我會找一台測試機進行即可，另外在安裝上，可以直接下載官方的 PowerShell 進行自動判斷安裝與檢查，不用逐一下載，省下很多的步驟。

最小需求：

• .NET framework 4.8 (runtime is sufficient). Windows 11 has version already.
• Download and install SQLSysClrTypes
• Download and install ReportViewer control (ReportViewer.msi)
• Download and install RML Utilities (RMLSetup_AMD64.msi)
• An instance of SQL Server (2012 or above) to connect to and process data
• Optional: PowerBI Desktop

自動判斷安裝與下載 (直接下載此檔案進行即可自動判斷)
https://github.com/microsoft/SqlNexus/blob/master/Setup-Related/SetupSQLNexusPrereq.ps1

在每個版本下，都會有原始碼與執行檔可以下載，直接進行下載即可，此篇寫作時，版本為 7.23.06.06, 所以下載 SQLNexus_7.23.06.06_Signed.zip 並進行解壓縮。

下載網址：
https://github.com/microsoft/SqlNexus/releases

執行 sqlnexus.exe 的程式後，即可出現主畫面，一開始會讓你選擇要透過那一台 SQL Server 要進行中介處理的動作，此時也請將收集到的檔案放到此主機上進行分析。

選擇主畫面中左下角的 Import，將所有的分析資訊進行匯入，另外路徑的部份，請不要使用中文，以免發生解析錯誤。

匯入的過程中，可能會需要一些時間，匯入完成後，會在中介處理的 SQL Server 主機上也會出現一個 sqlnexus 的資料庫。

最後處理完成後，你就會看到一個完整的分析說明，你可以從中看到各個不同的項目，你也可以逐一點開來看是否有建議改善等資訊可以參考，其實如果有建立案件到 Microsoft 時，這也是 Microsoft 的工程師們，會進行的一個方式，但其中的數據解讀才是真正的大學問，其中的寶藏，就等著大家去發現了。

如何設定無網域與無叢集架構的 SQLServer AlwaysOn - 簡易可讀取性複本

        之前多篇文章皆有介紹多種不同高可用性的 AlwaysOn 架構，但通常標準的 AlwaysOn 需要加入網域與架設在叢集服務上，但如果用戶端只是希望可以將資料抄寫到另一個節點，增加可讀副本，也不想用網域與叢集的服務時，此篇的方式，就是一個很節省成本的作法。

在介紹前，我也要先說明一下這個作法的缺點，由於是沒有架設在叢集上，所以沒有自動 Failover 的功能，只能手動進行切換，而且 Listener 也無法使用，所以請在使用前先參考環境需求，再進行使用。

安裝說明：
============

1. 請在二台主機依照單機的方式直接安裝 SQL Server。

2. 在二台主機上，分別啟用 AlwaysOn 可用性群組。

3. 請在二台主機上新增登入與使用者，此帳號只用於 AlwaysON 端點(endpoint)溝通使用，只需要給連線到端點(endpoint)的權限即可。

CREATE LOGIN dbm_login WITH PASSWORD = '1234qwer!@#$';

CREATE USER dbm_user FOR LOGIN dbm_login;

PS: 權限稍後會設定

4. 通常二台主機在沒有加入網域的情況下，可以透過相同的帳號密碼或憑證進行溝通，但此部份我們選擇透過憑證來進行，這也是比較推薦的作法。在第一台主機上設定憑證。

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'caryhsu@0316';

CREATE CERTIFICATE dba_certificate WITH SUBJECT = 'carytestclusterless';

BACKUP CERTIFICATE dba_certificate

  TO FILE = 'C:\cary-backup\dba_certificate.cer'

  WITH PRIVATE KEY (

          FILE = 'C:\cary-backup\dbm_certificate.pvk',

          ENCRYPTION BY PASSWORD = 'caryhsu@0316'

      );

PS: 上述的憑證很重要，請要小心保存，如果不見的話，會無法進行還原，其他的功能，如 TDE 也會用到此憑證來進行啟用。

5. 將上述的二個憑證檔案複制到第二台主機上，然後透過下列的指令進行建立憑證。

CREATE CERTIFICATE dba_certificate

AUTHORIZATION dbm_user

FROM FILE = 'C:\cary-backup\dba_certificate.cer'

WITH PRIVATE KEY (

FILE = 'C:\cary-backup\dbm_certificate.pvk',

DECRYPTION BY PASSWORD = 'caryhsu@19810316');

PS: 上述的 dbm_user 是在步驟三建立的使用者。

6. 在二台主機上分別建立端點 (endpoint)，並且賦予連接至端點的權限。

CREATE ENDPOINT [Hadr_endpoint]

    AS TCP (LISTENER_PORT = 5022)

    FOR DATABASE_MIRRORING (

    ROLE = ALL,

    AUTHENTICATION = CERTIFICATE dba_certificate,

ENCRYPTION = REQUIRED ALGORITHM AES

);

ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [dbm_login];

PS: 由於我們是設定透過憑證進行驗證，所以此部份一定要透過指令的方式進行

一切設定完成後，我們就可以來設定啟用 AlwaysOn。 

7. 請在第一台主機上執行下列的指令進行建立可用性群組.

CREATE AVAILABILITY GROUP [ClusterlessAG]

WITH (CLUSTER_TYPE = NONE)

FOR REPLICA ON

N'ClusterlessAG1' WITH (

ENDPOINT_URL = N'tcp://ClusterLessAG1:5022',

AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,

FAILOVER_MODE = MANUAL,

SEEDING_MODE = AUTOMATIC,

SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)

),

N'ClusterlessAG2' WITH (

ENDPOINT_URL = N'tcp://ClusterLessAG2:5022',

AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,

FAILOVER_MODE = MANUAL,

SEEDING_MODE = AUTOMATIC,

SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)

);

ALTER AVAILABILITY GROUP [ClusterlessAG] GRANT CREATE ANY DATABASE;

• 上述中的 SEEDING_MODE = AUTOMATIC 是代表建立後，如果資料庫加入時，會自動同步至另一個節點，如果資料庫過大時，建議設定成 SEEDING_MODE = MANUAL，代表建立後自行還原，藉以減少初使同步的時間。
• 上述中的 CLUSTER_TYPE = NONE 代表就是沒有使用任何的叢集服務

8. 請在第二台主機上執行，將第二台主機加入可用性群組中。

ALTER AVAILABILITY GROUP [ClusterlessAG] JOIN WITH (CLUSTER_TYPE = NONE);

ALTER AVAILABILITY GROUP [ClusterlessAG] GRANT CREATE ANY DATABASE;

9. 請在第一台主機上執行，將資料庫加入到可用性群組中。

ALTER AVAILABILITY GROUP [ClusterlessAG] ADD DATABASE [testdb];

PS: 加入的資料庫請確認設定為完整的複原模式 (Full Recovery)，而且已有進行一次完全備份( Full Backup)。

10. 嘗試要加入 Listener，是可以加入成功，但實際上是無法作用的，一來因為沒有網域，所以此 Listener 是無法進行註冊，而且也沒有自動 Failover，都是手動的方式，所以在連線時，需要特別指定連線到主要節點，還是連線到次要節點，所以在前端的部份，也是需要特別的注意。

如何建立 SQL Server AlwasyOn 分散式可用性群組 - 進階高可用性

        在之前陸續介紹多種不同方式 SQL Server AlwaysOn 的設定與安裝的方式，可以有效的提高資料庫的高可用性，這次我們再來介紹 AlwaysOn 進階的部份 分散式可用性群組 (Distributed availability groups) 的功能。

相關連結參考：
在混合雲的架構上建立完整的AlwaysOn架構
http://caryhsu.blogspot.com/2015/12/alwayson.html
SQL Server 2012 新功能 - AlwaysOn安裝與設定
http://caryhsu.blogspot.com/2012/04/sql-server-2012-alwayson.html
如何在Amazon上透過EC2，架設完整的AlwaysOn架構。
https://caryhsu.blogspot.com/2015/10/amazonec2alwayson.html

一般的情況下，我們在 AlwaysOn 的設定上以2個節點為主，進一步的設定，可以將第三個節點放在不同的地區或雲端，藉以當問題發生時，可以將 AlwaysOn 的節點轉移至雲端上，而且也可以當作可讀副本，藉以減輕主節點的壓力。

但在發生問題時，可能由於地端的網域或叢集等問題，所以轉移後，可能仍需及時的確認等問題，所以如果在預算允許的情況下，其實可以建立相同的第二組藉以問題發生時進行移轉，而 AlwaysOn 可以透過 分散式可用性群組 (Distributed availability groups)進行管理，當發生問題時，可以進行轉移的動作。

常見的方式，直接將第三個或第四個節點放在不同區或雲端上。

可用性群組 (Distributed availability groups) 的方式，也是本篇介紹的方式。

在使用 分散式可用性群組 (Distributed availability groups) 的部份，有下列的幾個優點：

1. 將叢集節點建立在不同的地區，而且真正作到多叢集多節點的情境。
2. 資料中心(DataCenter) 轉移。
3. 延伸可讀副本至不同的地區上。

環境說明：
==============

1. AD - Windows Server 2022
2. SQL Server Nodes, 這裡主要有四台 SQL Server，一個叢集中有二個SQL Server的節點

安裝方式：
==============

1. 請依照下列的文章將二組叢集建立好. 

SQL Server 2012 新功能 - AlwaysOn安裝與設定
http://caryhsu.blogspot.com/2012/04/sql-server-2012-alwayson.html

2. 請在第一組叢集的部份，建立第一組的 AlwaysOn，然後確認轉移等功能皆正常。

3. 在第二組叢集時，AlwaysOn 可以透過自動同步的方式進行建立，但通常如果資料庫較大，會透過備分的方式進行還原，而且這樣在建立上，問題也會比較單純。

4. 目前請確認二組的叢集在 Failover 上皆正常，可以 Listener 也可以正常的連接，最後在 Endpoint 的部份，也都確認有建立完成。

透過 SQL 語法進行查詢

SELECT * FROM sys.endpoints
where type = 4

5. 請透過下列的語法，建立 分散式可用性群組 (Distributed availability groups)

CREATE AVAILABILITY GROUP [distributedag]  

   WITH (DISTRIBUTED)   

   AVAILABILITY GROUP ON  

      'sqlag2019-1' WITH    

      (   

         LISTENER_URL = 'tcp://sqlag2019ag1lt.mscaryhsu.com:5022',    

         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   

         FAILOVER_MODE = MANUAL,   

         SEEDING_MODE = MANUAL   

      ),   

      'sqlag2019-2' WITH    

      (   

         LISTENER_URL = 'tcp://sqlag2019ag2lt.mscaryhsu.com:5022',   

         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   

         FAILOVER_MODE = MANUAL,   

         SEEDING_MODE = MANUAL   

      );    

GO 

上述中可以看到 分散式可用性群組 (Distributed availability groups) 主要是將二個 AlwaysOn 透過 Listener 進行綁定，其中在 AVAILABILITY_MODE 一定要設定為 ASYNCHRONOUS_COMMIT 模式，因為如果設定為 SYNCHRONOUS_COMMIT 的模式，因為要等於第一個叢集完成後，也要同時寫到第二個叢集才算一個交易的完成，一來會造成交易的時間過長，二來也會因為跨區的網路延遲造成問題，由於是 ASYNCHRONOUS_COMMIT 模式，所以在 FAILOVER_MODE 也會是手動的方式(MANUAL)，最後在 SEEDING_MODE 也就是在同步時，如果資料庫不存在，進行初使化為同步傳送，還是透過手動進行，因為我們上一個步驟是透過手動進行還原，所以這個步驟就設定成 SEEDING_MODE = MANUAL。

6. 最後建立完成後，如果要進行手動的 Failover，可以透過下列的方式進行轉移。

ALTER AVAILABILITY GROUP [distributedag] FORCE_FAILOVER_ALLOW_DATA_LOSS;

設定完上述的部份即已完成，但其實用性上來說，個人感覺使用第三個節點於雲端上已算是很好的部份，你要地端與雲端都同時發生問題，我想可能真的是發生了很嚴重的事情了，大家也別太擔心，最後也希望這篇有幫助到大家。

Windows 資料收集工具介紹 - TroubleShootingScript toolset (TSS)

        在協助客戶進行問題排除時，往往我們要針對不同的情境進行不同資料的收集，因為有許多的資料收集，可能會造成系統上的效能影響，所以需依情況而定。

以往我們可能會寫好收集的步驟，請客戶逐一進行收集，有時候步驟較多怕客戶漏掉或客戶怕麻煩就直接跳過，所以只好手把手的一步一步的帶著客戶，而許多時候，有許多的收集工具，可能需要透過執行檔或安裝進行，但由於許多客戶端的政策，所以無法進行。

在此我們介紹一個好用，也是目前 Microsoft 主推的收集工具，相信有許多建立案件給微軟時，MS工程師也會透過此工具請客戶進行資料的收集，所以本篇我們來介紹如何透過 TroubleShootingScript toolset (TSS) 進行 Windows 主機資訊的收集。

從下列的文件上來看，此工具可是集結許多 Microsoft Internal 的工具大成，其中包含 ProcDump，ProcMon，Xperf等工具，而且此工具不需安裝，而是透過 PowerShell 進行收集，所以非常的適合收集主機的資訊進行收集並再進行分析。

Introduction to TroubleShootingScript toolset (TSS)
Introduction to TroubleShootingScript toolset (TSS) - Windows Client | Microsoft Learn

接下來我們就說明如何透過此工具收集 SQL Server 主機的資訊。

1. 從下列的位址下載 TSS。

http://aka.ms/getTSS

2. 下載後，請解壓縮檔案。

3. 解壓縮後，請開啟一個 PowerShell 視窗，然後切換到相對應的視窗，並輸入下列的指令。

.\TSS.ps1 -SDP SQLbase -noPSR -AcceptEula

PS: 
SDP: Collect Support Diagnostic Package (SDP) for the specified specialty
noPSR: do not run PSR, used to override setting in preconfigured TS scenarios
SQLbase: 收集時資料夾的名稱

收集的過程約過5分鐘左右，但由於我的 VM 分配 1 Core 與 4GB 的記憶體，所以收集的過程中CPU是接近滿載的情況。

4. 收集完成後，會自動壓縮成一個檔案，將此檔案提供給原廠即可。

5. 進一步的解開此檔案，其實可以用來分析如系統的組態、防火牆，網路配置、系統日誌，同時在系統上有裝的服務，也會一同的收集，如 SQL Server 等相關的資訊。

6. 在這裡介紹相關 TSS 工具的初步說明，但其實仍可以再進一步的收集如效能監視器，TTT (Time Travel Debugging)，Process Monitor等長期收集的工具，後續有機會再來逐一介紹，也希望大家如果要協助客戶或朋友進行分析時，強力推薦透過這個工具來進行。