巡检在 YashanDB 中为一个单独的后台线程，该线程类似于巡逻小队，不断地监控数据库的运行状况。当发生严重错误时，收集诊断数据存储在自动诊断存储库中，并且触发相应的修复手段或者限制损坏及中断。 巡检主要包含如下内容：
监控数据库文件
发生严重错误时触发健康检查
监控同步备库（最大保护模式）
#文件监控
YashanDB 的后台文件都存储着重要的信息，部分文件丢失可能导致数据库无法正常使用。此外，用户不可以手动改动数据库的文件，如数据文件被改动可能造成各种影响，系统需要对此及时响应避免造成更大的损坏及中断，共享集群模式下该功能禁用。
文件监控的范围
控制文件、数据文件、redo 文件，如果开启双写也将监控双写文件。
文件监控的异常操作
文件元数据的变动：文件权限、文件用户及用户组以及时间戳等。
文件被删除：文件直接被删除，例如：rm 命令等。
文件名被修改或者文件被移动：文件名称被修改或者修改文件的路径，例如：mv 命令等。
文件系统被卸载：文件所在的磁盘被卸载或者时磁盘损坏无法装载。
异常响应
检测到数据库文件存在异常时，触发事件警报，收集事件诊断数据，并且触发反应式健康检查，将诊断数据存储在自动诊断存储库中。
故障处理
出现数据文件、redo 文件被删除或者被移动等操作时，系统将数据库的状态置为 ABNORMAL，数据库处于只读状态，用户执行业务报错，等待 DBA 介入修复故障。
下面以数据文件 hm_test 丢失时，文件监控的诊断数据为例：
-- 事件警报，通过V$DIAG_INCIDENT查看，输出信息如下
SELECT incident_id, session_id, error_number, error_argument, error_comments FROM V$DIAG_INCIDENT; INCIDENT_ID SESSION_ID ERROR_NUMBER ERROR_ARGUMENT ERROR_COMMENTS ------------ ------------ ------------ ----------------- ---------------------------------------------------------------- 11 12 107 data file [MONITOR] /data/yashan/dbdata/dbfiles/hm_test does not exist and may have been deleted 12 12 108 data file [MONITOR] /data/yashan/dbdata/dbfiles/hm_test was deleted -- 反应式健康检查，输出信息如下SELECT run_id, name, check_name, run_mode FROM V$HM_RUN; RUN_ID NAME CHECK_NAME RUN_MODE ------- ------------- ------------------------------------- --------- 51 hm_run_51 DB Structure Integrity Check REACTIVE
SELECT finding_id, description FROM V$HM_FINDING WHERE run_id = 51; FINDING_ID DESCRIPTION ------------ ---------------------------------------------------------------- 21 datafile /data/yashan/dbdata/dbfiles/hm_test is missing
复制代码
数据文件丢失，数据库状态变为 ABNORMAL，用户无法执行业务。
SELECT status FROM V$DATABASE;STATUS --------------------------------- ABNORMAL
-- 执行业务报错CREATE TABLE student_no(ID INT);YAS-06023 database is set to read-only because of database abnormal
-- 查询正常SELECT * FROM DUAL;DUMMY ----- X
复制代码
Note： 数据库的状态变为 ABNORMAL 时，DBA 需要及时处理，避免用户业务一直等待。
数据文件丢失，数据库有可能异常退出，需要 DBA 及时响应。
数据文件丢失，DBA 可以考虑是否 offline 该文件或者对该文件所在表空间进行离线修复，消除故障状态以使用户继续执行业务，也可以使用其他的处理策略。 以 offline 该文件所在表空间为例进行修复：
-- 消除故障状态ALTER DATABASE CONVERT TO NORMAL;
SELECT status FROM V$DATABASE;STATUS --------------------------------- NORMAL
-- offline 该文件所在表空间hm_testALTER TABLESPACE hm_test OFFLINE IMMEDIATE;
-- 用户继续执行业务CREATE TABLE student_no(ID INT);
复制代码
Note： 当出现 ABNORMAL 时，请及时查阅告警日志或者是事件视图 V$DIAG_INCIDENT 查看数据库 ABNORMAL 的诊断数据。
出现 ABNORMAL 时，需要先修复故障再消除故障，但是 offline 表空间数据 DDL 操作，是不可以执行的，所以需要先消除故障状态，再进行 offline 操作。
使用 offline 操作时，应采用 IMMEDIATE 选项，避免数据库出现异常退出的状况。
建议将数据库重启到 mount 阶段后，再执行 offline 数据文件操作，open 阶段执行该操作存在风险，故障有可能会扩散。
健康检查——反应式
反应式健康检查主要是用来排查潜在的故障。当 YashanDB 运行过程中出现某些故障时，会触发相应的健康检查，尽早地检测出潜在的故障，及时处理避免造成损坏。
-- 查询数据发现页面（block 132）损坏SELECT * FROM HM_TEST;YAS-02147 the block 6-0-132 is corrupted
-- 发现页面损坏，巡检线程会触发健康检查（Single Datafile Check）检查该页面所在的整个文件-- 触发反应式健康检查，输出信息如下SELECT run_id, name, check_name, run_mode, status FROM V$HM_RUN;RUN_ID NAME CHECK_NAME RUN_MODE STATUS ------ ----------- ----------------------- --------- ----------- 61 hm_run_61 Single Datafile Check REACTIVE COMPLETED -- 查看健康检查的具体诊断数据SELECT DBMS_HM.GET_RUN_REPORT('HM_RUN_61') FROM DUAL;DBMS_HM.GET_RUN_REPO ---------------------------------------------------------------- Run Name : hm_run_61 Run Id : 61 Check Name : Single Datafile Check Mode : REACTIVE status : COMPLETED Start Time : 2022-07-22 11:51:16 End Time : 2022-07-22 11:51:16 Error Encountered : 0 Source Incident Id : 0 Number of Incidents Created : 0
Input Parameters for the Run DF_NUM=6
Run Findings And Recommendations Finding Finding Name : block corruption Finding ID : 1 Message : block 132 in datafile 6: '/data/yashan/dbdata/dbfiles/hm_test' is corrupted Message : object might be unavailable Finding Finding Name : block corruption Finding ID : 2 Message : block 152 in datafile 6: '/data/yashan/dbdata/dbfiles/hm_test' is corrupted Message : object might be unavailable
复制代码
从以上示例可以发现：当执行业务发现页面损坏时，会触发单个文件的健康检查，不仅检测到页面（block 132）损坏，还发现了潜在的页面（block 152）损坏。
#监控同步备库（最大保护模式）
YashanDB 的高可用架构支持三种保护模式，最大保护模式为其中一种，在最大保护模式下，同步备库与主库断连或者同步备库不可用时，主库用户的业务提交会卡住。
巡检线程检测到同步备库长时间不可用或者是断连状态时，会将数据库的状态设置为 ABNORMAL，后续的业务将不再执行，如果正在提交或者是已经提交的业务会一直卡住，等待 DBA 介入修复故障。
处理该故障的推荐方案如下：
出现该故障的处理流程：
1.执行业务报错，数据库状态为 ABNORMAL。
SELECT status FROM V$DATABASE;STATUS --------------------------------- ABNORMAL
复制代码
2.查阅视图 V$DIAG_INCIDENT 或告警日志。
SELECT incident_id, session_id, error_number, error_comments FROM V$DIAG_INCIDENT;
INCIDENT_ID SESSION_ID ERROR_NUMBER ERROR_COMMENTS ----------- ------------ ------------ ---------------------------------------------------------------- 22 12 211 synchronization standby database destinations have failed, database is set to read-only
复制代码
3.查看视图 V$ARCHIVE_DEST_STATUS。
-- 存在一个断连备库SELECT dest_id, connection, status, database_mode FROM V$ARCHIVE_DEST_STATUS;DEST_ID CONNECTION STATUS DATABASE_MODE ------- ----------------- ----------------- ----------------- 2 CONNECTED NORMAL OPEN 3 DISCONNECTED UNKOWN UNKOWN
复制代码
4.选取修复方案（以重新启动备库为例）。
SELECT dest_id, connection, status, database_mode FROM V$ARCHIVE_DEST_STATUS;DEST_ID CONNECTION STATUS DATABASE_MODE ------- ----------------- ----------------- ----------------- 2 CONNECTED NORMAL OPEN 3 CONNECTED NORMAL OPEN
复制代码
5.DBA 消除故障状态，提交卡住的用户业务提交成功，用户可以继续执行业务。
ALTER DATABASE CONVERT TO NORMAL;
SELECT status FROM V$DATABASE;STATUS --------------------------------- NORMAL
复制代码
Note：
有关最大保护模式的详细信息请查阅高可用相关的文档。
同步备库信息可以查看配置参数 QUORUM_SYNC_STANDBYS 和 REQUIRED_SYNC_STANDBYS 获取更多的信息。
如果故障未修复，直接执行 ALTER DATABASE CONVERT TO NORMAL 消除故障状态的话，数据库会重新将数据库设置为 ABNORMAL 状态，再次记录告警日志和收集诊断数据。
有些故障修复之后数据库会自动消除 ABNORMAL 状态。例如：
评论