记一次微小操作造成的系统故障。

栏目:s-hr cloud知识作者:金蝶来源:金蝶云社区发布:2024-09-16浏览:1

记一次微小操作造成的系统故障。

公司这几天sHR系统出现了一些故障,现将相关的经验总结一下,让后面的人可以少走一些弯路。故障缘起1月8日周一,周一中午接到sHR系统报障,报障内容为系统有登陆界面,但是输入正确用户名,密码之后进入显示白屏。故障图如下:

故障图就这样
首先介绍一下我们的系统数据库服务器为centos 7.2 数据库版本为oracle 11g;应用服务器为centos 6.8,全部为自定义最小化安装;

第一轮交锋:1月8日12:00-13:30
1.出现问题第一反应为数据库挂了,vnc连接应用服务器,进入EAS8.2控制台,查看数据中心情况发现数据中心处无异常报错,但控制台整体反应较慢,通过ping命令,以及telnet命令测试网络以及端口都正常,排除应用以及数据库服务器网络故障可能;
2.进入数据库服务器oracle用户登录数据库输入select * from v$recovery_file_dest; 查看归档,发现归档日志使用率正常;
3.应用服务器EAS8.2控制台查看群集控制器,发现两个从实例负载了一共450人左右,初步判断为从实例负载较大造成的系统登陆异常,且主实例有一般用户登录。
4.停止集群,集群配置,增加从实例,将从实例由原来的2个增加到10个,修改防火墙规则,屏蔽主实例6888端口,防火墙配置命令如下:
vim /etc/sysconfig/iptables
将如下内容从防火墙规则中去掉
-A INPUT -m state --state NEW -m tcp -p tcp --dport 6888 -j ACCEPT
service iptbles reload
5.启动服务后系统正常运转。
第二轮交锋:1月9日9:00-10:00
1.翌日,还在公司的路上问题再次出现,此次问题出现之后登陆应用服务器查看EAS8.2数据中心状态,发现error报错。


当时没有截图,错误处用标红显示
2.停集群,进入数据库输入select * from v$recovery_file_dest; 发现归档日志依旧正常,网络也依旧正常;
3.无奈,寄出重启神技,数据库输入shutdown immediate,关闭完毕之后startup正常启动数据库;
4.启动集群之后服务正常。
第三轮交锋:1月9日13:30-15:30
1.几小时不到,系统再次无法登陆;
2.查看数据中心依旧error报错;
3.停集群,进入数据库输入select * from v$recovery_file_dest;发现归档日志已满,归档日志出现异常;


未找到原图,出现问题时,框内数据大小一致4.进入数据库服务器,rman,物理路径下删除归档日志,然后运行如下命令:rman target / nocatalogCrosscheck archivelog allDelete expired archivelog all5.归档删除重启集群,问题解决;第四轮交锋:1月9日15:40-1月10日14:301.问题暂时解决,但是后续问题接踵而来,进入数据库输入select * from v$recovery_file_dest;发现归档日志以肉眼可见速度增长起来,用如下命令查看归档日志cd /oracle/app/oracle/fast_recovery_area/OPPOHR/archivelog/2018_01_10ls -lh出现如下内容:



发现系统每隔2分钟左右会产生一个80M左右的归档日志,规律往复:每隔半小时用如下命令:du -h /oracle/app/oracle/fast_recovery_area/OPPOHR/archivelog/2018_01_10发现归档日志增长的容量和速度,之前设置的16g归档日志空间已经无法满足;2.为保证系统能够正常使用根据预估调整了归档日志的大小,归档日志调整命令如下:alter system set db_recovery_file_dest_size=80g scope=both;3.系统运行一天,没有出现无法登陆问题。问题分析:1.分析归档日志存储规律发现如下问题:
①归档日志产生存在规律性;②归档日志在午夜和凌晨,等用户使用较少的时间依旧规律性产生归档日志;③该问题从未出现过,1月8日开始出现该问题。总结:1.数据库本身问题可以排除;2.怀疑点极大的偏向于应用服务器进行了频繁的增删改操作,导致归档日志产生;3.问题出现在正常工作区间,怀疑对象倾向于人员参数设置错误。4.排除如此大量的归档日志是用户操作导致。尾声:在排查了近几天对于服务器的配置操作后,一次意外的收获让我们发现了问题的症结,问题的症结在于实施人员在客户端创建了一个“后台事务定义”将假勤管理里面的“云之家签到数据同步”的调动计划改为了每1分钟执行一次,导致出现了该问题,改为每30分钟执行一次,问题解决……后记:
本次问题处理仍然有如下疑问等待后续查证或者观者指教:1.前面的几次系统异常为何每次查归档都没有任何问题?


厉害了,豪哥
厉害了,Word哥:/P

记一次微小操作造成的系统故障。

公司这几天sHR系统出现了一些故障,现将相关的经验总结一下,让后面的人可以少走一些弯路。故障缘起1月8日周一,周一中午接到sHR系统报障,...
点击下载文档
分享:
确认删除?
回到顶部
客服QQ
  • 客服QQ点击这里给我发消息