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 ,如需转载请自行联系原作者



相关文章
|
1月前
|
数据采集 Oracle 关系型数据库
实时计算 Flink版产品使用问题之怎么实现从Oracle数据库读取多个表并将数据写入到Iceberg表
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
1天前
|
Oracle 关系型数据库 数据库
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
打开oracle数据库报错“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。 数据库没有备份,无法通过备份去恢复数据库。用户方联系北亚企安数据恢复中心并提供Oracle_Home目录中的所有文件,急需恢复zxfg用户下的数据。 出现“system01.dbf需要更多的恢复来保持一致性”这个报错的原因可能是控制文件损坏、数据文件损坏,数据文件与控制文件的SCN不一致等。数据库恢复工程师对数据库文件进一步检测、分析后,发现sysaux01.dbf文件损坏,有坏块。 修复并启动数据库后仍然有许多查询报错,export和data pump工具使用报错。从数据库层面无法修复数据库。
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
|
8天前
|
Oracle 安全 关系型数据库
Oracle数据恢复—Oracle数据库误删除的数据恢复方法探讨
删除Oracle数据库数据一般有以下2种方式:delete、drop或truncate。下面针对这2种删除oracle数据库数据的方式探讨一下oracle数据库数据恢复方法(不考虑全库备份和利用归档日志)。
|
18天前
|
存储 Oracle 关系型数据库
Oracle同一台服务器创建多个数据库
【8月更文挑战第30天】在 Oracle 中,可在同一服务器上创建多个数据库。首先确保已安装 Oracle 软件并具有足够资源,然后使用 DBCA 工具按步骤创建,包括选择模板、配置存储及字符集等。重复此过程可创建多个数据库,需确保名称、SID 和存储位置唯一。创建后,可通过 Oracle Enterprise Manager 进行管理,注意服务器资源分配与规划。
32 10
|
26天前
|
存储 Oracle 关系型数据库
分享几个Oracle数据库日常维护中常见的问题
分享几个Oracle数据库日常维护中常见的问题
74 1
|
21天前
|
SQL Oracle 关系型数据库
实时计算 Flink版产品使用问题之Oracle数据库是集群部署的,怎么进行数据同步
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
26天前
|
Oracle 关系型数据库 数据库
Oracle数据库备份脚本分享-Python
Oracle数据库备份脚本分享-Python
24 0
|
SQL Oracle 关系型数据库
【Oracle】数据库hang 诊断
一 什么是数据库hang 1 用户不能登录数据库 2 数据库不能正常工作 3 select 1 from dual 不出结果 4 不能正常完成建表操作 二 数据库被锁住    1  一个或多个会话停止工作 三 如果得知数据库hang 或者被锁    1 测试...
826 0
|
1月前
|
存储 自然语言处理 Oracle
Oracle数据库字符集概述及修改方式
【8月更文挑战第15天】Oracle 数据库字符集定义了数据的编码方案,决定可存储的字符类型及其表示方式。主要作用包括数据存储、检索及跨系统传输时的正确表示。常见字符集如 AL32UTF8 支持多语言,而 WE8MSWIN1252 主用于西欧语言。修改字符集风险高,可能导致数据问题,需事先备份并评估兼容性。可通过 ALTER DATABASE 语句直接修改或采用导出-导入数据的方式进行。完成后应验证数据完整性。此操作复杂,须谨慎处理。
|
1月前
|
SQL Oracle 关系型数据库
"揭秘!一键解锁Oracle日志清理魔法,让海量归档日志无处遁形,守护数据库健康,告别磁盘空间告急噩梦!"
【8月更文挑战第9天】随着Oracle数据库在企业应用中的普及,归档日志管理对保持数据库健康至关重要。归档日志记录所有更改,对数据恢复极为重要,但也可能迅速占用大量磁盘空间影响性能。利用Oracle提供的RMAN工具,可通过编写Shell脚本来自动清理归档日志。脚本包括设置环境变量、连接数据库、检查和删除指定时间前的日志,并记录执行情况。通过Cron作业定时运行脚本,可有效管理日志文件,确保数据库稳定运行。
65 7

推荐镜像

更多