数据库管理 2023-06-01

第七十九期儿童节惊魂
- 1 主板挂了？
- 2 时间同步
- 3 数据库参数
- 4 ACFS
- 5 两个错误
- 总结

第七十九期儿童节惊魂

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 #这里需要通过执行清理上面所有告警的UUIDexit
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_convertNAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert                 string
log_file_name_convert                string
pdb_file_name_convert                string--节点1（故障节点）：
SQL> show parameter file_name_convertNAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert                 string      'dbdg','db'
log_file_name_convert                string      'dbdg','db'
pdb_file_name_convert                stringcreate 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的人，这两件事情加在一起不得不让我怀疑这是不是故意的。

总结

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

数据库管理-第七十九期儿童节惊魂（20230601）相关推荐

数据库管理-第四十九期 Exadata的存储节点管理（20221223）
数据库管理 2022-12-23 第四十九期 Exadata的存储节点管理 1 咋个查看数据是否被缓存到闪存卡了没 2 EM13.5的Exadata监控 3 存储降级总结第四十九期 Exadata ...
数据库管理-第七十五期手把手教你搭19c RAC（20230516）
数据库管理 2023-05-16 第七十五期手把手教你搭19c RAC 1 基础环境 2 操作系统配置 2.1 /etc/hosts 2.2 配置系统挂载 2.3 配置本地yum源 2.4 操作系统 ...
第七十九期：阿里程序员感慨：码农们过去暴富有多轻松，现在赚钱就有多辛苦
互联网的世界也是一座围城.有人挤破脑袋想要进去.而有人又觉得是被互联网的光鲜表象欺骗了忙着要出来,但最终,这些人都会离开. 作者:职场八卦互联网的世界也是一座围城.有人挤破脑袋想要进去.而有人又觉得 ...
中国传媒大学计算机联合学院,第七十九期CCF-CV走进高校系列报告会于中国传媒大学圆满结束...
2019年9月24日下午,由中国计算机学会计算机视觉专委会(CCF-CV)主办,中国传媒大学媒介音视频教育部重点实验室.数据科学与智能媒体学院联合承办的第79期CCF-CV走进高校系列报告会--&qu ...
开发者论坛一周精粹(第十九期) ：【重要事件】运维人员注意啦：NetSarang的Xmanager和Xshell多种产品被植入后门...
摘要: 安全公司发现官方发布的软件版本中,nssock2.dll模块源码被植入后门.由于使用该软件的技术人员较多,存在一定的安全风险. 目前官方已经发布了xshell最高版本为 Xshell 5 Bu ...
《袁老师访谈录》第十九期-【在商言商·思享会】(第一场)“企业如何抓住新一代科技红利”...
11月21日,<袁老师访谈录>第十九期-香港科大商学院[在商言商·思享会](第一场)"企业如何抓住新一代科技红利"成功举办,现场共有近150位校友及观众到场,十大平台同 ...
鲁大师电动车智能化测评报告第十九期：电自旗舰大乱斗，九号突围成功
鲁大师第十九期智能化电动车测评排行榜数据来源于鲁大师智慧实验室,测评的车型均为市面上主流品牌的主流车型.截止目前,鲁大师智能化电动车测评的车型高达100余台,且还在不断增加和丰富中. 1. 测评依据 ...
应用回归分析何晓群课第五版_海外第三方应用市场分析丨出海学院十九期直播课...
Enjoy出海一站式出海服务平台点击关注"Enjoy出海"公众号时时参与出海答疑问题出海学院第十九期直播课出海学院十九期直播课,由Enjoy出海CEO金翔主讲,本期主题为& ...
2021计算机一级模拟29套,“智慧家”2021年第二十九期每周家庭套餐
原标题:"智慧家"2021年第二十九期每周家庭套餐玉溪妇联架起一座与广大姐妹们沟通的桥梁只有家长的好好学习,才能助力孩子的健康成长,只有家长和孩子不断地学习成长,才能营造和谐 ...

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

数据库管理 2023-06-01

第七十九期儿童节惊魂

1 主板挂了？

2 时间同步

3 数据库参数

4 ACFS

5 两个错误

总结

数据库管理-第七十九期儿童节惊魂（20230601）相关推荐

最新文章

热门文章

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

数据库管理 2023-06-01

第七十九期 儿童节惊魂

1 主板挂了？

2 时间同步

3 数据库参数

4 ACFS

5 两个错误

总结

数据库管理-第七十九期 儿童节惊魂（20230601）相关推荐

最新文章

热门文章

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

第七十九期儿童节惊魂

数据库管理-第七十九期儿童节惊魂（20230601）相关推荐