前言
应用支持A,接到业务部门反映公司的老总生产看板数据显示不了,联系开发组B,说是程序最近没有改动过,问题肯定在数据库让我检查数据库
查看报错ora-12541,检查数据库的监听,1521端口,均正常,线上的生产系统(与生产看板用的是同一个数据库),plsql都是正常。反应给开发组B,B说是程序没有改动,问题肯定在数据库。
因为不了解的生产看板的的数据架构,向B要应用连接数据库的配置参数,一直没给我
因为是公司总经理的事情,领导比较关注,应用支持A就一直说是数据库的问题,让重启数据库先
我一直坚持先了解架构再说,但是领导,A还有几个同事都是在说是数据库的问题,想了下问下厂里,这里有15分钟的时间给我重启数据库。
sql>shutdown immediate;
等了2分钟还是这里,大概是数据库hang住了
另开一个窗口:
SQL> conn /as sysdba
Connected to an idle instance.
SQL> startup;
ORA-10997: another startup/shutdown operation of this instance inprogress
ORA-09968: unable to lock file
Linux-x86_64 Error: 11: Resource temporarily unavailable
Additional information: 23096
好吧,关不掉,又起不来
领导这时问怎么回事,我说hang住了,打电话问厂里还有几分钟开线,回答3分钟
狂汗……
好吧只有kill掉local=no的进程强行关机了(冒着数据丢失的各种风险了,厂里停线的责任实在太大,担待不起)
sql>shutdown abort;
sql>startup;
还好数据库起来了
检查数据库状态:
sql>select open_mode from v$database
read_write
正常开启
登陆Mes系统
系统正常心理的大石头放下来
生产看板的问题还没有解决,也就是说数据库重启无效
问B,B说是问题找到了
生产看板的数据是汇总到我这里数据库显示,我这里的数据库是从集团服务器DB1汇总过来,各个基地的生产数据先汇总到集团服务器DB1。
集团服务器DB1宕机导致这个问题,-_-|||
总结:
一:当遇到系统有问题,查看系统是否有异常报错,如果没有,查看是否其他方面影响;
二:在没有了解系统架构的时候,不要擅自做一些有较大风险的操作,毕竟解决一个问题需要多沟通 , 多了解,闭门造车肯定不行;
三:当需要重启服务器的时候,要分清事情的大小轻重,缓急,不要受周围的人影响,毕竟重启服务器 出现突发状况的时候,出现重大故障,你是第一责任人,与七嘴八舌的人没有太大关系。
转载于:https://blog.51cto.com/1336014/1661523