SQL Q&A: Inside Clustering, Mysterious Hangs, the SA Account, and More

發行項
08/17/2016

SQL 問題與解答深入探索叢集、意外當機、SA 帳戶等

由 Nancy Michell 編輯

問：我需要進一步了解叢集的運作方式。我們的環境將包含執行 SQL Server™ 2005 的 64 位元 Windows Server® 2003、SQL Server Reporting Services (SSRS) Web 伺服陣列 (一種報告伺服器擴充部署)、SSRS TempDB Catalog 伺服器，以及經由連結伺服器提取協力廠商資料庫之資料的 SQL Server，並將儲存 SSRS 的資料。

我們想要由 3 個節點構成的「主動/主動/被動」叢集。Node1 為主動節點，它會儲存從協力廠商資料庫提取的資料。Node2 為主動節點，它會儲存 SSRS Catalog。Node3 為被動節點，它是 Node1 或 Node2 的容錯移轉節點。您可以幫忙嗎？

答：很遺憾，在參照到 SQL Server 叢集時，有太多人被「主動/主動」和「主動/被動」的術語所誤導。他們以為 SQL 叢集可支援在多部伺服器之間擴充一個資料庫或 SQL 執行個體。其實根本不是這麼回事。在 SQL Server 上，並沒有「主動/主動」資料庫或執行個體這種東西。「執行個體」是指有相對應資料庫的 SQL Server 安裝。每個 SQL Server 執行個體的叢集一律為主動 (1) 到被動 (n) (請注意，n 值的範圍是從 1 到 7，視您的 SQL Server 版本而定)。因此稱為容錯移轉叢集。

了解這一點之後，就可以開始考慮在一組節點上安裝容錯移轉叢集的多個執行個體。例如，有三個實體伺服器全部都使用共用磁碟，它們可以在 Node 1 具有一個預設為主動的執行個體，在 Node 2 具有一個預設為主動的第二個執行個體，兩者均可容錯移轉至 Node 3。這兩個執行個體完全分開；它們不共用資料，也不是「主動/主動」。它們都是「主動/被動」，且共用相同的容錯移轉執行個體。如果兩個執行個體都容錯移轉至 Node 3，則如何得知它是否會承受不了負載，將成為日後需要觀察和了解的挑戰。容錯移轉的設計是仰賴容錯移轉的同等處理能力。在正常操作之下，如果尖峰負載需要兩個節點才能處理，則在正常指派給兩個節點的尖峰負載之下，Node 3 不太可能存活 (無法負荷)。

也就是說，由於執行叢集的硬體成本考量，我們知道一般會考慮到兩個主體節點應該不會同時發生問題而強迫單一節點承受全部負載。了解這一點之後，通常會做出的商業決策將是承擔這樣的風險，而不會購買雙倍的裝置以實現 100% 容錯移轉容量。

還好，有一些好消息：SQL Server 2005 提供更多高可用性 (HA) 選項，包括比叢集更快速容錯移轉的替代方案，甚至表示可以複製資料 (叢集仰賴單一 SAN)。這些選項包括鏡像、點對點複寫等。有了這些新的替代方案，就有更多選項可以滿足各種類型的需求，包括可合併許多 HA 功能的選項。

可供下載的 Microsoft® Cluster Configuration Validation Wizard (ClusPrep)，可以取代以前的 Hardware Certification List (HCL) 測試，該測試以往可能需要花費數個月驗證全部組態之後，才能認定它在叢集之下是否為「可支援的」。如今把硬體驗證工具交到 DBA 手上，將可以進一步降低備妥合格硬體的成本 (包括時間和金錢)。它甚至可以在一個叢集節點集內驗證和部署異質硬體。

問：我其中一部機器上的刪除程序似乎當掉超過 12 小時。它並未遭到封鎖。查看最慢的查詢計劃，發現有一個觸發程序執行 87,327 秒，因此我假設程序是在該觸發程序上當掉。我如何得知究竟是哪一個陳述式當掉？

答：很可能是觸發程序內的迴圈基於各種原因而未結束。如果當掉時間很久，而您想要知道是哪一個陳述式在執行，請執行 [圖 1] 的程式碼。它會告訴您目前正在執行的是哪一個陳述式，而這就是造成機器當掉的那個陳述式。

Figure 1 尋找目前正在執行的陳述式

-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20), 
        @start int, 
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle, 
        @start = stmt_start, 
        @end = stmt_end 
FROM Master..sysProcesses(NOLOCK) 
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

問：我需要支援透過防火牆的交易式複寫。發行者和散發者位於防火牆外，訂閱者則位於防火牆內。訂閱者是設定為在 1433 接聽，而這些是我的電腦名稱：發行者：PUBMACHINE，散發者：DISTMACHINE，訂閱者：SUBMACHINE。我需要開啟哪些通訊埠，才能讓初始快照集和發行集發送成功？

答：如果您是使用發送訂閱，則開啟 SQL Server 通訊埠 (以您的情況為 1433) 應該已足夠，因為散發代理程式將在散發者電腦上執行 (在防火牆外)，並且對快照集代理程式所產生的快照檔案可能具有本機存取權。但如果您使用提取訂閱，則在訂閱者電腦上執行的散發代理程式將需要透過防火牆來存取快照集檔案。以下是您可以考慮的選項。

假設已經可以從防火牆外的檔案共用來存取快照集檔案，您可以透過防火牆開啟 Windows® 檔案共用埠，使得在防火牆內執行的散發代理程式可以存取外面的快照集檔案 (不過要注意這對於基礎結構的其他部分可能會有安全隱憂)。請注意，如果您已設定本機路徑做為預設快照集位置 (SSMS 預設值)，則您需要使用散發代理程式的 /AltSnapshotFolder 選項來覆寫快照集檔案選取位置。

