Oracle数据库shutdown immediate被hang住的几个原因

简介:

Oracle数据库shutdown immediate被hang住的几个原因

2014-01-05 23:08 by 潇湘隐者, 3677 阅读, 0 评论, 收藏,  编辑            

实验操作环境:

        操作系统:Red Hat Enterprise Linux ES release 4 (Nahant Update 6)                  

        数据库 : Oracle Database 10g Release 10.2.0.4.0 – Production  32bit

今晚使用shutdown immediate(其实是执行stop_oracle.sh脚本关闭数据库,如下所示)关闭数据库的时候,

   1: [oracle@gsp-orasvr02 scripts]$ more stop_oracle.sh

   

   2: lsnrctl stop LISTENER

   

   3: sleep 15

   

   4: sqlplus /nolog <<EOF

   

   5: conn / as sysdba;

   

   6: alter system switch logfile;

   

   7: alter system checkpoint;

   

   8: shutdown immediate;

   

   9: exit

   

  10: EOF

在另外一个会话中使用tail  -20f  命令查看告警日志的输出,结果发现数据库等待了很长时间都没有正常关闭,hang住在下面地方:

Active call for process 11121 user 'oracle' program 'oracle@get-orasvr02 (S000)'

Active call for process 7162 user 'oracle' program 'oracle@get-orasvr02 (S011)'

                                                           截图如下

clip_image002

这时解决办法是找出hang住的进程并杀掉(当时操作没有截图,也没有保存输出信息),因为有些session无法被pmon进程清理,导致数据库无法顺利关闭,需要手工杀掉进程。首先使用ps 和grep找到这两个进程。

[ oracle@get-orasvr02  bdump]$ ps -ef | grep oracle | grep  S000

[ oracle@get-orasvr02  bdump]$ ps -ef | grep oracle | grep  S011

然后使用kill -9  processesid杀掉这两个进程即可,杀掉这两个进程后,从告警日志里面看到里面跳到关闭dispatcher 。如下所示:

   1: [ oracle@get-orasvr02  bdump]$ tail  alert_epps.log

   

   2:   Current log# 3 seq# 242223 mem# 1: /u02/oradata/epps/redo03_01.log

   

   3: Sun Jan 5 05:14:50 2014

   

   4: Starting control autobackup

   

   5: Control autobackup written to DISK device

   

   6:         handle '/u01/app/oracle/product/10.2.0/db_1/dbs/c-2179993557-20140105-0e'

   

   7: Sun Jan 5 05:14:54 2014

   

   8: ALTER SYSTEM ARCHIVE LOG

   

   9: Sun Jan 5 05:14:55 2014

   

  10: Thread 1 cannot allocate new log, sequence 242224

   

  11: Checkpoint not complete

   

  12:   Current log# 3 seq# 242223 mem# 0: /u01/app/oracle/oradata/epps/redo03_1.log

   

  13:   Current log# 3 seq# 242223 mem# 1: /u02/oradata/epps/redo03_01.log

   

  14: Sun Jan 5 05:14:58 2014

   

  15: Thread 1 advanced to log sequence 242224 (LGWR switch)

   

  16:   Current log# 5 seq# 242224 mem# 0: /u01/app/oracle/oradata/epps/redo05_1.log

   

  17:   Current log# 5 seq# 242224 mem# 1: /u02/oradata/epps/redo05_02.log

   

  18: Sun Jan 5 07:31:56 2014

   

  19: Thread 1 advanced to log sequence 242225 (LGWR switch)

   

  20:   Current log# 2 seq# 242225 mem# 0: /u01/app/oracle/oradata/epps/redo02_1.log

   

  21:   Current log# 2 seq# 242225 mem# 1: /u02/oradata/epps/redo02_02.log

   

  22: Sun Jan 5 07:32:20 2014

   

  23: Starting background process EMN0

   

  24: Shutting down instance: further logons disabled

   

  25: EMN0 started with pid=43, OS id=7062

   

  26: Sun Jan 5 07:32:21 2014

   

  27: Stopping background process CJQ0

   

  28: Sun Jan 5 07:32:21 2014

   

  29: Stopping background process QMNC

   

  30: Sun Jan 5 07:32:23 2014

   

  31: Stopping background process MMNL

   

  32: Sun Jan 5 07:32:34 2014

   

  33: Background process MMNL not dead after 10 seconds

   

  34: Sun Jan 5 07:32:34 2014

   

  35: Killing background process MMNL

   

  36: Sun Jan 5 07:32:35 2014

   

  37: Stopping background process MMON

   

  38: Sun Jan 5 07:33:05 2014

   

  39: Background process MMON not dead after 30 seconds

   

  40: Sun Jan 5 07:33:05 2014

   

  41: Killing background process MMON

   

  42: Sun Jan 5 07:33:06 2014

   

  43: Shutting down instance (immediate)

   

  44: License high water mark = 561

   

  45: Sun Jan 5 07:33:06 2014

   

  46: Stopping Job queue slave processes, flags = 7

   

  47: Sun Jan 5 07:33:06 2014

   

  48: Process OS id : 6088 alive after kill

   

  49: Errors in file /u01/app/oracle/admin/epps/udump/epps_ora_7055.trc

   

  50: Sun Jan 5 07:33:09 2014

   

  51: Waiting for Job queue slaves to complete

   

  52: Sun Jan 5 07:33:09 2014

   

  53: Job queue slave processes stopped

   

  54: Sun Jan 5 07:38:10 2014

   

  55: Active call for process 11121 user 'oracle' program 'oracle@get-orasvr02 (S000)'

   

  56: Active call for process 7162 user 'oracle' program 'oracle@get-orasvr02 (S011)'

   

  57: SHUTDOWN: waiting for active calls to complete.

   

  58: Sun Jan 5 07:57:28 2014

   

  59: Waiting for dispatcher 'D000' to shutdown

   

  60: Waiting for dispatcher 'D001' to shutdown

   

  61: Waiting for dispatcher 'D002' to shutdown

   

  62: Waiting for dispatcher 'D003' to shutdown

   

  63: Waiting for dispatcher 'D004' to shutdown

   

  64: Waiting for dispatcher 'D005' to shutdown

   

  65: Waiting for dispatcher 'D006' to shutdown

   

  66: Sun Jan 5 07:59:29 2014

   

  67: All dispatchers and shared servers shutdown

   

  68: Sun Jan 5 08:04:30 2014

   

  69: SHUTDOWN: Active processes prevent shutdown operation

   

  70: Sun Jan 5 08:09:32 2014

   

  71: SHUTDOWN: Active processes prevent shutdown operation

