#巡检
巡检在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_test
ALTER 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介入修复故障。
处理该故障的推荐方案如下：
- 查看故障备库是否可以重新启动或者修复，如果可以，请尽快启动或者修复。
- 根据需要，可以考虑修改配置参数 QUORUM_SYNC_STANDBYS 和 REQUIRED_SYNC_STANDBYS。
- 根据需要，可以考虑修改主库的保护模式。
出现该故障的处理流程：
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 状态。例如：
归档空间不足，数据库状态被置为ABNORMAL，DBA 释放磁盘空间，数据库会自动消除ABNORMAL状态，用户可以继续执行业务。
最大保护模式下，同步备库长时间异常，数据库状态被置为 ABNORMAL， DBA 重启同步备库或者是其他的修复方案，数据库检测到修复完成，会自动消除ABNORMAL 状态，无需手动消除，用户可以继续执行业务。
下载文档
复制链接