SecureCRT开了多个窗口，结果一不小心，疏忽之下在一个生产服务器上执行了shutdown immediate命令，大概过了6到7秒，发现该命令还没有响应，我才发现我这个命令执行错了服务器。一惊之下，想都没有想直接CTRL+C想中断这个操作。 SQL shutdown immeidate;
创新互联专注于鱼峰企业网站建设,响应式网站建设,商城网站建设。鱼峰网站建设公司,为鱼峰等地区提供建站服务。全流程定制网站开发，专业设计，全程项目跟踪，创新互联专业和态度为您提供的服务
SP2-0717: illegal SHUTDOWN option
SQL shutdown immediate;
^C^C^C^C^C
ORA-01013: user requested cancel of current operation
clip_image001
于是我在另外一个窗口里面查看了一下告警日志文件，发现数据库已经关闭了一些进程。大体情况如下所示
tail -40f alert_SCM2.log
Wed Aug 6 17:54:37 2014
ARCH shutting down
ARC8: Archival stopped
Wed Aug 6 17:54:42 2014
ARCH shutting down
ARC7: Archival stopped
Wed Aug 6 17:54:47 2014
ARCH shutting down
ARC6: Archival stopped
Wed Aug 6 17:54:52 2014
ARCH shutting down
ARC5: Archival stopped
Wed Aug 6 17:54:57 2014
ARCH shutting down
ARC4: Archival stopped
Wed Aug 6 17:55:05 2014
CLOSE: Error 1013 during database close
Wed Aug 6 17:55:05 2014
SMON: enabling cache recovery
SMON: enabling tx recovery
Wed Aug 6 17:55:05 2014
ORA-1013 signalled during: ALTER DATABASE CLOSE NORMAL...
Wed Aug 6 17:55:07 2014
ARCH shutting down
ARC2: Archival stopped
Wed Aug 6 17:55:12 2014
ARCH shutting down
ARC1: Archival stopped
Wed Aug 6 17:55:17 2014
ARC3: Becoming the heartbeat ARCH
ARC3: Archiving disabled
ARCH shutting down
ARC3: Archival stopped
Wed Aug 6 17:55:17 2014
ARCH shutting down
Wed Aug 6 17:55:17 2014
ARC0: Archival stopped
Wed Aug 6 17:55:18 2014
Thread 1 closed at log sequence 97562
Successful close of redo thread 1
^C
于是立马查看数据库的状态，看看是否正常，结果如下所示，出现了ORA-00604、ORA-00376、ORA-01110等错误。
SQL SQL SQL select status from v$instance;
select status from v$instance
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 2
ORA-00376: file 1 cannot be read at this time
ORA-01110: data file 1: '/u01/oradata/SCM2/system01.dbf'
clip_image002
一惊之下，立马退出了会话，重新登录后（当时不怎么冷静，慌忙之下已经不谈定了）
sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Wed Aug 6 17:57:11 2014
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected.
SQL select status from v$instacne;
select status from v$instacne
*
ERROR at line 1:
ORA-01012: not logged on
SQL shutdown immdeiate;
SP2-0717: illegal SHUTDOWN option
SQL exit
Disconnected
SQL shutdwon immeidiate;
SP2-0734: unknown command beginning "shutdwon i..." - rest of line ignored.
SQL shutdown immediate;
ORA-24324: service handle not initialized
ORA-24323: value not allowed
ORA-01089: immediate shutdown in progress - no operations are permitted
clip_image003
此时告警日志里面有大量的这类错误。
clip_image004
无奈之下，我只能使用shutdown abort命令了，这时候我反而冷静下来。但是居然报ORA-01031: insufficient privileges 错误，立马退出然后重新登录后，将数据库关闭然后重新启动。
SQL shutdown abort
ORA-01031: insufficient privileges
sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Wed Aug 6 18:15:00 2014
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected.
SQL shutdown abort
ORACLE instance shut down.
SQL startup
ORACLE instance started.
Total System Global Area 7516192768 bytes
Fixed Size 2095640 bytes
Variable Size 5167384040 bytes
Database Buffers 2298478592 bytes
Redo Buffers 48234496 bytes
Database mounted.
Database opened.
SQL exit
重新启动后，监控告警日志，发现没有异常出现，逐个检查后发现没有什么问题，一颗悬着的心才淡定下来。不过还是要总结一下：这是一次低级失误，也是印象比较深的一次失误，我之所以要记录下来，一来这也是一个案例，二来要自己谨记于心。整个过程中，发现自己一直不冷静、不谈定。其实本来已经shutdown了数据库，那应该先冷静分析一下，到底是等数据库关闭后重新启动，还是中断这个进程。 本身ORACLE数据库已经关闭了一些进程，如果此时中断shutdown 进程，明显是个不明智的决定。错误的决策导致后面一系列问题的出现，典型的修为不够！ 老大给我的邮件叫我下次应该 relax, calm down and be careful 。 谨记于心。
1、由于oracle运行在Linux系统里面，第一步，我们要连接Linux系统。
2、然后我们转换到oracle安装用户里面。 我的是 oracle。
3、然后我们运行oracle的环境里的变量， 用来输入相关命令。
4、进去oracle的控制台。输入一个命令： sqlplus / as sysdba。
5、如果要启动数据库，就输入命令： startup。
6、如果关闭数据库， 就输入命令： shutdown immediate。
连接第一台服务端未成功的原因应该是没有配置好listener，或者listener
没有打开。
首先、找到出现ORA-03135连接丢失的那个客户端所在机器上的sqlnet.ora文件
然后、修改或者添加一行SQLNET.EXPIRE_TIME=15
如果、有防火墙空闲检测周期分钟的话相应缩小到期设置以内，如10、5让他和服务器强制握手保持连接激活。
当然、要看现在的中断究竟报的是不是常见的这个连接丢失的错误
注意、对于非连接池又频繁发起很多连接的数据库要谨慎保持长连接
1、正常关闭
正常关闭数据库所用的选项是normal，数据库在关闭前将检查所有的连接，并且发出命令后不允许再有新的用户连接，在等待所有连接都断开后再关闭数据库，再次启动数据库不需要任何恢复过程。
联入sys用户
sqlshutdown normal;
2、紧急关闭
该方式用在某些紧急的情况下，比如通知马上停电，此时需要紧急关闭数据库以应付这些情况。这种方式用的选项是immediate，在这种方式下并不等待所有的用户断开连接再关闭，而是由系统断开连接，然后关闭数据库。
sqlshutdown immediate;
一旦执行了这条命令，则将当前正在处理的sql语句马上停止，然后将所有未提交的事务回退，并且不等待当前联入数据库的用户断开连接，而是由系统强行将各个联接断开。在下次启动数据库时要执行恢复动作，不过是由系统自动执行的，用户不必去了解它。
3、异常关闭
异常关闭选项是abort，此种方式下系统并不做任何检查和断开用户操作以及回退操作，而是直接将数据库现场撤销，这样现场中的数据库数据当然就无效了，数据库自然也就被关掉了。
sqlshutdown abort;
以abort方式关闭数据库时只有一行关闭信息表示关闭了数据库现场。以abort方式关闭的数据库再次启动时必须要进行恢复动作，这些恢复操作同样是系统自动来完成的，需要的时间较长。
在ORACLE中停止一个JOB的方法如下：
首先确定要停止的JOB号，在10g中可通过Dba＿Jobs＿Running进行确认。
查找正在运行的JOB：
selectsidfromdba＿jobs＿running；
查找到正在运行的JOB的spid：
selecta．spidfromv＄processa，v＄sessionbwherea．addr＝b．paddrandb．sidin（selectsidfromdba＿jobs＿running）；
Broken确认的JOB，注意使用DBMS＿JOB包来标识你的JOB为BROKEN。
SQL EXEC DBMS_JOB.BROKEN(job#,TRUE);
注意：当执行完该命令你选择的这个JOB还是在运行着的。
Kill对应的OracleSession，应为BROKEN后该JOB还在运行，如果要求该JOB立刻停止，就需要找到该job的对应SESSION（SID，SERIAL＃），然后执行以下命令：
ALTERSYSTEMKILLSESSION‘sid，serial＃＇；
或者直接KILL对应的操作系统的SESSION。
如果使用ALTERSYSTEMKILLSESSION执行很长时间，其实可以使用OS的命令来快速KILL掉SESSION．ForWindows，attheDOSPrompt：
orakill sid spid；For UNIX at the command line kill –9 spid。
检查要停止的JOB是否还在运行，其实多数情况下，应该都已经停止了。尤其执行的第三步的“杀手”命令。
如果真的还是没有停止，只好从第一道第三步重新做一下了。
将JobQueueProcesses的数目修改为0，首先确认当前的JobQueueProcesses的数目：
SQL col value for a10SQL select name,value from v$parameter where name =’job_queue_processes';
然后将JobQueueProcesses的数目修改为0。
SQL ALTER SYSTEM SET job_queue_processes = 0;
保证所有的JOB都会停止。修改要修改的任何东西，甚至是JOB内的内容，修改完成后，将job的BROKEN状态停止。
SQLEXEC DBMS_JOB.BROKEN(job#,FALSE):
恢复job＿queue＿processes的原始值：
ALTERSYSTEMSETjob＿queue＿processes＝original＿value；
至此整个停止并修改JOB完成。
但是需要另外注意一下的是，在MARK一个BROKEN状态的时候，因为JOB内部执行SQL的原因，所以执行时或许要“煎熬”一段时间。所以在建立JOB时一定要仔细考虑，同时如果可能可以在你设计的PL／SQL代码中，增加一些判断“停止信号”的部分。来避免费力执行上面的步骤。
扩展资料：
很多时候遇到某个session一直处于active，使得CPU一直处于搞使用状态，虽然kill了，但是却不能够使得使得线程结束。killsession只是kill这个进程，但是线程一直处于活动状态。需要真正的kill线程才能够解决cpu使用率高的问题。
Oracle数据库最新版本为OracleDatabase19c。Oracle数据库12c引入了一个新的多承租方架构，使用该架构可轻松部署和管理数据库云。
此外，一些创新特性可最大限度地提高资源使用率和灵活性，如OracleMultitenant可快速整合多个数据库，而AutomaticDataOptimization和HeatMap能以更高的密度压缩数据和对数据分层。
这些独一无二的技术进步再加上在可用性、安全性和大数据支持方面的主要增强，使得Oracle数据库12c成为私有云和公有云部署的理想平台。
参考资料：百度百科-Oracle数据库
