Share via

使用中次要：可讀取的次要複本 (AlwaysOn 可用性群組)

  • 發行項

AlwaysOn 可用性群組 使用中次要功能包含對一個或多個次要複本進行唯讀存取的支援 (「可讀取的次要複本」(Readable Secondary Replicas))。 可讀取的次要複本允許對其所有次要資料庫進行唯讀存取。 但可讀取的次要資料庫並不會設定為唯讀。 這些資料庫為動態。 隨著對應主要資料庫變更而衍生的給定次要資料庫變更會套用至次要資料庫。 對於一般次要複本而言，次要資料庫中的資料幾近即時。 此外，全文檢索索引會與次要資料庫進行同步處理。 在許多情況下，主要資料庫和對應次要資料庫之間的資料延遲只在幾秒鐘內。

主要資料庫中進行的安全性設定會保存到次要資料庫。 其中包括使用者、資料庫角色和應用程式角色，連同其各自的權限，以及透明資料加密 (TDE) (如果主要資料庫上已啟用)。

[!附註]

雖然您無法將資料寫入次要資料庫，但是您可以寫入裝載次要複本的伺服器執行個體上的讀寫資料庫，包括使用者資料庫和系統資料庫 (例如 tempdb)。

AlwaysOn 可用性群組 也可將讀取意圖的連接要求重新路由到可讀取的次要複本 (「唯讀路由」(Read-Only Routing))。 如需有關唯讀路由的詳細資訊，請參閱＜使用接聽程式連接到唯讀次要複本 (唯讀路由)＞。

本主題內容：

  • 優點

  • 可用性群組的必要條件

  • 限制事項

  • 效能考量

  • 容量規劃考量

  • 相關工作

  • 相關內容

優點

將唯讀連接導向至可讀取的次要複本，具有下列優點：

  • 從主要複本卸載次要唯讀工作負載，將主要複本的資源保留給關鍵任務工作負載使用。 如果您有關鍵任務的讀取工作負載或不能容忍延遲的工作負載，則應該在主要複本上執行此工作負載。

  • 提高裝載可讀取次要複本之系統的投資報酬率。

此外，可讀取的次要複本對唯讀作業提供強大的支援，如下：

  • 可讀取次要複本的暫時統計資料會最佳化唯讀查詢。 如需詳細資訊，請參閱本主題稍後的＜唯讀存取資料庫的統計資料＞。

  • 唯讀工作負載會使用資料列版本設定來移除對於次要資料庫的封鎖競爭。 針對次要資料庫執行的所有查詢都會自動對應到快照集隔離交易層級，即使已明確設定其他交易隔離等級也是如此。 此外，所有鎖定提示都會被忽略。 這排除了讀取器/寫入器競爭。

搭配回到頁首連結使用的箭頭圖示[回到頁首]

可用性群組的必要條件

  • 可讀取的次要複本 (必要)

    資料庫管理員必須設定一個或多個複本，以便在以次要角色執行時，這些複本可以允許所有連接 (僅供唯讀存取) 或只允許讀取意圖的連接。

    [!附註]

    除此之外，資料庫管理員也可選擇在以主要角色執行時，將可用性複本設定為排除唯讀連接。

    如需詳細資訊，請參閱＜關於可用性複本的用戶端連接存取 (SQL Server)＞。

  • 可用性群組接聽程式

    若要支援唯讀路由，可用性群組必須具有可用性群組接聽程式。 唯讀用戶端必須將其連接要求導向至此接聽程式，且用戶端的連接字串必須將應用程式的意圖指定為「唯讀」。換句話說必須是「讀取意圖的連接要求」(Read-Intent Connection Request)。

  • 唯讀路由

    「唯讀路由」(Read-Only Routing) 是 SQL Server 功能，可將導向至可用性群組接聽程式之內送讀取意圖的連接要求，路由至可用之可讀取的次要複本。 唯讀路由的必要條件如下：

    • 若要支援唯讀路由，可讀取的次要複本需要唯讀路由 URL。 只有在本機複本以次要角色執行時，此 URL 才會生效。 如有必要，您必須各自指定每個複本的唯讀路由 URL。 每個唯讀路由 URL 可用於將讀取意圖的連接要求路由至特定可讀取的次要複本。 一般而言，每個可讀取的次要複本皆會獲派一個唯讀路由 URL。

    • 當支援唯讀路由的可用性複本為主要複本時，每一個可用性複本皆需要唯讀路由清單。 只有本機複本以主要角色執行時，給定的唯讀路由清單才會生效。 如有必要，您必須各自指定每個複本的這份清單。 一般而言，每份唯讀路由清單皆會包含每一個唯讀路由 URL，並在清單結尾提供本機複本的 URL。

      [!附註]

      讀取意圖的連接要求會路由至目前之主要複本的唯讀路由清單上，第一個可用之可讀取的次要複本。 沒有負載平衡。

    如需詳細資訊，請參閱＜設定可用性群組的唯讀路由 (SQL Server)＞。

