ITPub博客

首页 > 数据库 > SQL Server > [AlwaysOn2017] AlwaysOn的DMV和DMF - Sys.dm_hadr_database_replica_states

[AlwaysOn2017] AlwaysOn的DMV和DMF - Sys.dm_hadr_database_replica_states

原创 SQL Server 作者:cow977 时间:2019-09-05 21:25:44 0 删除 编辑

18、 Sys. dm_hadr_database_replica_states


为其返回AlwaysOn可用性组中的参与每个数据库的行的本地实例SQL Server正承载其可用性副本。此动态管理视图公开与主副本和辅助副本有关的状态信息。在辅助副本上,此视图为服务器实例上的每个辅助数据库都返回一行。在主副本上,此视图为每个主数据库都返回一行,并且为相应的辅助数据库另外返回一行。

重要

根据操作和更高级别的状态,数据库状态信息可能不可用或过期。此外,这些值仅具有本地相关性。例如,在主副本的值 last_hardened_lsn 列反映到主副本当前可用的给定辅助数据库有关的信息,不实际强制写入的LSN值辅助副本当前可能具有。

列名

数据类型

说明(针对主副本)

database_id

int

数据库的标识符,在SQL Server的实例内是唯一的。这是相同的值中所示 Sys.databases目录视图。

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)。有关如何派生此值的信息,请参阅 了解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。它不是实际的日志序列号。有关详细信息,请参阅 了解LSN列值,本主题中更高版本。

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。它不是实际的日志序列号。有关详细信息,请参阅 了解LSN列值,本主题中更高版本。

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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2011-03-02

  • 博文量
    689
  • 访问量
    739804