Oracle的官方文档介绍、解释如下

The database is waiting for pmon to clean up processes, but pmon is unable to

clean them. The client connections to the server are causing the shutdown

immediate or normal to hang. Killing them allows pmon to clean up and release

the associated Oracle processes and resources.

What resources are we talking about?

1) Any non committed transactions must be rolled back

2) Any temporary space (sort segments / lobs / session temporary tables) must be freed

3) The session itself and any associated memory consumed by the session.

4) Internal locks / enqueues must be cleaned up

Often Oracle (SMON or PMON depending on whether Shared Server is used) will wait for the OS to terminate the process(es) associated with the session. If the OS never returns, or fails to terminate them, then the instance shutdown will hang with this message (Shutdown Waiting for Active Calls to Complete)

Other means exist to achieve a quick shutdown, as outlined inNote 386408.1- What Is The Fastest Way To Cleanly Shutdown An Oracle Database?

结果解决上面问题后,本以为可以顺利关闭数据库,结果又hang住了,告警日志信息提示为

SHUTDOWN: Active processes prevent shutdown operation

出现这个错误原因:

因为我大概如下的操作导致:

[oracle@gsp-orasvr02 scripts]$ sqlplus / as sysdba

...........

SQL> !

[oracle@get-orasvr02 ~]$

..... (执行了一些shell 命令)

然后又使用了sqlplus启动登录了数据库,然后做shutdown immediate操作,这时导致shutdown immediate被hang住。

[oracle@gsp-orasvr02 scripts]$ sqlplus / as sysdba

解决办法:退出当前的会话,回到原始会话,并重新连接,就可以正常的关闭数据库了















本文转自xiaocao1314051CTO博客,原文链接:http://blog.51cto.com/xiaocao13140/1932951 ,如需转载请自行联系原作者



