eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« 7月21日-Oracle11g新特性公开课 | Blog首页 | Oracle中数据文件大小的限制 »

DBA警示录:关闭数据库应当谨慎

周末在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-


历史上的今天...
    >> 2013-07-08文章:
    >> 2009-07-08文章:

By eygle on 2007-07-08 15:46 | Comments (19) | Beginner | 1492 |

19 Comments

且不论主管,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是好习惯

不过这样的有这样的主管在,离开未尝不是一件好事

真晕,...

不知道是哪里的电信啊,应该不是浙江电信。


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com