您也可以設定複寫來使用 FTP 傳送快照集檔案 (為此，您需要開啟通訊埠 21)。

問：我想知道在 SQL Server 2005 中停用 SA 帳戶是否有任何缺點，以及停用 SA 是否真的可以提高安全性。此問題是否有白皮書可供參考？

答：在新的 SQL Server 2005 安裝上，當未啟用混合模式時，根據預設，會停用 SA 帳戶，並且會為它產生一個隨機密碼。您也可以自行將其停用。並沒有它的白皮書，但在最佳作法文件中有討論到停用及重新命名登入。

如果您希望自己不要破壞 SA 帳戶，也可以將它重新命名。只要記住，如果要啟用一個已停用的帳戶，就應該為它設定新密碼。

關於這樣做是否真的能提高安全性，只要記住停用帳戶之所以能夠增加安全性，是因為停用帳戶之後，猜測密碼的行為根本無效。不論駭客或病毒有多少時間，對已鎖定帳戶進行暴力破解攻擊是不會成功的。重新命名或停用 SA 會中斷需要使用 SA 帳戶進行連線的應用程式。無論如何，尋找並更正或刪除這些應用程式才是首要任務。如上所述，在重新啟用帳戶之前，不能用它來連接到資料庫。還有，由於驗證程序會更快失敗，嘗試對受攻擊系統造成的負荷也將會減輕。

問：我其中一個較大的線上交易處理 (OLTP) 資料庫含有一個記錄檔，它是資料檔的兩倍大。我曾經試著使用下列命令使記錄檔減為合理大小，但它還需要進一步縮小：

backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

答：您應該將備份資料庫變更為備份記錄檔陳述式。另外，您也可以使資料庫成為簡單修復模式，並發出 shrinkfile 陳述式。在完成記錄檔縮小之後，將資料庫設為其先前的修復模式並備份資料庫。如果它仍未縮小，請檢查並確定您沒有開啟的交易 (使用 dbcc opentran)。下列知識庫文章提供詳細資訊：support.microsoft.com/kb/907511。

問：如果在排定的 SQL Server Agent 作業期間發生容錯移轉，在容錯移轉之後，該作業會發生什麼情況？我需要手動重新啟動它嗎？

答：是的，如果您沒有備妥一些其他程序，就需要手動啟動它。如果您不想要手動重新啟動作業，則可撰寫指令碼於作業完成時更新資料表。如果值 = 1，表示已執行作業；其他值表示作業未完成，且稍後會有第二個作業，以發出啟動命令。因此，如果作業執行期間發生容錯移轉，您就必須重新執行該作業，但是藉由撰寫指令碼，就可以確保那些必須在下一個工作天之前完成的重要作業，能夠有備援的機制。

提示：升級與 DBCC UPDATEUSAGE

您是否要從 SQL Server 2000 升級到 SQL Server 2005？

如果是，請確定您在資料庫升級之後有執行 DBCC UPDATEUSAGE。

DBCC UPDATEUSAGE 會在目錄檢視中報告並更正頁面和資料列計數的錯誤。這些錯誤需要更正，因為它們會造成 sp_spaceused 系統預存程序傳回不正確的空間使用量報告。在 SQL Server 2005 中，一定會正確維護這些值，因此這些資料庫絕對不會發生不正確計數。不過，升級到 SQL Server 2005 的資料庫可能包含無效計數，因此您應該在升級之後執行 DBCC UPDATEUSAGE。

以下是 DBCC UPDATEUSAGE 的運作方式。它會在資料表或索引中更正每一個資料分割的資料列、使用的頁面、保留的頁面、分葉頁面和資料頁計數。如果系統資料表沒有錯誤，DBCC UPDATEUSAGE 就不會傳回資料。如果發現錯誤並予以更正，且您未使用 WITH NO_INFOMSGS，則 DBCC UPDATEUSAGE 會傳回系統資料表中更新的資料列和資料行。

DBCC UPDATEUSAGE 也可以用來同步處理空間使用量計數器。因為 DBCC UPDATEUSAGE 在大型資料表或資料庫上需要多花一點時間，因此通常只有當您懷疑 sp_spaceused 傳回不正確值時才要使用它。請注意，sp_spaceused 可以在傳回資料表或索引的空間資訊之前，接受執行 DBCC UPDATEUSAGE 的可選用參數。

在 SQL Server 2005 中，DBCC CHECKDB 已增強功能，會偵測到頁面或資料列計數何時變為負數。偵測到負數時，DBCC CHECKDB 會發出警告，並建議執行 DBCC UPDATEUSAGE 來解決此問題。雖然看起來是將資料庫升級到 SQL Server 2005 造成此問題，其實是在升級程序進行之前就已經造成無效的計數。

下面的範例將告訴您，如何為目前資料庫中的所有物件更新頁面或資料列計數或是兩者。下列命令指定 0 為資料庫名稱，且 DBCC UPDATEUSAGE 報告目前資料庫的更新資訊：

DBCC UPDATEUSAGE (0);
GO

例如，若要針對 AdventureWorks 更新頁面或資料列計數或是兩者，並隱藏參考訊息，您需要執行類似下面的命令，其中會指定 AdventureWorks 做為資料庫名稱，然後隱藏所有參考訊息：

USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO

如需詳細資訊，請搜尋《SQL Server 線上叢書》的＜DBCC UpdateUsage＞。

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.

其他資源