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

简介:

实验操作环境:

        操作系统: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

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

相关文章
|
13天前
|
Oracle 关系型数据库 网络安全
崖山异构数据库迁移利器YMP初体验-Oracle迁移YashanDB
文章是作者小草对崖山异构数据库迁移利器 YMP 的初体验分享,包括背景、YMP 简介、体验环境说明、YMP 部署(含安装前准备、安装、卸载、启动与停止)、数据迁移及遇到的问题与解决过程。重点介绍了 YMP 功能、部署的诸多细节和数据迁移流程,还提到了安装和迁移中遇到的问题及解决办法。
|
13天前
|
数据库
【YashanDB知识库】数据库使用shutdown immediate无响应导致coredump
【标题】数据库使用shutdown immediate无响应导致coredump 【简介】在YashanDB 22.2 - 22.2.10.100版本中,执行shutdown immediate后数据库未正常退出,强制停止进程时发生coredump。原因是参数错误导致选举错误,且shutdown后数据库重启并接收redo日志,终止时因处理redo日志触发异常。需检查参数设置并避免不当操作。
|
13天前
|
数据库
【YashanDB知识库】yac修改参数后关闭数据库hang住
【标题】YashanDB yac修改参数后关闭数据库hang住 【简介】修改yac参数后执行`shutdown immediate`时,数据库hang住。原因是Shutdown操作中线程卡在获取信号量,jobManagerStop()和checkRedoFreeSpace()接口导致死循环,且SHM_POOL_SIZE过小影响redo日志使用。需检查配置文件并调整SHM_POOL_SIZE参数。影响范围为23.1 - 23.1.1.200版本。 【关键词】YashanDB, yac, shutdown hang 【修复版本】待定
|
14天前
|
数据库
【YashanDB知识库】数据库审计shutdown immediate操作导致数据库异常退出
【YashanDB知识库】数据库审计shutdown immediate操作导致数据库异常退出
|
3月前
|
存储 Oracle 关系型数据库
数据库数据恢复—ORACLE常见故障的数据恢复方案
Oracle数据库常见故障表现: 1、ORACLE数据库无法启动或无法正常工作。 2、ORACLE ASM存储破坏。 3、ORACLE数据文件丢失。 4、ORACLE数据文件部分损坏。 5、ORACLE DUMP文件损坏。
196 11
|
4月前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
4月前
|
存储 Oracle 关系型数据库
oracle数据恢复—Oracle数据库文件大小变为0kb的数据恢复案例
存储掉盘超过上限,lun无法识别。管理员重组存储的位图信息并导出lun,发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息,重新导出控制文件中记录的数据文件,发现这些文件的大小依然为0kb。
|
3月前
|
存储 Oracle 关系型数据库
服务器数据恢复—华为S5300存储Oracle数据库恢复案例
服务器存储数据恢复环境: 华为S5300存储中有12块FC硬盘,其中11块硬盘作为数据盘组建了一组RAID5阵列,剩下的1块硬盘作为热备盘使用。基于RAID的LUN分配给linux操作系统使用,存放的数据主要是Oracle数据库。 服务器存储故障: RAID5阵列中1块硬盘出现故障离线,热备盘自动激活开始同步数据,在同步数据的过程中又一块硬盘离线,RAID5阵列瘫痪,上层LUN无法使用。
|
5天前
|
关系型数据库 MySQL 数据库连接
docker拉取MySQL后数据库连接失败解决方案
通过以上方法,可以解决Docker中拉取MySQL镜像后数据库连接失败的常见问题。关键步骤包括确保容器正确启动、配置正确的环境变量、合理设置网络和权限,以及检查主机防火墙设置等。通过逐步排查,可以快速定位并解决连接问题,确保MySQL服务的正常使用。
110 82
|
2月前
|
关系型数据库 MySQL 数据库连接
数据库连接工具连接mysql提示:“Host ‘172.23.0.1‘ is not allowed to connect to this MySQL server“
docker-compose部署mysql8服务后,连接时提示不允许连接问题解决

推荐镜像

更多