orachk检查项目Verify data files are recoverable报警的处理
TFA是OracleRAC安装时自动部署一个工具,它有一套工具集,这些工具对于数据库自身的检测以及系统监测提供了较好的信息审查询功能,但是有时也可能发生一些特殊情况,比如今天我们遇到的问题,报告一个数据文件recover有问题。
系统告警如下(这个告警直接发送到了个人手机上)
Dec 7 02:01:23 RAC1 journal: orachk @cee: {"orachkExecTimestamp":"2020-12-07 02:01:23 CST", "orachkID":"DC223BE507
001B0AE04313C0E50A359D", "orachkExecTime":"", "orachkType":"SQL", "orachkName":"Verify data files are recoverable", "orachkT
argetType":"RDBMS", "orachkStatus":"FAIL", "orachkmessage":"The data files should be recoverable", "orachkMsgDetail":"DATA
FOR mytest19 FOR VERIFY DATA FILES ARE RECOVERABLE\n FILE# UNRECOVER UNRECOVERABLE_CHANGE#
\n---------- --------- --------------------- \n 7 14-OCT-20
2342347 \n 8 14-OCT-20 2711684
\n 10 14-OCT-20 2337970 \n 11 14-OCT-20
2342748 " ,"orachkColumnValues":[ {"Name":"DBName","value":"mytest19"} ] }
根据这个信息,我们在数据库查询v$datafile中记录的文件信息
SQL> select file#,CHECKPOINT_CHANGE#,UNRECOVERABLE_CHANGE#,UNRECOVERABLE_TIME,CREATION_TIME from v$datafile where file#=8;
FILE# CHECKPOINT_CHANGE# UNRECOVERABLE_CHANGE# UNRECOVERABLE_TIME CREATION_TIME
---------- ------------------ --------------------- ------------------- -------------------
8 29265095 2711684 2020-10-14 22:00:15 2020-10-14 16:02:35'
2020-10-14T14:53:01.055027+08:00
alter database archivelog
也就是开启归档后,数据文件中的对象有不可恢复的操作,导致
UNRECOVERABLE_CHANGE# 的出现,如果我们做了个备份,备份了数据文件和归档,这个问题可以忽略,显然这里是数据库开启归档后不久的数据库操作,很可能是初始化数据的操作,一般用户不会恢复到过去那么久 的时间。
tfactl> toolstatus
.------------------------------------------------------------------.
| TOOLS STATUS - HOST : RAC1 |
+----------------------+--------------+--------------+-------------+
| Tool Type | Tool | Version | Status |
+----------------------+--------------+--------------+-------------+
| Development Tools | orachk | 19.3.0.0.0 | DEPLOYED |
| | oratop | 14.1.2 | DEPLOYED |
+----------------------+--------------+--------------+-------------+
| Support Tools Bundle | darda | 2.10.0.R6036 | DEPLOYED |
| | oswbb | 8.3.2 | RUNNING |
| | prw | 12.1.13.11.4 | NOT RUNNING |
+----------------------+--------------+--------------+-------------+
| TFA Utilities | alertsummary | 19.3.0.0.0 | DEPLOYED |
| | calog | 19.3.0.0.0 | DEPLOYED |
| | dbcheck | 18.3.0.0.0 | DEPLOYED |
| | dbglevel | 19.3.0.0.0 | DEPLOYED |
| | grep | 19.3.0.0.0 | DEPLOYED |
| | history | 19.3.0.0.0 | DEPLOYED |
| | ls | 19.3.0.0.0 | DEPLOYED |
| | managelogs | 19.3.0.0.0 | DEPLOYED |
| | menu | 19.3.0.0.0 | DEPLOYED |
| | param | 19.3.0.0.0 | DEPLOYED |
| | ps | 19.3.0.0.0 | DEPLOYED |
| | pstack | 19.3.0.0.0 | DEPLOYED |
| | summary | 19.3.0.0.0 | DEPLOYED |
| | tail | 19.3.0.0.0 | DEPLOYED |
| | triage | 19.3.0.0.0 | DEPLOYED |
| | vi | 19.3.0.0.0 | DEPLOYED |
'----------------------+--------------+--------------+-------------'
关闭TFA组建
tfactl stop
tfactl disable
如果关闭TFA对监控影响比较大,比如oswbb这个监控系统层面资源状况还是很有用的,我们单独关闭orachk这个组件
[root@RAC1 ~]#orachk -autostop
Removing orachk cache discovery....
Successfully completed orachk cache discovery removal.
This version of orachk was released on 29-Apr-2020 and it is older than 180 days. No new version of orachk is available in RAT_UPGRADE_LOC. It is highly recommended that you download the latest version of orachk from my oracle support to ensure the highest level of accuracy of the data contained within the report.
updates.oracle.com is not reachable. Please establish connectivity to updates.oracle.com to download latest version of AHF from MOS patch 30166242 and try again
Running older version...
Removed orachk from inittab
[root@RAC1 ~]#
为了确保安全,我们对数据文件8做备份
另一种方式,对数据文件8作一个备份
RMAN> backup datafile 8;
Starting backup at 2020-12-08 10:52:38
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2 instance=mytest191 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00008 name=/oradata1/mytest19/hypay.dbf
channel ORA_DISK_1: starting piece 1 at 2020-12-08 10:52:39
channel ORA_DISK_1: finished piece 1 at 2020-12-08 10:52:46
piece handle=/oracle/12.2/dbs/04vhi8nn_1_1 tag=TAG20201208T105239 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07
Finished backup at 2020-12-08 10:52:46
Starting Control File and SPFILE Autobackup at 2020-12-08 10:52:46
piece handle=/oracle/12.2/dbs/c-318897591-20201208-00 comment=NONE
Finished Control File and SPFILE Autobackup at 2020-12-08 10:52:47
RMAN> list backup of datafile 8;
之后改问题没有再出现
相关文章