CaryHsu - 學無止盡

2023年12月11日星期一

如何進行 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 的工程師們，會進行的一個方式，但其中的數據解讀才是真正的大學問，其中的寶藏，就等著大家去發現了。

2023年12月7日星期四

如何設定無網域與無叢集架構的 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，都是手動的方式，所以在連線時，需要特別指定連線到主要節點，還是連線到次要節點，所以在前端的部份，也是需要特別的注意。

2023年12月4日星期一

如何建立 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) 的部份，有下列的幾個優點：

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

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

AD - Windows Server 2022
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;

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

2023年11月21日星期二

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等長期收集的工具，後續有機會再來逐一介紹，也希望大家如果要協助客戶或朋友進行分析時，強力推薦透過這個工具來進行。

2023年11月17日星期五

設定 Kerberos 驗證與 SQL Server 連線與問題排除

最近遇到許多關於 Kerberos 的問題，所以我也自學習並整理相關 Kerberos 的問題，希望對大家會有幫助，也提供給自已記錄。

在 SQL Server 的驗證模式，可以分成 SQL Server 驗證與 Windows 的整合驗證，而在網域的環境下，Windows 整合驗證主要透過 Kerberos 進行，但在 Kerberos 無法啟用成功時，就會透過 NTLM 的方式進行，簡單的說，NTLM 是一種舊的認證方式，而且本身在證驗過程會帶著使用者輸入的密碼，而且加密方式也被證實是可以被反計算出的，所以微軟建議透過 Kerberos 的方式進行連線驗證，而二者之間的差異，也可以透過下列的文章進行了解。

NTLM 驗證模式：

Kerberos 驗證模式：

NTLM vs KERBEROS
https://answers.microsoft.com/en-us/msoffice/forum/all/ntlm-vs-kerberos/d8b139bf-6b5a-4a53-9a00-bb75d4e219eb

使用 Kerberos 的好處：

More secure: No password stored locally or sent over the net.
Best performance: improved performance over NTLM authentication.
Delegation support: Servers can impersonate clients and use the client's security context to access a resource.
Simpler trust management: Avoids the need to have p2p trust relationships on multiple domains environment.
Supports MFA (Multi Factor Authentication)

而 SQL Server 如果要使用 Kerberos 的驗證模式，必須符合下列二個條件。

用戶端與主機都在相同的網域或在信任的網域中。
Service principal Name(SPN) 又可稱為服務主機名稱，必預註冊於網域中。

Register a Service Principal Name for Kerberos connections
https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/register-a-service-principal-name-for-kerberos-connections?view=sql-server-ver16

針對上述的說明，如果在網域中，預設的情況下會使用 Kerberos 的驗證模式進行，但如何確認目前 Kerberos 是否有啟用，可以透過下列的方式進行確認。

1. 從 SQL Server 的 Error Log 中，確認主機是否有正確的註冊 SPN。

成功的註冊 SPN:

2023-11-16 09:37:30.94 Server The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/SQL2019-AG1.mscaryhsu.com ] for the SQL Server service.

2023-11-16 09:37:30.94 Server The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/SQL2019-AG1.mscaryhsu.com:1433 ] for the SQL Server service.

SPN 註冊失敗：

2023-11-16 10:34:40.80 Server The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/SQL2019-AG2.mscaryhsu.com ] for the SQL Server service. Windows return code: 0x21c7, state: 15. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.

2023-11-16 10:34:40.80 Server The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/SQL2019-AG2.mscaryhsu.com:1433 ] for the SQL Server service. Windows return code: 0x21c7, state: 15. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.

2. 透過語法確認目前的連線是 NTLM or Kerberos.

SELECT net_transport, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@spid

如何進行自動註冊 SPN 的動作。

在 SQL Server 端，預設在啟動時，會進行自動註冊 SPN 的動作，如同上述的日誌檔顯示，即可確認成功與否，而這部份也要注意你的啟動帳號必須要有下列的權限，關於啟動帳號的部份，也可以參考我另一篇的文章說明。

Read servicePrincipalName
Write servicePrincipalName

SQL Server 啟動帳號最佳實踐與最小化權限設定
http://caryhsu.blogspot.com/2023/11/sql-server.html

當無法進行自動註冊時，就需要進行手動註冊與問題排除，在此篇，我就透過上述 SPN 註冊失敗的情況為例，說明該如何進行問題排除。

1。從錯誤訊息上看 Windows return code: 0x21c7，如同下列的說明，主要是疑似 SPN 重覆，造成註冊 SPN 失敗。

SPN: 0x21c7
ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST The operation failed because SPN value provided for addition/modification isn't unique forest-wide.

