1. Oracle启动停止的整体思路1.1 为什么启动停止是个“技术活”刚接触Oracle的朋友往往觉得启动数据库不就是敲个startup、关闭敲个shutdown就完事了。实际在运维一线摸爬滚打几年后你会发现启动和停止Oracle远不是一条命令那么简单。一个生产库动不动几百GB到数TB涉及的组件包括实例Instance、监听器Listener、ASM实例、集群软件Clusterware、数据守护Data Guard等。启动停止的顺序错了、模式选错了轻则业务连接报错重则数据文件损坏、实例崩溃甚至触发长达数小时的恢复流程。这套操作是所有Oracle DBA的必修课也是日常巡检、版本升级、硬件维护、机房迁移时最高频的操作。它适合谁不管是刚入门的运维新人、做开发需要本地起库的研发同学还是维护着几十套库的资深DBA都应该把“启动停止”背后的原理和每一种方式的适用场景吃透。1.2 Oracle实例的生命周期先把这个概念捋清楚Oracle数据库由“实例Instance”和“数据库Database”两部分组成。实例是内存结构SGA加后台进程PMON、SMON、DBWn、LGWR等的组合数据库则是磁盘上的控制文件、数据文件、重做日志文件、参数文件等物理文件。平时我们说的“启动数据库”完整流程实际是先启动实例、再挂载控制文件、最后打开数据文件。停止则是倒过来先关闭数据文件、卸载控制文件、再关掉实例。这个过程对应三种模式SHUTDOWN NORMAL正常关闭、SHUTDOWN TRANSACTIONAL事务级关闭、SHUTDOWN IMMEDIATE立即关闭、SHUTDOWN ABORT强制终止。后面我会逐一掰开讲。理解了生命周期再去看不同环境下的操作命令就不会被各种报错搞得晕头转向。2. 单机环境SQLPlus方式2.1 启动数据库的完整步骤单机环境是最简单也最经典的环境sqlplus方式仍是所有进阶操作的基础。先讲标准流程再讲几个容易踩坑的细节。首先切换到Oracle用户设置好环境变量su - oracle export ORACLE_HOME/u01/app/oracle/product/19.0.0/dbhome_1 export ORACLE_SIDorcl export PATH$ORACLE_HOME/bin:$PATH然后以SYSDBA身份登录sqlplus / as sysdba登录后如果直接敲startup大多数情况能正常起来。但更稳妥的做法是先看实例状态再做启动SQL select status from v$instance;如果返回STARTED或MOUNTED说明实例没有完全关闭需要根据情况退出到当前状态再启动。完整启动推荐分步操作让每一步都能看到反馈SQL startup nomount; -- 实例创建完成读参数文件分配SGA启动后台进程 SQL alter database mount; -- 加载控制文件让实例与数据库文件建立关联 SQL alter database open; -- 打开数据文件和重做日志对外提供服务实际工作中我更喜欢直接敲startupOracle会按nomount、mount、open的次序自动执行。分步启动主要用于故障排查比如控制文件损坏时可能只能走到mount阶段。启动完成后建议立刻检查alert.log和监听状态。日志路径通常在$ORACLE_BASE/diag/rdbms/{db_name}/{SID}/trace/alert_{SID}.log。我见过太多人启动成功就跑去喝茶结果两小时后业务说连不上一查发现监听根本没起。2.2 关闭数据库的几种模式关闭的命令就一条但参数选择非常关键。先给出对比表关闭模式并发事务是否等待是否产生检查点能否用ABORT后自动恢复适用场景NORMAL等待所有会话主动断开是能计划内维护允许长时间等待TRANSACTIONAL等待正在执行的事务完成但不允许新事务是能生产环境需要让业务优雅退出IMMEDIATE正在执行的SQL立即终止回滚未提交事务是能最常见日常重启首选ABORT不等待立即终止实例否需要做实例恢复故障应急最后手段逐个说。SHUTDOWN NORMAL是最温柔的关闭方式但它会一直等所有客户端断开会话。如果某台应用服务器的连接池没释放这个命令可能挂几个小时。我遇到过一次半夜执行shutdown normal第二天早上还没关完快速检查才发现有个遗留的PL/SQL会话一直挂着。SHUTDOWN TRANSACTIONAL的设计意图是等待正在执行的事务结束并提交/回滚然后断开连接不允许再有新事务。它介于NORMAL和IMMEDIATE之间适合那种“希望业务干净退出”的场合但实际生产中使用较少因为等待时长同样不可控。SHUTDOWN IMMEDIATE是生产环境用得最多的关闭模式。它不会等会话主动断开而是直接终止正在执行的SQL、回滚未提交的事务然后做检查点、关闭数据文件。对于绝大多数正常维护场景这个模式都够用回滚操作通常很快我在实际库上执行IMMEDIATE关闭从几百个活跃会话到完全关停一般几十秒内完成。SHUTDOWN ABORT是灾难模式。Oracle会直接杀死后台进程、释放内存不做检查点不关数据文件。下次启动时Oracle会基于重做日志做实例恢复。这个命令只适合“数据库已经卡死、正常命令无响应”或者“机房断电”这种极端情况。注意ABORT后数据文件出现丢失或损坏的表象很常见不用慌只要控制文件和所有数据文件都在启动时自动前滚回滚就能恢复。2.3 监听器的启停和常见坑监听器是客户端连接数据库的第一道门单独启停的场景非常多。最常用的是lsnrctl工具lsnrctl start lsnrctl stop lsnrctl statusstart会读取$ORACLE_HOME/network/admin/listener.ora配置默认监听名是LISTENER端口通常1521。实际运维中最常见的三个坑第一个坑是环境变量没配对。lsnrctl依赖于ORACLE_HOME如果当前用户的环境变量指错了ORACLE_HOME启动的监听可能是另一套的配置。第二个坑是端口被占用。1521端口已经被别的监听或其他程序占用时lsnrctl start会报TNS-12541或TNS-01106。我的排查习惯是netstat -an | grep 1521 lsof -i :1521确定占用进程后要么改监听端口要么停掉占用程序。第三个坑是监听起来了但数据库状态没注册上。如果数据库在监听之前启动或者监听重启后没有重新注册lsnrctl status可能看不到任何服务。可以通过在SQLPlus里执行alter system register;手动触发注册或者等PMON后台自动注册可能需等待60秒以上。3. 集群环境SRVCTL方式3.1 从RAC实战出发单机环境掌握了面对RACReal Application Clusters时的最大变化是不能直接用sqlplus在节点上随意启停更不能用shutdown abort去重启某个节点的实例而不通知集群软件。RAC环境下集群软件GIGrid Infrastructure负责监控和管理所有节点上的资源包括监听、ASM实例、数据库实例、VIP等。标准做法是用srvctl来统一控制。看数据库的整体状态crsctl status resource -t看某个数据库的配置和状态srvctl config database -d orcl srvctl status database -d orcl输出会列出实例名和对应节点类似Instance orcl1 is running on node db01 Instance orcl2 is running on node db02启动整个数据库集群服务srvctl start database -d orcl停止整个数据库集群服务srvctl stop database -d orcl只停某个节点srvctl stop instance -d orcl -i orcl1只启动某个节点srvctl start instance -d orcl -i orcl1srvctl的好处是它会自动处理依赖关系比如启动数据库前会先确保ASM实例和监听可用停止时也会按依赖顺序优雅处理。这就规避了人工操作时“先停监听还是先停实例”的混乱。3.2 启动停止顺序的选择围绕RAC启停顺序网上争论不少。我给出符合集群软件设计原理的推荐顺序。整体停机维护时的顺序适用于需要关闭整个集群的场合停止应用层的客户端连接或让连接池失效防止新请求进来。停止数据库实例列表优先使用srvctl stop database -d orcl。停止监听器可停可不听依赖于是否维护监听相关配置。关闭ASM实例。停止集群软件使用crsctl stop cluster -all对所有节点统一执行或crsctl stop cluster -n 节点名在某一节点上执行仅停止该节点。断电或做硬件维护。如果是单节点维护只需要在对应节点上操作但要注意确认该节点上没有活动连接。特别注意正常情况下不应该直接kill掉Oracle进程来停止RAC节点实例这会让集群软件判定实例异常可能触发另一节点的接管逻辑严重时导致整个集群抖动。启动集群的顺序是反过来的确认硬件和网络正常。启动集群软件crsctl start cluster -all。检查集群资源状态确保crsctl status resource -t中ora.asm、ora.evmd、ora.cssd等在线。通过srvctl start database -d orcl启动数据库。检查告警日志确认实例状态。开放应用连接或唤醒连接池。有人会问RAC能不能直接用sqlplus shutdown immediate停掉某个实例能但集群软件很快会把实例重新拉起来或者标记资源异常。所以除非你明确要测试故障切换否则别这么搞。3.3 状态检查方法论RAC环境出了问题时状态检查要形成一套固定的肌肉记忆。我自己的检查顺序如下先看集群crsctl status resource -t再逐个数据库看实例状态srvctl status database -d orcl然后看监听是否正常注册lsnrctl status最后检查ASM实例srvctl status asm -a这套顺序能快速定位“数据库实例没起”还是“集群资源挂了”还是“监听没注册”。我处理过的案例中大约三成问题出在ASM实例未随集群启动两成出在监听未重新注册剩下的是数据库实例自身故障或网络问题。有了这套方法论排障效率会高很多。4. Windows环境与图形化工具4.1 Windows服务启停Windows下Oracle通常安装为系统服务服务名一般是OracleService{SID}和OracleOraDB19Home1TNSListener之类的格式。在服务管理器services.msc里找到对应服务右键启动、停止、重启这算是最直白的方式。命令行方式更适合批量操作和脚本化net start OracleServiceORCL net stop OracleServiceORCL net start OracleOraDB19Home1TNSListener net stop OracleOraDB19Home1TNSListener注意服务名区分大小写吗Windows服务名实际上不区分大小写但精确匹配不容易出错。可以用sc query来查看服务名和状态sc query | findstr /i oracleWindows和Linux一个很大的差异是关闭方式。Windows服务管理器点“停止服务”时后台触发的大致相当于SHUTDOWN IMMEDIATE但因为Windows服务机制的限制服务可能长时间停在“正在停止”状态。这通常意味着有会话没有断开或者某个后台进程在执行长事务。此时不要反复点停止更不要直接结束进程先在数据库端查活跃会话select sid, serial#, status, sql_id, event from v$session where username is not null;如果确认是残留会话导致无法停止可以杀掉会话alter system kill session sid,serial# immediate;4.2 图形化IDE的辅助很多开发用户习惯用PL/SQL Developer、DBeaver、Navicat连接Oracle。这类工具能执行SQL和建表但启动和停止实例的操作依赖工具是否内置了管理员功能。比如PL/SQL Developer的“Commands”窗口可以执行startup、shutdown但前提是连接时用了SYSDBA权限。DBeaver需要创建Oracle驱动里配置SYSDBA角色连接连接方式选SYSDBA或SYSOPER才能执行实例级操作。不过我的建议是图形化工具适合学习和开发环境生产环境操作尽量回到命令行。图形工具一旦连接异常、内存占用或版本兼容出问题会干扰你对故障本身的判断。另外很多运维事故是在GUI里手滑执行的命令行反而能让你更清楚地意识到自己在敲什么。4.3 OEM云控制Oracle Enterprise ManagerOEM是Oracle官方的图形化管理平台适合企业级多套数据库统一管理。通过OEM的“数据库目标”界面可以在线执行启动、停止、刷新状态等操作。OEM云控制还提供了审计功能可以查谁在什么时间执行了启停操作这个对生产环境的合规管理很有价值。不过OEM也需要一套独立的部署和维护成本小型环境往往用不到。我的观点很直接一两套库的环境老老实实用srvctl和sqlplus就足够不必为了“看到可视化按钮”而引入OEM。5. 特殊组件与维护模式5.1 ASM实例的管理如果数据库文件存放在Oracle ASM中单机切换或集群切换时还需要管理ASM实例。ASM实例本身没有数据文件它的作用是管理磁盘组、提供卷管理功能。ASM实例的启动停止通常由集群软件自动管理手动操作时需要小心。在RAC环境ASM实例状态查询srvctl status asm -a启动ASM实例srvctl start asm -n 节点名停止ASM实例srvctl stop asm -n 节点名在单机环境中可能用sqlplus启动sqlplus / as sysasm SQL startup; SQL shutdown immediate;注意登录ASM实例要使用/ as sysasm或/ as sysdbaSysDBA在ASM实例中在很多版本里权限不足。如果弄错了权限启动时会报ORA-01031: insufficient privileges解决方式就是确认/etc/oracle/olr或/u01/app/11.2.0/grid下用户组配置正确。5.2 Data Guard备库的启停Data GuardDG环境下备库的启动停止遵循同样的SQL命令但操作顺序有讲究。正常打开备库到任一模式均可但DG主备切换前需要重点确认备库是否处于APPLYING日志的状态。如果备库停止了日志应用主库就要不断堆积归档日志可能撑满磁盘。查看DG状态select database_role, open_mode from v$database; select process, status from v$managed_standby;期望输出类似PRIMARY READ WRITE ARCH CONNECTED MRP0 APPLYING_LOG对于物理备库启动MRP进程应用日志alter database recover managed standby database using current logfile disconnect from session;停止日志应用但保持实例运行alter database recover managed standby database cancel;关闭备库时直接shutdown immediate即可只要备库不在应用日志过程中出现异常重启后MRP通常会自动重新连接主库并继续应用。如果备库关闭时有事务没有应用完成重启后日志会自动从断点继续。5.3 静默启动与限制模式实际操作中还有两种特殊场景需求。第一限制模式启动。startup restrict允许只有具备RESTRICTED SESSION权限的用户连接数据库。这个模式适合做数据迁移、导入导出、结构变更前的维护。如果数据库已经打开想进入限制模式alter system enable restricted session;操作结束后解除alter system disable restricted session;第二静默启动。startup命令后面可以加PFILE参数指定参数文件路径比如使用备份的参数文件启动startup pfile/u01/app/oracle/pfile_backup.ora;这个方法常用于SPFILE损坏、需要从备份参数文件恢复的紧急场景。6. 常见问题与排查实录6.1 启动报错的经典场景这里整理几个高频启动报错我按出现频率排序。ORA-01033: Oracle initialization or shutdown in progress。这个报错有两层含义。第一层是实例真的还在启动比如nomount到open之间此时等几秒即可第二层是实例已经关闭但连接池、监听器还残留旧状态客户端拿到的还是旧连接。排查方式sqlplus / as sysdba select status from v$instance; select open_mode from v$database;如果实例状态是MOUNTED或OPEN而客户端仍报此错刷新监听注册、重启监听器通常能解决。ORA-01034: ORACLE not available / ORA-27101: shared memory realm does not exist。这个多半是实例没有启动或者环境变量不对。先登录实例看看状态在nomount状态执行alter database mount; alter database open;试试。如果实例起不来还要看告警日志里的具体报错。ORA-01109: database not open。这条容易理解实例在MOUNTED状态或者关闭状态。数据库可以直接执行alter database open;来打开。ORA-12514: TNS listener does not currently know of service requested in connect descriptor。这是监听相关问题。可能性有三服务没注册到监听、监听配置写错、数据库实例尚未打开。先lsnrctl status确认有没有对应的SERVICE没有就执行alter system register;再不行重启监听。6.2 排查工具和日志体系启动停止相关的排查最核心的工具是告警日志alert log。从Oracle 11g开始使用ADRAutomatic Diagnostic Repository管理日志查看告警日志的命令select value from v$diag_info where name Diag Alert;得到路径后直接tail -200 alert_{SID}.log。告警日志里会有每一阶段的启动记录比如控制文件读取、数据文件检查、重做日志打开等。启动失败时真正的根因通常就在告警日志的最后几十行。跟踪文件trace file排查后台进程问题很有用比如某个后台进程崩溃时的pmon_*.trc、smon_*.trc等。实操中不一定每次都能从trace里看出根因但结合alert log一起看基本不会跑偏。另外crsctl status resource -t这条命令在RAC环境特别有用。它能显示每个资源的目标状态TARGET)和当前状态STATE当状态不一致时比如TARGET是ONLINE但STATE是OFFLINE说明集群软件已经尝试拉起资源但失败了这时候要看对应资源的日志。6.3 我这几年攒下来的实操经验写到这里分享几条只有动手碰过才能体会的经验。第一停机前先拍快照或备份控制文件。虽然不是每次都需要但数据量不大时alter database backup controlfile to trace as /tmp/ctrl.sql;这个操作成本极低却在控制文件故障时能救命。第二梳理一套“启停检查清单”。我自己的清单包括停机前确认当前是否有长时间运行的批处理或定时任务记录当前监听端口和SERVICE_NAME停机后验证实例状态和告警日志启动前确认磁盘空间充足启动后检查监听注册和连接成功率。这套清单看着简单但在凌晨两点的故障处理现场它能防止你漏掉关键步骤。第三禁止频繁用ABORT模式关闭数据库。有些新手图省事遇到慢关闭就直接ABORT导致每次启动都要实例恢复。一次两次没问题频繁操作会增加控制文件、数据文件头部损坏的风险。第四别忘了dba_registry组件的状态。启动完成后有空可以查询一下select comp_name, status from dba_registry;如果某个组件状态是UPGRADED或INVALID即使实例状态是OPEN应用也可能访问异常。这时需要结合组件日志和utlrp.sql脚本做恢复但那是另外的话题了。最后再分享一个小技巧。启动数据库之前先tail -f告警日志然后在另一个终端执行startup这样你能实时看到启动各阶段是否正常。很多隐藏的文件级报错会在阶段加载时显现比启动完成后回头翻日志更直观。我自己执行所有生产环境的启动操作时都保留这个习惯它能让我在几秒内判断启动是否真的正常而不是看到Database opened就觉得万事大吉。