相关文章
|
7月前
|
Oracle 关系型数据库 Linux
【赵渝强老师】Oracle数据库配置助手:DBCA
Oracle数据库配置助手(DBCA)是用于创建和配置Oracle数据库的工具,支持图形界面和静默执行模式。本文介绍了使用DBCA在Linux环境下创建数据库的完整步骤,包括选择数据库操作类型、配置存储与网络选项、设置管理密码等,并提供了界面截图与视频讲解,帮助用户快速掌握数据库创建流程。
632 93
|
6月前
|
Oracle 关系型数据库 Linux
【赵渝强老师】使用NetManager创建Oracle数据库的监听器
Oracle NetManager是数据库网络配置工具,用于创建监听器、配置服务命名与网络连接,支持多数据库共享监听,确保客户端与服务器通信顺畅。
344 0
|
9月前
|
存储 Oracle 关系型数据库
服务器数据恢复—光纤存储上oracle数据库数据恢复案例
一台光纤服务器存储上有16块FC硬盘,上层部署了Oracle数据库。服务器存储前面板2个硬盘指示灯显示异常,存储映射到linux操作系统上的卷挂载不上,业务中断。 通过storage manager查看存储状态,发现逻辑卷状态失败。再查看物理磁盘状态,发现其中一块盘报告“警告”,硬盘指示灯显示异常的2块盘报告“失败”。 将当前存储的完整日志状态备份下来,解析备份出来的存储日志并获得了关于逻辑卷结构的部分信息。
|
7月前
|
SQL Oracle 关系型数据库
Oracle数据库创建表空间和索引的SQL语法示例
以上SQL语法提供了一种标准方式去组织Oracle数据库内部结构,并且通过合理使用可以显著改善查询速度及整体性能。需要注意,在实际应用过程当中应该根据具体业务需求、系统资源状况以及预期目标去合理规划并调整参数设置以达到最佳效果。
494 8
|
9月前
|
SQL Oracle 关系型数据库
比较MySQL和Oracle数据库系统,特别是在进行分页查询的方法上的不同
两者的性能差异将取决于数据量大小、索引优化、查询设计以及具体版本的数据库服务器。考虑硬件资源、数据库设计和具体需求对于实现优化的分页查询至关重要。开发者和数据库管理员需要根据自身使用的具体数据库系统版本和环境,选择最合适的分页机制,并进行必要的性能调优来满足应用需求。
438 11
|
9月前
|
Oracle 关系型数据库 数据库
数据库数据恢复—服务器异常断电导致Oracle数据库报错的数据恢复案例
Oracle数据库故障: 某公司一台服务器上部署Oracle数据库。服务器意外断电导致数据库报错,报错内容为“system01.dbf需要更多的恢复来保持一致性”。该Oracle数据库没有备份,仅有一些断断续续的归档日志。 Oracle数据库恢复流程: 1、检测数据库故障情况; 2、尝试挂起并修复数据库; 3、解析数据库文件; 4、导出并验证恢复的数据库文件。
|
9月前
|
存储 Oracle 关系型数据库
【赵渝强老师】Oracle RMAN的目录数据库
Oracle RMAN默认将备份元信息存储在控制文件中,但控制文件损坏或丢失会导致恢复失败,且备份增多会使控制文件无限增长。为解决这些问题,Oracle引入了RMAN目录数据库(Catalog Database),专门用于存储RMAN备份的元信息。使用目录数据库可提升备份管理效率,支持多数据库共享、长期备份历史记录存储,并可保存RMAN脚本。本文详细介绍了如何创建目录数据库、注册目标数据库及其操作步骤。
260 0
|
Oracle 安全 关系型数据库
【Oracle】使用Navicat Premium连接Oracle数据库两种方法
以上就是两种使用Navicat Premium连接Oracle数据库的方法介绍,希望对你有所帮助!
2397 28
|
10月前
|
存储 Oracle 关系型数据库
oracle数据恢复—oracle数据库执行错误truncate命令的数据恢复案例
oracle数据库误执行truncate命令导致数据丢失是一种常见情况。通常情况下,oracle数据库误操作删除数据只需要通过备份恢复数据即可。也会碰到一些特殊情况,例如数据库备份无法使用或者还原报错等。下面和大家分享一例oracle数据库误执行truncate命令导致数据丢失的数据库数据恢复过程。
|
SQL Oracle 关系型数据库
【赵渝强老师】Oracle的闪回数据库
Oracle闪回数据库功能类似于“倒带按钮”,可快速将数据库恢复至 earlier 状态,无需还原备份。本文介绍了闪回数据库的使用方法及实战案例:包括设置归档模式、开启闪回功能、记录SCN号、执行误操作后的恢复步骤等。通过具体 SQL 操作演示了如何利用闪回数据库恢复被误删的用户数据。注意,使用此功能前需确保数据库为归档模式。
411 9

推荐镜像

更多
下一篇
开通oss服务