[!附註]

如需有關可用性群組接聽程式和唯讀路由的詳細資訊，請參閱＜可用性群組接聽程式、用戶端連接及應用程式容錯移轉 (SQL Server)＞。

搭配回到頁首連結使用的箭頭圖示[回到頁首]

限制事項

某些作業不完全受到支援，如下：

  • 在可讀取的次要複本聯結可用性群組之後，次要複本立即可以開始接受與其次要資料庫之間的連接。 但是，如果主要複本上有任何使用中交易，對應的次要資料庫上無法立即完全使用資料列版本。 設定次要複本時，主要複本上若有使用中交易，必須認可或回復這些交易。 完成此程序之前，次要資料庫的交易隔離等級對應並不完整，而且查詢會暫時封鎖。

    [!附註]

    執行長時間交易會影響保存的版本資料列數目。

  • 在屬於可讀取次要複本的次要資料庫上，不支援變更追蹤和異動資料擷取：

    • 次要資料庫上已明確停用變更追蹤。

    • 次要資料庫上可以啟用異動資料擷取，但是這不受支援。

  • 由於讀取作業會對應至快照集隔離交易層級，因此一個或多個次要複本上的交易會封鎖在主要複本上的準刪除記錄清除。 當任何次要複本不再需要準刪除記錄時，準刪除記錄清除工作會自動清除主要複本上的準刪除記錄。 這類似於在主要複本上執行交易時所完成的作業。 在次要資料庫的極端案例，您需要終止長時間執行、封鎖準刪除清除的讀取查詢。 請注意，如果次要複本中斷連接或在次要資料庫上的資料移動暫停時，可能會封鎖準刪除清除。 這種狀態也會防止記錄截斷，因此如果此狀態持續發生，建議您從可用性群組中移除此次要資料庫。

  • 若檔案包含了次要複本所需要的準刪除記錄，則主要複本的 DBCC SHRINKFILE 作業可能會失敗。

[!附註]

對裝載可讀取之次要複本的伺服器執行個體上查詢 sys.dm_db_index_physical_stats 動態管理檢視時，可能會發生 REDO 封鎖問題。 這是因為此動態管理檢視會取得指定使用者資料表或檢視的 IS 鎖定，並因此而封鎖了對該使用者資料表或檢視之 X 鎖定的 REDO 執行緒要求。

搭配回到頁首連結使用的箭頭圖示[回到頁首]

效能考量

本節討論可讀取次要資料庫的數項效能考量。

本節內容：

  • 資料延遲

  • 唯讀工作負載的影響

  • 索引

  • 唯讀存取資料庫的統計資料

資料延遲

如果您的唯讀工作負載可以容忍某些資料延遲時，實作次要複本的唯讀存取會很有用。 在無法接受資料延遲的狀況下，請考慮針對主要複本執行唯讀工作負載。

主要複本上會將主要資料庫變更的記錄檔記錄傳送到次要複本。 在每個次要資料庫上，專用的重做執行緒會套用記錄檔記錄。 在讀取存取的次要資料庫上，給定資料變更不會出現在查詢結果，除非包含變更的記錄檔記錄已套用至次要資料庫，而且已經在主要資料庫認可交易。

這表示，主要複本和次要複本之間會有一些延遲 (通常只有幾秒鐘)。 但在很少見的情況下 (例如網路問題減少輸送量的狀況下)，延遲可能會比較長。 在發生 I/O 瓶頸和資料移動暫停時，會增加延遲。 若要監視暫停的資料移動，您可以使用 AlwaysOn 儀表板或 sys.dm_hadr_database_replica_states 動態管理檢視。

唯讀工作負載的影響

將次要複本設定為唯讀存取時，次要資料庫上的唯讀工作負載會耗用系統資源 (例如重做執行緒的 CPU 和 I/O)，特別是當唯讀工作負載高度密集使用 I/O 時。

此外，次要複本上的唯讀工作負載可以封鎖透過記錄檔記錄套用的資料定義語言 (DDL) 變更。 雖然讀取作業因為資料列版本設定的緣故而不會取得共用鎖定，但是這些作業會取得結構描述穩定性 (Sch-S) 鎖定，而這些鎖定可能會封鎖套用 DDL 變更的重做作業。

請查明建立查詢的最佳作法，並在次要資料庫中執行這些最佳作法。 例如，將長時間執行的查詢 (如資料彙總) 安排在活動較少的期間執行。

[!附註]

如果重做執行緒遭到次要複本上的查詢封鎖，便會引發 sqlserver.lock_redo_blocked XEvent。

索引

若要將可讀取次要複本上的唯讀工作負載最佳化，您可能會想要在次要資料庫的資料表上建立索引。 因為您無法在次要資料庫上進行結構描述或資料變更，所以請在主要資料庫中建立索引，並允許透過重做處理序將變更傳送到次要資料庫。

