第七十九期儿童节惊魂

6月第一天，又是儿童节，加上客户现场来了不少娃，也有一些客户家里有娃去参加活动了，所以整体的氛围是十分轻松惬意的。然鹅，一通电话打破了这一份来之不易的平静。

1 主板挂了？

这是我们公司另一个地方的项目，之前我跑的前期沟通和部分数据库环境的搭建工作，虽然2年多没去过难了，但是整体来说那边的客户对我的感官还蛮好的（当然中间还是远程处理过故障滴）。今天这通电话就是那边项目经理打来，原来是那边X8M的一个计算节点莫名其妙的挂了，操作系统没起起来，随即远程过去看。
首先，挂掉的节点ilom还能登上去，过去就发现一些问题：
在这里插入图片描述
通过show /System/Open_problems命令可以看到MB（主板）和P0、P1（CPU）都有报错，两个CPU同时坏的的可能性很低，因此这里大概率是主板有问题。紧接着通过show faulty命令查看详细信息（内容有点多这里就不展示了），发现是异常重启后主板无法加电。
根据一般的标准解决方案，是先清理告警再尝试重启，不行再说换硬件的事情，下面是在ilom中如何清理告警：

start /SP/faultmgmt/shell/ #进入故障管理工具后台
faultmgmtsp>
	fmadm faulty #查询所有告警
	fmadm repaire fault_UUID #这里需要通过执行清理上面所有告警的UUID
	exit
reset /SP/ #重启节点

这里断电重启节点之后操作系统仍然没起起来，faulty倒是没有再次生成，机房管理也终于到了机房，发现这个计算节点只有ilom灯亮了，其余的系统灯、硬盘灯一个没亮，主板还是没有加电。硬件维保厂商也上线了，说可能需要拔电源线并等待放电一段时间后重启，由于机房管理不敢操作，只能等待硬件维保厂商人员到场。到了中午，硬件维保厂商工程师进入了机房，拔电放电重启后，操作系统果然起来了，接着就是他们检查下硬件收收日志回头看看到底发生了啥。
你以为这就完了？还早呢，现场数据库维护发现节点数据库没起起来，因此在我午觉的时候又把我吵醒了远程去查看。

2 时间同步

通过crsctl check crs检查，发现Cluster Ready Services没起起来，用下面命令尝试重启crs并监控日志：

su - root
/u01/app/19.0.0.0/grid/bin/crsctl stop crs -f
/u01/app/19.0.0.0/grid/bin/crsctl start crs
tail -f /u01/app/grid/diag/crs/HOSTNAME/crs/alert/log.xml

在查看日志的过程中发现是两个计算节点的时间差距很大造成CRS启动失败。检查时间同步服务，发现出其余节点（计算和存储节点）都是通过出故障这个节点进行时间同步，而这个节点又是通过外部时间同步服务器进行时间同步，然而以前配置的时间同步服务器（自建的）已经回收，现在改用硬件时间同步设备，因此将两个计算节点全部调整至外部硬件时钟设备，存储节点由于网络问题设置到两个计算节点同步时间。
处理完成后再次：

su - root
/u01/app/19.0.0.0/grid/bin/crsctl stop crs -f
/u01/app/19.0.0.0/grid/bin/crsctl start crs

这里CRS就起起来了，然鹅还是有问题。

3 数据库参数

CRS起起来了，但是ACFS和DB没有起来，ACFS放在后面，毕竟只用于做部分重要表的离线备份，DB才是最重要的。

startup nomount
alter database mount;
-- 结果出现了以下报错
ORA-01105: mount is incompatible with mounts by other instances
ORA-01677: standby file name convert parameters differ from other instance

检查节点参数发现：

--节点2（正常节点）：
SQL> show parameter file_name_convert

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert                 string
log_file_name_convert                string
pdb_file_name_convert                string

--节点1（故障节点）：
SQL> show parameter file_name_convert

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert                 string      'dbdg','db'
log_file_name_convert                string      'dbdg','db'
pdb_file_name_convert                string

create pfile='/home/oracle/initdb0601.ora' from spfile;

检查spfile内容发现db_file_name_convert和log_file_name_convert参数都是配置过的，这就很奇怪了，运行实例为啥值为空，只能判断为前任DBA做了配置，但是没有重启数据库，也因此造成了这次实例无法启动。（其实数据库配置了OMF，在ADG环境是不需要配置convert参数的，这套ADG我以前搭的时候是没有配置这两个参数，但是有些DBA总觉得这个参数是必须的）。

alter system reset db_file_name_convert scope=spfile sid='*';
alter system reset log_file_name_convert scope=spfile sid='*';

shut immediate
startup --这里就能正常启动了

--不要尝试直接将db_file_name_convert和log_file_name_convert直接设为空：
alter system set db_file_name_convert='' scope=spfile sid='*';

ORA-01678: parameter string must be pairs of pattern and replacement strings
--convert参数必须是每两个为一组一一对应的

4 ACFS

本来ACFS起不起来都不是啥大事，但是奈何业务需要对重要表进行离线备份，再说了日常巡检挂着看着也不舒服。经过基本检查发现ACFS模块没有启动起来，因此需要启动，但是出现了以下的问题：

su -
/u01/app/19.0.0.0/grid/bin/acfsload start
sh: -c: line 0: unexpected EOF while Looking for maching ``'
sh: -c: line 1: syntax error: unexpected end of file

这个报错就有点莫名其妙了，结合之前通过主机名ping节点的一些异常（这里通过我的虚拟机做了个模拟展示）：
在这里插入图片描述
让我隐约感觉到这个/etc/host.conf中有些异常，进去一看果然发现里面有一行reorder hosts,bind，也是报错的内容，注释掉之后再次启动acfs模块：

su -
/u01/app/19.0.0.0/grid/bin/acfsload start
#这次是正常启动了

当然到这里还没完：

su - grid
srvctl start asm -proxy #启动ora.proxy_advm
asmcmd volenable -G DATAC1 ACFSVOL01 #启动ACFS卷

su -
mount.acfs -o all #挂载所有ACFS卷

没有报错，ACFS也正常挂载。至此，故障处理完成，当然还是要等硬件侧的日志分析。

5 两个错误

这件事情中有两个很奇怪的问题，第一个就是修改了需要重启生效的参数但没有重启数据库，这个我可以判定为前任DBA的疏忽，但是总归是不专业的表现。
第二个则是/etc/host.conf中配置的问题，可能有人觉得是不是配错了，这里我给大家一个配置文件的原始截图：
在这里插入图片描述
（这里的multi on是因为要不通过DNS配置IPv4和IPv6双栈运行，是专门开SR咨询过是可以修改的）
而reorder这行也是专门写了不要进行修改。翻看Linux的相关文档：

这个参数的值只允许为on和off，加上配置文件详细写明了不要更改内容。前任DBA也是有OCM的人，这两件事情加在一起不得不让我怀疑这是不是故意的。