« 7月21日-Oracle11g新特性公开课 | Blog首页 | Oracle中数据文件大小的限制 »
DBA警示录:关闭数据库应当谨慎
作者：eygle | 【转载请注出处】|【云和恩墨 领先的zData数据库一体机 | zCloud PaaS云管平台 | SQM SQL审核平台 | ZDBM 数据库备份一体机】
链接：https://www.eygle.com/archives/2007/07/careful_to_shutdown.html
链接：https://www.eygle.com/archives/2007/07/careful_to_shutdown.html
周末在ITPUB上看到这样一个帖子：
信息1：
电信运营客户出了问题，紧急向大家求助
版本是AIX 5.3 ORACLE 9206，REDOLOG是500M
因为他们阵列换电池，为保险起见就关机了，但是他们的DBA可能经验不足并且可能觉得麻烦，就直接SHUTDOWN ABORT了，但是现在数据库却无法开起我远程连上去看了一下，发现有一个ORACLE进程消耗资源比较多，估计是系统进程做系统的实例恢复，从下午7点到现在都快3个小时了，数据库还是不停的做实例恢复，后来DBA还和他主管动了手脚 。现在他们想知道什么时候才可以恢复完毕，用什么地方可以计算出大概要恢复的时间，或者有什么地方可以加速系统的恢复
信息2：
DBA和他主管干了一架,DBA已经走人..........
信息3：
后来问了一下，具体情况大概是这样的
本来用SHUTDOWN IMMEDIATE,但是关的慢，但是他们主管老是在那里唠叨，主管是一个高层的亲戚，好象只是中专毕业没有多久的．
后来被催烦了，就直接杀进程，然后就启动不来了
主管是从那种痞子学校出来的，什么都不会，就会骂人，后来2个人在那里推搡，就打起来了，电脑都打坏几台
现在还在恢复
在这次事故里，有几件事情需要注意：
1.DBA要有扎实的基础
作为一个DBA一定要了解自己的操作可能带来的后果，否则一旦出现问题就只能是后悔莫及。
2.DBA要有良好的心理素质
要能够坚持自己正确的观点，不能感情用事。数据库管理，好歹也是个技术工作。一定不要感情用事。
特别是对于重要的数据库，遇事更要考虑得周全一点。
至于其他的人的因素，都还是次要的，有些习惯DBA必需养成，有些素质DBA也必需具备。
-The End-
By eygle on 2007-07-08 15:46 | Comments (19) | Beginner | 1492 |
且不论主管，DBA也有责任！
呵呵，最近freelist上有个讨论，说的就是shutdown abort能否做为日常关机的选项。Robert G. Freeman坚持认为是可以将shutdow n abort作为正常关机的手段的，除非遭遇bug，shutdown abort和shutdown immediate所需要的整体时间(包括后面startup需要的时间)应该是相差不多的，问题就在于时间是花在shutdown还是startup上面而已，有一定的道理。我认为，在需要快速关机而尽量不影响已经连接的应用，又要快速启动的情况下，先checkpoint再shutdown abort是可以接受的
不过在已经shutdown immediate的情况下直接杀进程，是不可取的，危险性应该比直接shudown abort大很多
这个帖子为什么被删除了。
是的，贴子看到了5楼，过会再看，被删除了！
可以多设置多设置几个recovery_parallelism并行度，测试过还是有用的
以便恢复，一边用oradebug命令查看，并dump systemstate level 10,分析trace
有的时候是一个操作系统的进程阻塞了恢复进程,KILL 掉就可以了.
看来是不太适合公开讨论了。作者自己删除了吧。
关于shutdown abort
我的看法是，要具体分析，如果是正常情况下，一般是没有问题的。
但是当系统比较繁忙，存在较多闩锁竞争、活动事务的情况下，应当极其慎重。
个人认为最稳妥的方法是，先从操作系统kill -9用户进程，再shutdown immediate；或者checkpoint再abort都是可以的。
直接abort一定是不推荐的。
大多数情况下，kill -9 local=no的进程是的可以,可以加快shutdown immediate 的速度，有的时候KILL -9显示成功了，但是此时是“假死”状态，进程号没有了，v$session中的status也是killed状态，但一致不消失，但是资源由于某些原因，根本无法释放，这种情况通常和操作系统的某些内核调用有关，由于业务急着恢复，所以迫不得以用shutdown abort.
不过shutdown abort的命令，就是拿自己的DBA 职业生涯在赌博，成则罢了，输则.......,所以具体具体分析吧。
我帮助别人处理过3次abort起不来的情况，自己倒是从来没有遇到过。
DBA有点冲动,居然在shutdown immediate过程中kill关键进程,应该是和主管积冤以久才会这样的,悲哀......
问题是有这么急的吗? 一般不需要在这个Shutdown上争取时间的啊.
Checkpoint先是很好的习惯了.
是要先停lsnr还是要先停数据库？
一般是先lsnr
可以先将监听器停下来。
不管shutdown immediate还是abort,先做 checkpoint是好习惯
不过这样的有这样的主管在，离开未尝不是一件好事
真晕，...
不知道是哪里的电信啊，应该不是浙江电信。