前言

应用支持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宕机导致这个问题,-_-|||


总结:

一:当遇到系统有问题,查看系统是否有异常报错,如果没有,查看是否其他方面影响;


二:在没有了解系统架构的时候,不要擅自做一些有较大风险的操作,毕竟解决一个问题需要多沟通 ,     多了解,闭门造车肯定不行;


三:当需要重启服务器的时候,要分清事情的大小轻重,缓急,不要受周围的人影响,毕竟重启服务器      出现突发状况的时候,出现重大故障,你是第一责任人,与七嘴八舌的人没有太大关系。