数据库文件用专门的命令怎么关闭?

发布网友发布时间：2022-04-23 04:00

共2个回答

懂视网时间：2022-04-08 03:26

有个测试库，使用shutdown normal停库，结果就是很常见的hang住了。

操作顺序：

?1. shutdown normal，然后关闭了当前sqlplus窗口。
?从alert日志中看：
?Mon Jun 22 16:50:22 2015
Shutting down instance (normal)
Stopping background process SMCO
Shutting down instance: further logons disabled
这里涉及到shutdown normal的原理，稍后引述。
?

?2. 此时重新登录，sqlplus / as sysdba?，执行startup或shutdown immediate命令都提示失败，

SQL*Plus: Release 11.2.0.1.0 Production on Mon Jun 22 17:03:06 2015

Copyright (c) 1982, 2009, Oracle. All rights reserved.

Connected.
SQL> startup
ORA-01012: not logged on
SQL> shutdown immediate
ORA-24324: service handle not initialized
ORA-24323: value not allowed
ORA-01090: shutdown in progress - connection is not permitted
Mon Jun 22 16:50:24 2015
Stopping background process CJQ0
Stopping background process QMNC
Stopping background process MMNL
Stopping background process MMON
License high water mark = 125

ORA-01090提示说正在执行关闭操作，不允许其他连接的操作。

3. 其实这涉及到normal关闭的原理，他需要等待所有已连接用户中断连接，换句话说，如果仍有连接到库的用户，shutdown的操作就一直等待。这是最完全的关闭方式，但同时是变数最大的，因为可能你不知其他用户什么时候中断。

首先尝试查找出所有连接用户，用kill -9直接杀进程。

可以使用ps -ef查找所有(LOCAL=NO)的进程，LOCAL=NO表示连接不是本地，而是远程。

ps -ef|grep ora|grep -v grep|grep -v ora_|grep LOCAL=NO|awk ‘{print $2}‘，然后kill -9 进程号
或者
ps -ef|grep ora|grep -v grep|grep -v ora_|grep LOCAL=NO|awk ‘{print $2}‘|xargs kill

从alert日志看：

Mon Jun 22 16:55:26 2015
Active process 27446 user ‘oracle11g‘ program ‘oracle@dcsopenNode1‘
Active process 27402 user ‘oracle11g‘ program ‘oracle@dcsopenNode1‘
Active process 27555 user ‘oracle11g‘ program ‘oracle@dcsopenNode1‘
Active process 11697 user ‘oracle11g‘ program ‘oracle@dcsopenNode1‘
Active process 14942 user ‘oracle11g‘ program ‘oracle@dcsopenNode1‘
Active process 27559 user ‘oracle11g‘ program ‘oracle@dcsopenNode1‘
Active process 27513 user ‘oracle11g‘ program ‘oracle@dcsopenNode1‘
Active process 26911 user ‘oracle11g‘ program ‘oracle@dcsopenNode1‘
Active process 31993 user ‘oracle11g‘ program ‘oracle@dcsopenNode1‘
Active process 30810 user ‘oracle11g‘ program ‘oracle@dcsopenNode1‘
Active process 27557 user ‘oracle11g‘ program ‘oracle@dcsopenNode1‘
Active process 11684 user ‘oracle11g‘ program ‘oracle@dcsopenNode1‘
Active process 11666 user ‘oracle11g‘ program ‘oracle@dcsopenNode1‘
Active process 27510 user ‘oracle11g‘ program ‘oracle@dcsopenNode1‘
Active process 11688 user ‘oracle11g‘ program ‘oracle@dcsopenNode1‘
SHUTDOWN: waiting for logins to complete.
Mon Jun 22 17:01:29 2015
All dispatchers and shared servers shutdown

是提示了所有dispatcher和共享服务关闭，但sqlplus登录后仍是上面的提示。

4. 尝试关闭监听服务，lsnrctl stop。

问题依旧。

5. 重登陆执行shutdown abort，强制关闭。

从alert日志看：

USER (ospid: 28558): terminating the instance

Instance terminated by USER, pid = 28558

看样子是关闭了实例。

重新执行sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Mon Jun 22 17:43:25 2015

Copyright (c) 1982, 2009, Oracle. All rights reserved.

Connected to an idle instance.

再次执行startup-shutdown normal，

SQL> startup
ORACLE instance started.