若要監視次要複本的索引使用活動，請查詢 sys.dm_db_index_usage_stats 動態管理檢視的 user_seeks、user_scans 和 user_lookups 資料行。

唯讀存取資料庫的統計資料

資料表資料行和索引檢視表的統計資料可用來最佳化查詢計畫。 對於可用性群組而言，在主要資料庫上建立和維護的統計資料會自動保存至次要資料庫，做為交易記錄檔記錄應用的一部分。 但是，次要資料庫上的唯讀工作負載所需的統計資料可能與主要資料庫上所建立的統計資料不同。 但是，因為次要資料庫受限為唯讀存取，所以無法在次要資料庫上建立統計資料。

為了解決此問題，次要複本會在 tempdb 中建立及維護次要資料庫的暫時統計資料。 暫時統計資料名稱會附加後置詞 _readonly_database_statistic，以便區分暫時統計資料與主要資料庫中保存的永久統計資料。

只有 SQL Server 可以建立和更新暫時統計資料。 但是，您可以使用永久統計資料所使用的相同工具來刪除暫時統計資料及監控其屬性：

  • 使用 DROP STATISTICS Transact-SQL 陳述式刪除暫時統計資料。

  • 使用 sys.stats 和 sys.stats_columns 目錄檢視監控統計資料。 sys_stats 包含 is_temporary 資料行，以指示哪些統計資料為永久性及哪些統計資料為暫時性。

如需有關 SQL Server 統計資料的詳細資訊，請參閱＜統計資料＞。

本節內容：

  • 次要資料庫上過時的永久統計資料

  • 限制事項

次要資料庫上過時的永久統計資料

SQL Server 會偵測次要資料庫上的永久統計資料何時過時。 但除了對主要資料庫所做的變更以外，無法對永久統計資料進行變更。 為達到查詢最佳化，SQL Server 會在次要資料庫上建立暫時統計資料，並且使用這些統計資料以取代過時的永久統計資料。

在主要資料庫上更新永久統計資料時，這些統計資料會自動保存至次要資料庫。 然後 SQL Server 會使用更新的永久統計資資料 (比暫時統計資料還要新)。

如果可用性群組容錯移轉，所有次要複本上的暫時統計資料都會被刪除。

限制事項

  • 因為暫時統計資料會儲存在 tempdb 中，所以重新啟動 SQL Server 服務會導致所有暫時統計資料消失。

  • 後置詞 _readonly_database_statistic 會保留給 SQL Server 產生的統計資料使用。 當您在主要資料庫上建立統計資料時，將無法使用這個後置詞。 如需詳細資訊，請參閱＜統計資料＞。

搭配回到頁首連結使用的箭頭圖示[回到頁首]

容量規劃考量

  • 出於以下兩個原因，可讀取的次要複本可能需要 tempdb 的空間：

    • 快照集隔離等級會將資料列版本複製到 tempdb 中。

    • 在 tempdb 中建立和維護次要資料庫的暫時統計資料。 暫時統計資料會導致 tempdb 略微增大。 如需詳細資訊，請參閱本節稍後的＜唯讀存取資料庫的統計資料＞。

  • 當您設定一個或多個次要複本的讀取權時，主要資料庫會在已刪除、修改或插入的資料列上增加 14 個位元組的負擔，以便在次要資料庫上儲存資料列版本的指標。 此 14 個位元組的負擔會轉至次要資料庫。 將 14 個位元組的負擔增加到資料列時，可能會發生頁面分割。

    主要資料庫不會產生資料列版本資料， 而是由次要資料庫產生資料列版本。 不過，資料列版本設定會同時增加主要和次要資料庫的資料儲存量。

    系統是否新增資料列版本資料，取決於主要資料庫的快照集隔離或讀取認可快照集隔離 (RCSI) 等級設定。 下表描述在不同設定下可讀取次要資料庫的版本設定行為。

    可讀取的次要複本？

    已啟用快照集隔離或 RCSI 等級？

    主要資料庫

    次要資料庫

    否

    否

    沒有資料列版本或 14 個位元組的負擔

    沒有資料列版本或 14 個位元組的負擔

    否

    是

    有資料列版本和 14 個位元組的負擔

    沒有資料列版本，但有 14 個位元組的負擔

    是

    否

    沒有資料列版本，但有 14 個位元組的負擔

    有資料列版本和 14 個位元組的負擔

    是

    是

    有資料列版本和 14 個位元組的負擔

    有資料列版本和 14 個位元組的負擔

搭配回到頁首連結使用的箭頭圖示[回到頁首]

相關工作

搭配回到頁首連結使用的箭頭圖示[回到頁首]

相關內容

搭配回到頁首連結使用的箭頭圖示[回到頁首]

請參閱

概念

AlwaysOn 可用性群組概觀 (SQL Server)

關於可用性複本的用戶端連接存取 (SQL Server)

可用性群組接聽程式、用戶端連接及應用程式容錯移轉 (SQL Server)

統計資料