2. 透過 setspn 的指令進行確認，確認該啟動帳號已註冊的 SPN 有那些。

setspn -L mscaryhsu\gmsasql

Registered ServicePrincipalNames for CN=gMSAsql,CN=Managed Service Accounts,DC=mscaryhsu,DC=com:

MSSQLSvc/SQL2019-AG1.mscaryhsu.com:1433
MSSQLSvc/SQL2019-AG1.mscaryhsu.com

3. 從上述來看，只有第一個節點 (AG1) 有註冊成功，但第二個節點 (AG2) 最沒有註冊，所以我嘗試手動註冊第二個節點。

在註冊前，簡單的說一下格式，在預設的情況下，SQL Server 預設的 port 為 1433，所以需同時註冊二個，一個是沒有 port 的連線方式，而另一個則是預設的 port

格式：
setspn -S MSSQLSvc/Server FQDN domain\username

手動進行註冊：

setspn -S MSSQLSvc/SQL2019-AG2.mscaryhsu.com mscaryhsu\gmsasql

Checking domain DC=mscaryhsu,DC=com
CN=cary hsu,CN=Users,DC=mscaryhsu,DC=com
MSSQLSvc/SQL2019-AG2.mscaryhsu.com

Duplicate SPN found, aborting operation!

setspn -S MSSQLSvc/SQL2019-AG2.mscaryhsu.com:1433 mscaryhsu\gmsasql
Checking domain DC=mscaryhsu,DC=com

Registering ServicePrincipalNames for CN=gMSAsql,CN=Managed Service Accounts,DC=mscaryhsu,DC=com
MSSQLSvc/SQL2019-AG2.mscaryhsu.com:1433

Updated object

從上述來看沒有 port 的那一個是註冊失敗的，所以也就是為何 SQL Server 自動註冊失敗的情況。

4。透過 setspn -x 的方式來進行找出重覆的 SPN，但可惜是找不出來的，原因在後面會描述。

setspn -x
Checking domain DC=mscaryhsu,DC=com
Processing entry 0

found 0 group of duplicate SPNs.

5. 透過網域主機上的 Directory Service 日誌，發現一個明顯的錯誤，其實認真的看，你可以看出，主要是有另一個使用者 "caryhsu" 已註冊此台主機所造成，所以當你透過新帳號進行註冊時，就會出現帳號重覆註冊的情況。

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: 2023/11/16 上午 10:34:40
Event ID: 2974
Task Category: Global Catalog
Level: Error
User: MSCARYHSU\gMSAsql$
Computer: Win-CaryDC.mscaryhsu.com
Description:
The attribute value provided is not unique in the forest or partition. Attribute: servicePrincipalName Value=MSSQLSvc/SQL2019-AG2.mscaryhsu.com
CN=cary hsu,CN=Users,DC=mscaryhsu,DC=com Winerror: 8647

6. 透過下列的指令，你可以發現原來兇手就是自已的另一個帳號，因為我換了啟動帳號後，原先的帳號沒有刪除，造成無法註冊更換後的新帳號。

setspn -Q MSSQLSvc/SQL2019-AG2.mscaryhsu.com6.
Checking domain DC=mscaryhsu,DC=com
CN=cary hsu,CN=Users,DC=mscaryhsu,DC=com
MSSQLSvc/SQL2019-AG2.mscaryhsu.com

Existing SPN found!

7。最後，將此舊的 SPN 刪除，並再進行一次註冊後，問題就解決了。

setspn -D MSSQLSvc/SQL2019-AG2.mscaryhsu.com mscaryhsu\caryhsu
Unregistering ServicePrincipalNames for CN=cary hsu,CN=Users,DC=mscaryhsu,DC=com
MSSQLSvc/SQL2019-AG2.mscaryhsu.com

Updated object

setspn -S MSSQLSvc/SQL2019-AG2.mscaryhsu.com mscaryhsu\gmsasql
Checking domain DC=mscaryhsu,DC=com
Registering ServicePrincipalNames for CN=gMSAsql,CN=Managed Service Accounts,DC=mscaryhsu,DC=com
MSSQLSvc/SQL2019-AG2.mscaryhsu.com

Updated object

訂閱：文章 (Atom)

2023年12月11日 星期一

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

2023年12月7日 星期四

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

2023年12月4日 星期一

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

2023年11月21日 星期二

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

2023年11月17日 星期五

設定 Kerberos 驗證與 SQL Server 連線與問題排除

2023年12月11日星期一

2023年12月7日星期四

2023年12月4日星期一

2023年11月21日星期二

2023年11月17日星期五