Total System Global Area 3290345472 bytes
Fixed Size   2217832 bytes
Variable Size  2499807384 bytes
Database Buffers  771751936 bytes
Redo Buffers  16568320 bytes
Database mounted.
Database opened.
SQL> shutdown normal
Database closed.
Database dismounted.
ORACLE instance shut down.

由于现在已经没有连接的用户了，正常启动，正常关闭了。

从alert日志看，

Mon Jun 22 17:46:01 2015
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Using LOG_ARCHIVE_DEST_1 parameter default value as /oracle/ora11gR2/product/11.2.0/dbhome_1/dbs/arch
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =27
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
Using parameter settings in server-side spfile /oracle/ora11gR2/product/11.2.0/dbhome_1/dbs/spfiledcsopen.ora
System parameters with non-default values:
 processes  = 150
 memory_target  = 3152M
 control_files  = "/oracle/ora11gR2/oradata/dcsopen/control01.ctl"
 control_files  = "/oracle/ora11gR2/oradata/dcsopen/control02.ctl"
 db_block_size  = 8192
 compatible  = "11.2.0.0.0"
 undo_tablespace  = "UNDOTBS1"
 remote_login_passwordfile= "EXCLUSIVE"
 db_domain  = ""
 dispatchers  = "(PROTOCOL=TCP) (SERVICE=dcsopenXDB)"
 audit_file_dest  = "/oracle/ora11gR2/admin/dcsopen/adump"
 audit_trail  = "DB"
 db_name   = "dcsopen"
 open_cursors  = 300
 diagnostic_dest  = "/oracle/ora11gR2"
Mon Jun 22 17:46:03 2015
PMON started with pid=2, OS id=30699 
Mon Jun 22 17:46:03 2015
VKTM started with pid=3, OS id=30701 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Mon Jun 22 17:46:03 2015
GEN0 started with pid=4, OS id=30705 
Mon Jun 22 17:46:03 2015
DIAG started with pid=5, OS id=30707 
Mon Jun 22 17:46:03 2015
DBRM started with pid=6, OS id=30709 
Mon Jun 22 17:46:03 2015
PSP0 started with pid=7, OS id=30711 
Mon Jun 22 17:46:03 2015
DIA0 started with pid=8, OS id=30713 
Mon Jun 22 17:46:03 2015
MMAN started with pid=9, OS id=30715 
Mon Jun 22 17:46:03 2015
DBW0 started with pid=10, OS id=30717 
Mon Jun 22 17:46:03 2015
LGWR started with pid=11, OS id=30721 
Mon Jun 22 17:46:03 2015
CKPT started with pid=12, OS id=30723 
Mon Jun 22 17:46:03 2015
SMON started with pid=13, OS id=30725 
Mon Jun 22 17:46:03 2015
RECO started with pid=14, OS id=30727 
Mon Jun 22 17:46:03 2015
MMON started with pid=15, OS id=30729 
starting up 1 dispatcher(s) for network address ‘(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))‘...
Mon Jun 22 17:46:03 2015
MMNL started with pid=16, OS id=30731 
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /oracle/ora11gR2
Mon Jun 22 17:46:04 2015
ALTER DATABASE MOUNT
Successful mount of redo thread 1, with mount id 2809595100
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE MOUNT
Mon Jun 22 17:46:08 2015
ALTER DATABASE OPEN
Thread 1 opened at log sequence 1279
 Current log# 1 seq# 1279 mem# 0: /oracle/ora11gR2/oradata/dcsopen/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Mon Jun 22 17:46:09 2015
QMNC started with pid=20, OS id=30789 
Completed: ALTER DATABASE OPEN
Starting background process CJQ0
Mon Jun 22 17:46:11 2015
CJQ0 started with pid=22, OS id=30806 
Mon Jun 22 17:46:18 2015
Shutting down instance (normal)
Shutting down instance: further logons disabled
Stopping background process QMNC
Stopping background process CJQ0
Stopping background process MMNL
Stopping background process MMON
License high water mark = 5
All dispatchers and shared servers shutdown
ALTER DATABASE CLOSE NORMAL
Mon Jun 22 17:46:22 2015
SMON: disabling tx recovery
SMON: disabling cache recovery
Mon Jun 22 17:46:22 2015
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Thread 1 closed at log sequence 1279
Successful close of redo thread 1
Completed: ALTER DATABASE CLOSE NORMAL
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT
ARCH: Archival disabled due to shutdown: 1090
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Mon Jun 22 17:46:23 2015
Stopping background process VKTM: 
ARCH: Archival disabled due to shutdown: 1090
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Mon Jun 22 17:46:25 2015
Instance shutdown complete

