前言
应用支持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
