前言

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

总结：

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

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

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

本文转自 abc3486389 51CTO博客，原文链接:http://blog.51cto.com/1336014/1661523