数据库管理-第七十九期 儿童节惊魂(20230601)

第七十九期 儿童节惊魂

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的人,这两件事情加在一起不得不让我怀疑这是不是故意的。

总结

也许是我小人之心度君子之腹了,但是有些事情以前就看破过,说破过,真的不好说了。
本次处理呢有很多东西没来得及截图也不方便截图,处理过程一些波折也经过了简化。
老规矩,知道写了些啥。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

胖头鱼的鱼缸(尹海文)

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值