[AlwaysOn2017] AlwaysOn的DMV和DMF - Sys.dm_hadr_database_replica_states
為其返回AlwaysOn可用性組中的參與每個資料庫的行的本地例項SQL Server正承載其可用性副本。此動態管理檢視公開與主副本和輔助副本有關的狀態資訊。在輔助副本上,此檢視為伺服器例項上的每個輔助資料庫都返回一行。在主副本上,此檢視為每個主資料庫都返回一行,並且為相應的輔助資料庫另外返回一行。
重要
根據操作和更高階別的狀態,資料庫狀態資訊可能不可用或過期。此外,這些值僅具有本地相關性。例如,在主副本的值 last_hardened_lsn 列反映到主副本當前可用的給定輔助資料庫有關的資訊,不實際強制寫入的LSN值輔助副本當前可能具有。
列名 |
資料型別 |
說明(針對主副本) |
database_id |
int |
資料庫的識別符號,在SQL Server的例項內是唯一的。這是相同的值中所示 目錄檢視。 |
group_id |
uniqueidentifier |
資料庫所屬的可用性組的識別符號。 |
replica_id |
uniqueidentifier |
可用性組內可用性副本的識別符號。 |
group_database_id |
uniqueidentifier |
可用性組內資料庫的識別符號。在此資料庫聯接到的每個副本上,該識別符號都是相同的。 |
is_local |
bit |
可用性資料庫是否是本地的,可以是下列值之一: 0 = 資料庫對於SQL Server例項而言不是本地的。 1 = 資料庫對於伺服器例項而言是本地的。 |
is_primary_replica |
bit |
如果副本是主要副本則返回1;如果副本是輔助副本則返回0。 適用範圍:SQL Server 2014(12.x)到SQL Server 2017。 |
synchronization_state synchronization_state_desc |
tinyint
nvarchar(60) |
資料移動狀態,以下值之一。 0 = NOT SYNCHRONIZING 未同步。 1 = SYNCHRONIZING 正在同步。 2 = SYNCHRONIZED 已同步。 3 = REVERTING 恢復。 4 = INITIALIZING 正在初始化。 |
is_commit_participant |
bit |
0 = 就此資料庫而言,事務提交未同步。 1 = 就此資料庫而言,事務提交同步。 對於非同步提交可用性副本上的資料庫,該值始終為0。 對於同步提交可用性副本上的資料庫,該值僅在主資料庫上是準確的。 |
synchronization_health synchronization_health_desc |
tinyint
nvarchar(60) |
反映聯接到可用性副本上的可用性組的資料庫的同步狀態和可用性副本(同步提交或非同步提交模式)之一的可用性模式的交集以下值。 0 = NOT_HEALTHY 不正常。資料庫 Synchronization_state是0(NOT SYNCHRONIZING)。
1 = PARTIALLY_HEALTHY 不完全正常。如果同步提交可用性副本上的資料庫 synchronization_state為1(SYNCHRONIZING)被視為完全正常。 2 = HEALTHY 正常。如果同步提交可用性副本上的資料庫 synchronization_state為2(SYNCHRONIZED)和非同步提交可用性副本上的資料庫 synchronization_state為1(SYNCHRONIZING)被視為正常。 |
database_state database_state_desc |
tinyint nvarchar(60) |
0 = ONLINE 聯機 1 = RESTORING 正在還原 2 = RECOVERING 正在恢復 3 = RECOVERY_PENDING 恢復掛起 4 = SUSPECT 可疑 5 = EMERGENCY 緊急 6 = OFFLINE 離線 注意: 與Sys.databases 中的state和 state_desc列相同。 |
is_suspended |
bit |
資料庫狀態,可以是下列值之一: 0 = 已恢復 1 = 已掛起 |
suspend_reason suspend_reason_desc |
tinyint nvarchar(60) |
如果資料庫處於已掛起狀態,則為已掛起狀態的原因,可以是下列值之一: 0 = SUSPEND_FROM_USER = 使用者手動掛起的收據移動 1 = SUSPEND_FROM_PARTNER = 在強制故障轉移後掛起資料庫副本/掛起來自夥伴 2 = SUSPEND_FROM_REDO = 在重做階段中出錯 3 = SUSPEND_FROM_CAPTURE = 在捕獲主副本上的日誌時出錯 4 = SUSPEND_FROM_APPLY = 在將日誌寫入檔案時出錯(請參閱錯誤日誌) 5 = SUSPEND_FROM_RESTART = 在重新啟動資料庫前掛起資料庫副本(請參閱錯誤日誌) 6 = SUSPEND_FROM_UNDO = 在撤消階段中出錯(請參閱錯誤日誌) 7 = 重新驗證 8 = 計算輔助副本同步點時出錯 SUSPEND_FROM_REVALIDATION = 在重新連線時檢測到了日誌更改不匹配(請參閱錯誤日誌) SUSPEND_FROM_XRF_UPDATE = 找不到公共日誌點(請參閱錯誤日誌) |
recovery_lsn |
numeric(25,0) |
在主副本上,在恢復或故障轉移之後、在主資料庫寫入任何新日誌記錄之前事務日誌的結尾。對於給定的輔助資料庫,如果該值小於當前硬化的LSN (last_hardened_lsn),則recovery_lsn是此輔助資料庫需要重新同步的值(即要恢復到和重新初始化的值)。如果該值大於或等於當前硬化LSN,重新同步將沒有必要且不會發生。 recovery_lsn 反映了用零填充的日誌塊ID。它不是實際的日誌序列號(LSN)。有關如何派生此值的資訊,請參閱 ,本主題中更高版本。 |
truncation_lsn |
numeric(25,0) |
在主副本上,對於主資料庫,反映了所有相應輔助資料庫中的最小日誌截斷LSN。如果阻止本地日誌截斷(例如由備份操作阻止),則該LSN可能高於本地截斷LSN。 對於給定的輔助資料庫,反映了該資料庫的截斷點。 truncation_lsn 反映了用零填充的日誌塊ID。它不是實際的日誌序列號。 |
last_sent_lsn |
numeric(25,0) |
指示一個點(在該點前的所有日誌塊都已由主資料庫傳送)的日誌塊識別符號。該識別符號是將傳送的下一日誌塊的ID,而非最近傳送的日誌塊的ID。 last_sent_lsn 反映了日誌塊ID用零填充,它不是實際的日誌序列號。 |
last_sent_time |
datetime |
傳送最後一個日誌塊的時間。 |
last_received_lsn |
numeric(25,0) |
標識一個點的日誌塊ID,在該點之前,所有日誌塊都已由承載此輔助資料庫的輔助副本接收。 last_received_lsn 反映了用零填充的日誌塊ID。它不是實際的日誌序列號。 |
last_received_time |
datetime |
在輔助副本上讀取最後接收的訊息中的日誌塊ID的時間。 |
last_hardened_lsn |
numeric(25,0) |
包含輔助資料庫上最後強制寫入的LSN的日誌記錄的日誌塊開頭。 在非同步提交主資料庫上或其當前策略為“延遲”的同步提交資料庫上,該值為NULL。對於其他同步提交主資料庫, last_hardened_lsn指示所有輔助資料庫中的強制的LSN的最小值。 注意:last_hardened_lsn 反映了用零填充的日誌塊 ID。它不是實際的日誌序列號。有關詳細資訊,請參閱 ,本主題中更高版本。 |
last_hardened_time |
datetime |
輔助資料庫上最後一個日誌塊識別符號的時間強制寫入的LSN( last_hardened_lsn)。在主資料庫上,反映了與最小強制寫入的LSN相對應的時間。 |
last_redone_lsn |
numeric(25,0) |
在輔助資料庫上重做的上一個日誌記錄的實際日誌序列號。 last_redone_lsn是始終小於 last_hardened_lsn。 |
last_redone_time |
datetime |
在輔助資料庫上重做最後一個日誌記錄的時間。 |
log_send_queue_size |
bigint |
主資料庫中尚未傳送到輔助資料庫的日誌記錄量(KB)。 |
log_send_rate |
bigint |
在最後一個活動期間,以千位元組(KB)的平均主副本傳送例項資料的速率/秒。 |
redo_queue_size |
bigint |
輔助副本的日誌檔案中尚未重做的日誌記錄量(KB)。 |
redo_rate |
bigint |
日誌記錄在給定輔助資料庫重做的速率(KB/s)。 |
filestream_send_rate |
bigint |
FILESTREAM 檔案傳送到輔助副本的速率(KB/秒)。 |
end_of_log_lsn |
numeric(25,0) |
日誌LSN的本地結尾。與主資料庫和輔助資料庫上日誌快取中的最後一個日誌記錄相對應的實際LSN。在主副本上,輔助行反映了輔助副本已傳送到主副本的最新進度訊息中日誌LSN的結尾。 end_of_log_lsn 反映了用零填充的日誌塊ID。它不是實際的日誌序列號。有關詳細資訊,請參閱 ,本主題中更高版本。 |
last_commit_lsn |
Numeric(25,0) |
與事務日誌中的最後提交的記錄相對應的實際日誌序列號。 主資料庫上,這對應於上次處理的提交記錄。輔助資料庫的行顯示輔助副本已傳送到主副本的日誌序列號。 在輔助副本上,這是已重做的最後一個提交記錄。 |
last_commit_time |
datetime |
與最後一個提交記錄對應的時間。 在輔助資料庫上,此時間與主資料庫上的時間相同。 在主副本上,每個輔助資料庫行都顯示承載該輔助資料庫的輔助副本報告回主副本的時間。主資料庫行和給定的輔助資料庫行之間的時間差異表示大約恢復點目標(RPO),假定,重做程式並且進度已到主副本返回報告由輔助副本。 |
low_water_mark_for_ghosts |
bigint |
針對資料庫的單調遞增的數字,指示主資料庫上虛影清除使用的低水印。如果這個數字沒有隨著時間的推移而增加,則意味著虛影清除可能未發生。為了確定要清除的虛影行,主副本會在所有可用性副本(包括主副本)上將該列的最小值用於此資料庫。 |
secondary_lag_seconds |
bigint |
在同步期間,輔助副本是主副本的秒數。 適用範圍:SQL Server 2016(13.x)到SQL Server 2017。 |
瞭解LSN列值
end_of_log_lsn , last_hardened_lsn , last_received_lsn , last_sent_lsn , recovery _lsn ,並 truncation_lsn 列的值不是實際的日誌序列號(Lsn)。上述各值反映了用零填充的日誌塊ID。
end_of_log_lsn , last_hardened_lsn ,和 recovery_lsn 是重新整理Lsn。例如, last_hardened_lsn 指示越過已位於磁碟的塊的下一個塊的開頭。因此任何LSN<的值 last_hardened_lsn 磁碟上。LSN,它是>=此值將不會重新整理。
返回的LSN值 Sys.dm_hadr_database_replica_states ,則只 last_redone_lsn 是真實的LSN。
當前例項下所有可用性資料庫的狀態資訊表
synchronization_state 和synchronization_state_desc
值 |
說明 |
0 |
NOT SYNCHRONIZING 未同步。 l 對於某一主資料庫,指示該資料庫未做好將其事務日誌與相應的輔助資料庫同步的準備。 l 對於輔助資料庫,指示資料庫由於連線問題而未開始日誌同步,正被掛起,或者在啟動或角色切換過程中正在轉換狀態。 |
1 |
SYNCHRONIZING 正在同步。 l 對於主資料庫,指示此資料庫已做好接受來自輔助資料庫的掃描請求的準備。 l 對於輔助資料庫,指示對於該資料庫正在發生活動資料移動。 |
2 |
已同步。 l 主資料庫顯示SYNCHRONIZED來代替SYNCHRONIZING。 l 同步提交輔助資料庫在以下情況下將顯示已同步:本地快取指示資料庫副本可供故障轉移並且資料庫正在同步。 |
3 |
REVERTING 正在恢復。指示撤消程式中輔助資料庫主動從主資料庫獲取頁時的階段。 注意 :當輔助副本上的資料庫處於REVERTING狀態時,強制故障轉移到輔助副本將使資料庫處於該資料庫不能作為主資料庫啟動的狀態。該資料庫將需要作為輔助資料庫重新連線,或者您需要應用來自日誌備份的新日誌記錄。 |
4 |
INITIALIZING 正在初始化。指示在正在輔助副本上傳送和強制寫入輔助資料庫跟上撤消LSN所需的事務日誌時的撤消階段。 注意 :當輔助副本上的資料庫處於INITIALIZING狀態時,強制故障轉移到輔助副本將使資料庫處於該資料庫可作為主資料庫啟動的狀態。該資料庫將需要作為輔助資料庫重新連線,或者您需要應用來自日誌備份的新日誌記錄。 |
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/81227/viewspace-2656180/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- [AlwaysOn2017] AlwaysOn的DMV和DMF - Sys.availability_replicasAI
- [AlwaysOn2017] AlwaysOn的DMV和DMF - Sys.dm_tcp_listener_statesTCP
- [AlwaysOn2017] AlwaysOn的DMV和DMF - Sys.availability_groupsAI
- [AlwaysOn2017] AlwaysOn的DMV和DMF - Sys.availability_group_listenersAI
- [AlwaysOn2017] AlwaysOn的DMV和DMF -sys.availability_databases_clusterAIDatabase
- [AlwaysOn2017] AlwaysOn的DMV和DMF - Sys.availability_groups_clusterAI
- [AlwaysOn2017] AlwaysOn的DMV和DMF - Sys.dm_hadr_auto_page_repairAI
- [AlwaysOn2017] AlwaysOn的DMV和DMF - Sys.dm_hadr_availability_group_statesAI
- [AlwaysOn2017] AlwaysOn的DMV和DMF - Sys.dm_hadr_availability_replica_statesAI
- [AlwaysOn2017] AlwaysOn的DMV和DMF - Sys.dm_hadr_database_replica_cluster_statesDatabase
- [AlwaysOn2017] AlwaysOn的DMV和DMF - Sys.fn_hadr_distributed_ag_database_replicaDatabase
- [AlwaysOn2017] AlwaysOn的DMV和DMF - Sys.availability_read_only_routing_listsAI
- [AlwaysOn2017] AlwaysOn的DMV和DMF-Sys.dm_hadr_availability_replica_cluster_nodesAI
- [AlwaysOn2017] AlwaysOn的DMV和DMF -Sys.availability_group_listener_ip_addressesAI
- [AlwaysOn2017] AlwaysOn的DMV - Sys.dm_hadr_availability_replica_cluster_statesAI
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 3模式
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 6模式
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 5模式
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 4模式
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 2模式
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 1模式
- [AlwaysOn] AlwaysOn可用性組的可用性模式之間的差異模式
- 透過DMV查詢CPU時間最長的語句和查詢計劃
- SQL Server AlwaysOn搭建SQLServer
- 如何遷移Alwayson AG
- [AlwaysOn] 建立SQL Server AlwaysOn高可用性組T-SQL語法SQLServer
- SQL Server AlwaysOn的Oracle等價技術SQLServerOracle
- 六、CPU優化(6)DMV與計數器優化
- SQL Server Alwayson概念總結SQLServer
- 丐版sqlserver AlwaysOn叢集SQLServer
- DMV:2019年4月蘋果自動駕駛汽車和司機數量減少蘋果自動駕駛
- Sqlserver重啟alwayson監聽埠SQLServer
- DBA工具——DMV——如何知道TSQL語句已執行了多久SQL
- SQL Server AlwaysOn讀寫分離配置SQLServer
- SQL Server 修改AlwaysOn共享網路位置SQLServer
- 談SQL Server 2012 AlwaysOnSQLServer
- 獨家揭祕:SQL Server AlwaysOn在阿里雲的突破SQLServer阿里
- 安裝SQL Server 2012的AlwaysOn叢集SQLServer