借鉴《Concept》，一些知识点：

1. 如果用户试图访问一个正在关闭的数据库，会得到错误提示：ORA-01090: shutdown in progress - connection is not permitted.

2. 关闭数据库，必须用SYSOPER或SYSDBA的角色。

3. 关闭数据库，是有超时时间的，如果用户未中断连接，或者交易未完成，超过一小时，则shutdown命令会取消，提示错误：ORA-01013: user requested cancel of current operation.

4. 几种关闭库的参数，

shutdown normal：

默认的关闭参数，需要两个条件：

(1) 执行语句后，不允许新的连接。

(2) 数据库关闭之前，数据库会等待所有已连接用户中断连接。

下一次启动时不需要实例恢复。

shutdown immediate：

使用场景：

(1) 初始化一个自动，无人值守的备份。

(2) 马上就要断电。

(3) 数据库或应用工作不正常，你不能马上联系到用户退出登录或他们无法退出登录。

条件：

(1) 不允许新的连接，不允许新的交易。

(2) 任何未提交的事务会回滚(如果此时有个长交易，未提交，那么不会像这种关闭名称immediate那样迅速地关闭)。

(3) 不会等待已连接用户退出登录。数据库会隐式回滚活动事务，中断连接用户。

下一次启动时不需要实例恢复。

shutdown transactional：

适用于计划停机，允许活动交易处理完成后再停止实例的场景。

条件：

(1) 不允许新的连接，不允许新的交易。

(2) 所有交易完成后，会中断所有和库的连接。

(3) 在这个时间点，关闭实例就像执行了shutdown immediate。

下一次启动时不需要实例恢复。

transactional参数主要会防止用户丢失交易，同时不需要所有用户退出登录。

shutdown abort：

适用场景：

数据库或应用不能正常工作，并且没有其它类型的关闭操作正在进行。

(1) 需要立即关闭数据库(例如，一分钟后电源会被关闭)。

(2) 启动实例时碰到了问题。

条件：

(1) 不允许新的连接，不允许新的交易。

(2) 正在被Oracle处理的客户端SQL语句会被立即中断。

(3) 未提交事务不会回滚。

(4) Oracle不会等待正保持连接的客户端退出登录。数据库会隐式地中断所有连接。

下一次启动时需要进行实例恢复。

总结：

以上四种参数会适合于不同的场景，简单讲，shutdown normal是默认的关闭方式，最完整的关闭方式，缺点是需要被动等待所有交易完成，所有用户退出登录。shutdown immediate只要不存在较长的需要回滚的事务，其关闭时间会快。shutdown transactional会最大限度地保证交易的完成。前三种都不需要实例恢复。shutdown abort则是最暴力的关闭，关闭时间最快，但代价是启动需要实例恢复，因为关闭时存在未回滚未提交的事务。

normal数据库关闭hang的问题

标签：oracle shutdown 关闭的四种参数

热心网友时间：2022-04-08 00:34

（1）shutdown normal（正常关闭数据库）
在正常关闭情况下，Oracle在关闭数据库前，等待所有与之相连接的用户正常结束其对话。于是在下次启动数据库时，就不需要恢复实例。

（2）shutdown immediate（立即方式关闭数据库）
当选择Immediate关闭方式时，即实现直接关闭。在SVRMGRL中执行shutdown immediate，数据库并不立即关闭，而是在Oracle执行某些清除工作后才关闭（终止会话、释放会话资源），当使用shutdown不能关闭数据库时，shutdown immediate可以完成数据库关闭的操作。
该关闭方式主要用于下列情况：
①马上停电；
②Oracle正在非正规的运行数据库或一个数据库应用。
该方式关闭数据库过程如下：
①Oracle结束当前正在处理的SQL语句；
②回滚未提交的事务；
③Oracle不等待与之相连接的用户退出连接，就直接中断他们，使用这种关闭方式，下次启动数据库时，Oracle应自动执行实例恢复。

（3）shutdown abort（撤消实例方式关闭数据库）
这是一种最快的关闭方式，它主要用于下列情况：
①一分钟后就要停电；
②Oracle正在非正规的运行数据库或一个数据库应用，并且其它的关闭方式失效；
③启动一个数据库实例时碰到问题。
该方式关闭数据库的过程如下：
①Oracle不等待调用完成，直接中断正在处理的SQL语句；
②回滚未提交事物。
使用这种关闭方式，下次启动数据库时，......</B>