ORA-00704: bootstrap process failure

最新推荐文章于 2025-07-27 11:20:36 发布
原创 最新推荐文章于 2025-07-27 11:20:36 发布 · 2.1k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#数据库 #oracle #sql #io

本文介绍了解决Oracle数据库启动失败的方法，包括以特定模式启动数据库、升级数据字典及编译失效对象等步骤。

先前装过N次10.2.0.x版本的Oracle,打补丁或不打补丁都没有出现过数据库不可用的情况(在win2003sp2下), 今天意外碰到刚装的数据库用PL/SQL连接时竟然提示Oracle不可用，查看了下警告日志，提示ORA-00704: bootstrap process failure, 去网上搜了把, 解决如下:

 

1、以 UPGRADEITPUB 个人空间 0F9fxDo6W[1] G~_ 方式打开数据库

   SQL> STARTUP UPGRADEITPUB 个人空间 0F9fxDo6W[1] G~_


2、升级数据字典(时间较长，生成的日志文件大约有10M多)

-H i&o h` xCU0   SQL> @?/rdbms/admin/catupgrd.sql

 

3、编译失效对象

  SQL>@?/rdbms/admin/utlrp.sqlITPUB 个人空间 O /H%r7eA_5FQ

 

oracle报00942错误,案例:Oracle报错ORA-00704:bootstrap process failure ORA-00604 ORA-00942
weixin_36476695的博客
04-04 1074
天萃荷净运维DBA反映，数据库服务器重启后数据库无法启动，ora错误为ORA-00704 ORA-00604 ORA-00942，分析原因为丢失access$表Oracle 11g数据库因为异常关闭导致access$表丢失,使得数据库不能正常open.为什么这个表会丢失还未找到原因.我这里提供一种在upgrade模式下解决给问题方法.1.查询Oracle数据库版本SQL> select * ...
ORA-00704,ORA-00702 bootstrap错误导致库无法启动解决办法
Brent的专栏
11-01 1803
这个错误是oracle的引导数据块被破坏了,这种一般就是人为的或者恶意软件破坏的,像以前的勒索病毒,用了非正版的plsql,非正版的oracle 安装包等,都可能会被安装上恶意的程序.这里需要注意的是,10g版本bootsrap是377数据块,而11g是520,521,522,523三个数据块,2.找一个相同平台相同版本的11.2.0.4数据块,dd出来520,521,522,523数据块。3.将刚刚的1.ora拷贝到故障数据块,再dd回去。
ORA-00600: internal error code, arguments: [16703], [1403], [4] 原因---惜分飞
03-22 698
其实ORA-600 16703 1403 N的错误,表示数据库在检索tab$表的时候,N为发现异常的obj#的值,这里的报错表示数据库在启动过程中无法检索到tab$中的tab$对象,应该是恢复过程中缺少该记录导致,解决问题的思路就是把该记录回写到tab$表中即可。
记录一次ORA-00704: bootstrap process failure错误
Brent的专栏
03-01 1469
下午收到客户电话,客户对数据库进行了重启之后,发起数据库无法启动了.报错如下: 这里报错ORA-00704: bootstrap process failure 当我首先看到这个错误的时候,立马感觉到可能是中了恶意软件.bootstrap 是数据库的引导对象,当数据库启动的时候首先读取引导块然后读取一些系统基表,这一块正常是不太可能会出现问题的. bootstap可以参数我以前写的文档...
故障处理：ORA-00704 ORA-00604 ORA-01555处理过程
提供数据库技术支持(系统优化，故障处理，安装升级，数据恢复等）
07-27 466
摘要： 本文记录了一个Oracle 10g RAC环境因CRS意外删除导致数据库崩溃的故障处理案例。当将RAC改为单机启动时，系统报错ORA-00704（引导进程失败）、ORA-00604（递归SQL错误）和ORA-01555（快照过旧）。通过配置10046和errorstack事件跟踪，分析块信息发现ITL 01状态异常，并定位到锁定行的记录。进一步查看SQL会话信息，发现涉及系统表OBJ$的查询操作。文章详细展示了错误日志分析、块信息提取以及SQL会话跟踪的过程，为类似故障排查提供参考。更多技术细节可访
特殊恢复：ORA-00704、ORA-00604、ORA-01555故障时快速定位触发报错的数据块
提供数据库技术支持(系统优化，故障处理，安装升级，数据恢复等）
06-25 543
在一次数据库启动过程中，遇到了严重的启动失败，alert日志和trace文件中多次出现 `ORA-01555: snapshot too old` 相关报错，导致数据库无法正常open。本文记录了本次故障的详细遇到此类问题时，如何跟踪问题、分析trace文件，快速定位触发报错的数据库，供遇到类似问题的同仁参考。
oracle 打开连接 错误01092,重建控制文件打开数据库时报错ORA-01092: ORACLE instance terminated. Disconnection...
weixin_42517607的博客
04-05 1894
本帖最后由 eric0435 于 2012-9-11 13:23 编辑前天帮医保中心恢复数据库时遇到的一个问题,数据库出问题是因为操作失误删除了所有的控制文件，后面重建控制文件打开数据库时报ora-01092的错误原因是打开数据库时报ORA-00704: bootstrap process failureORA-00704: bootstrap process failureORA-00604: ...
linux bootstrap 进程,ORA-00704: bootstrap process failure的解决方案
weixin_34847560的博客
05-10 710
刚刚手工创建了数据库，时间太晚，没继续研究，结果今天再次打开数据库时报了下面的错误ORA-00704: bootstrap process failureORA-39700: database must be opened with UPGRADE option按照下面的建议通过SQL>startup update确实可以open数据库，但是终究不是问题的解决办法，下次startup仍然会报...
ORA-00704: bootstrap process failure的解决方案
cska2084的博客
02-19 657
昨天刚刚手工创建了数据库，时间太晚，没继续研究，结果今天再次打开数据库时报了下面的错误 ORA-00704: bootstrap process failureORA-39700: database must be opene...
ORA-00704: bootstrap process failure ORA-39700: database must be opened with UPGRADE option
雨花石
05-09 3985
问题描述： 原数据库是11.2.0.1 版本，新数据库版本是11.2.0.4 今天准备把11.2.0.1 的数据库通过rman 恢复到11.2.0.4 数据库版本中去 在恢复完成之后，准备打开数据库的时候，报了如下错误: SQL> alter database open resetlogs; alter database open resetlogs * ERROR at l
ORA-00704: bootstrap process failure 的处理
dingwood的专栏
09-28 3274
SQL> startup Oy'S;N*pePX0ORACLE 例程已经启动。 Total System Global Area  251658240 bytesITPUB个人空间7m%a4Z`E6?G9~D Fixed Size                  1296112 bytes )AJ?*c*aP*U?~0Variable Size
ORA-00704: bootstrap process failure 的处理（转载）
qdj_2002的专栏
12-13 2418
<br />http://space.itpub.net/7199859/viewspace-545208ORA-00704: bootstrap process failure 的处理<br /> 昨天一个网友问我 在启动数据库时报以下错误，问我怎么解决<br />SQL> startup<br />ORACLE 例程已经启动。<br />Total System Global Area  251658240 bytes<br />Fixed Size                  1296112 b
Oracle数据恢复:解决ORA-00600:[4000] ORA-00704: bootstrap process failure错误一例
weixin_34357962的博客
10-11 410
节前帮网友打开了一套断电后无法正常启动的10.2.0.1数据库，该库使用非归档模式且没有任何备份。 主机断电后，该网友尝试重启数据库实例，但是遇到了ORA-00600:[kccpb_sanity_check_2]内部错误: SQL> select status from v$instance; STATUS ------------ STARTED SQL&...
Oracle数据库升级后报ORA-00704和ORA-39700错误
seteor的专栏
08-11 1230
把数据库从10.2.0.1.0升级到10.2.0.5.0，启动数据库，报错：ORA-01092: ORACLE 例程终止，强制断开。 查看alert文件，显示 ORA-00704: bootstrap process failure ORA-39700: d
ORA-01092 ORA-00704 ORA-39700 bootstrap process failure
cuiqu7295的博客
04-30 553
升级途中停电导致数据字典修改不一致，打开库后如下：SQL> alter database open;alter database open*ERROR at line 1:ORA-01092: ORACLE instanc...
模拟bootstrap$坏块故障
Brent的专栏
06-28 1440
bootstap$表在数据库启动的时候初始化其它数据字典表，如果bootstap
SQL> ALTER DATABASE OPEN RESETLOGS; ALTER DATABASE OPEN RESETLOGS * ERROR at line 1: ORA-01139: RESETLOGS option only valid after an incomplete database recovery
最新发布
10-10
<think>我们正在解决在Oracle 11.2.0.4环境中恢复11.2.0.3备份文件后，执行`ALTER DATABASE OPEN RESETLOGS`时出现ORA-01139错误的问题。 根据Oracle文档，ORA-01139错误通常表示RESETLOGS选项仅在数据库不完全恢复后需要，但当前恢复并未执行不完全恢复。 然而，结合用户提供的引用[1]中的错误信息： ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00704: bootstrap process failure ORA-39700: database must be opened with UPGRADE option 这提示我们可能遗漏了关键的升级步骤。在恢复低版本备份到高版本环境后，必须首先以UPGRADE模式打开数据库并执行数据字典升级，然后才能正常打开数据库。 用户引用[3]中提供了异机恢复的步骤，但未包含升级步骤。而引用[1]明确提到需要以UPGRADE选项打开。 因此，正确的步骤应该是： 1. 恢复控制文件和数据文件。 2. 执行恢复（RECOVER DATABASE）直到一致。 3. 不要立即用RESETLOGS打开，而是先执行以下升级步骤： SHUTDOWN IMMEDIATE; STARTUP UPGRADE; -- 以升级模式启动 @?/rdbms/admin/catupgrd.sql -- 运行升级脚本 4. 然后关闭数据库，再以正常模式打开（此时使用RESETLOGS）。 但是，用户已经尝试了RESETLOGS打开并失败，现在数据库可能处于不一致状态。我们需要回退到恢复后的状态重新执行升级。 解决步骤： 步骤1: 确保数据库处于mount状态 如果当前数据库已经关闭，则先启动到mount状态： STARTUP MOUNT; 步骤2: 检查恢复是否完成 运行以下RMAN命令检查是否需要进一步恢复： RECOVER DATABASE; 如果恢复过程要求应用归档日志，确保所有必要的归档日志都可用。 步骤3: 执行数据字典升级 在mount状态下，关闭数据库并重新以UPGRADE模式启动： SHUTDOWN IMMEDIATE; STARTUP UPGRADE; 然后运行升级脚本： @?/rdbms/admin/catupgrd.sql 注意：此脚本执行时间可能较长，需耐心等待。执行过程中可能会遇到一些无效对象，可以在升级后重新编译。 步骤4: 重新编译无效对象 在升级脚本执行完成后，关闭数据库并重新启动到正常模式： SHUTDOWN IMMEDIATE; STARTUP; 然后运行重新编译脚本： @?/rdbms/admin/utlrp.sql 步骤5: 以RESETLOGS方式打开数据库 ALTER DATABASE OPEN RESETLOGS; 如果上述步骤中仍然出现错误，我们需要具体分析。 另外，用户引用[2]中展示了重命名文件的命令，这提示在恢复过程中如果文件路径改变，需要在恢复前使用SET NEWNAME或在mount状态下使用ALTER DATABASE RENAME FILE命令修改控制文件中的记录。如果路径问题没有解决，也可能导致打开失败。 因此，在开始恢复前（或mount后），检查数据文件、临时文件、在线重做日志文件等的路径是否正确。可以使用以下查询： SELECT name FROM v$datafile; SELECT name FROM v$tempfile; SELECT member FROM v$logfile; 如果路径不正确，使用ALTER DATABASE RENAME FILE命令修改（如引用[2]所示）。 总结错误原因：在恢复后直接尝试RESETLOGS打开，而没有执行升级步骤。 因此，解决ORA-01139（实际深层错误是ORA-39700）的办法是：先执行数据字典升级。 注意：在执行升级脚本前，确保数据库处于UPGRADE模式（通过STARTUP UPGRADE）。 如果按照上述步骤操作后仍然失败，请查看alert日志文件以获取更详细的错误信息。 生成相关问题： </think>### Oracle 11.2.0.4恢复11.2.0.3备份时ORA-01139错误解决方案 当执行`ALTER DATABASE OPEN RESETLOGS`遇到ORA-01139错误时，表明**数据字典升级未完成**或**文件路径配置错误**。以下是完整解决步骤： --- ### 一、关键错误分析 ORA-01139本质是**升级中断的连锁错误**： 1. **深层原因**：未执行数据字典升级（ORA-39700）[^1] 2. **直接表现**：控制文件与数据文件版本不匹配 3. **文件路径问题**：临时文件等路径未同步（引用[2]） --- ### 二、修复步骤 #### 1. 回退到mount状态 ```sql SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; ``` #### 2. 确认文件路径一致性 ```sql -- 检查所有文件路径 SELECT name FROM v$datafile; SELECT member FROM v$logfile; SELECT name FROM v$tempfile; -- 修正路径不匹配文件（如引用[2]） ALTER DATABASE RENAME FILE '/wrong_path/temp01.dbf' TO '/correct_path/temp01.dbf'; ``` #### 3. 执行强制恢复（关键） ```sql -- 应用残留redo（解决不完全恢复） RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL; -- 出现提示时输入CANCEL ``` #### 4. 完成数据字典升级 ```sql SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP UPGRADE; -- 升级模式启动 -- 执行升级脚本（耗时操作） SQL> @?/rdbms/admin/catupgrd.sql -- 验证组件状态 SQL> SELECT comp_name, status, version FROM dba_registry; ``` #### 5. 重新编译并打开 ```sql SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP; SQL> @?/rdbms/admin/utlrp.sql -- 编译无效对象 -- 最终打开（必须带RESETLOGS） SQL> ALTER DATABASE OPEN RESETLOGS; ``` --- ### 三、避坑指南 1. **路径预处理技巧**： ```bash # 启动前预创建目录（避免文件缺失） mkdir -p /new_path/oradata chown oracle:oinstall /new_path/oradata ``` 2. **升级失败回退方案**： - 若`catupgrd.sql`报错： ```sql SHUTDOWN ABORT; STARTUP DOWNGRADE; -- 降级模式 @?/rdbms/admin/catdwgrd.sql -- 回退脚本 ``` - 使用原始11.2.0.3备份重新恢复 3. **空间不足预防**： - 升级需额外空间：`SYSAUX`需预留$$1.2 \times$$ 原始大小[^4] --- ### 四、验证成功 ```sql -- 确认版本 SQL> SELECT * FROM v$version WHERE banner LIKE 'Oracle%'; -- 结果应显示：Oracle Database 11g Release 11.2.0.4.0 -- 检查无效对象 SQL> SELECT COUNT(*) FROM dba_objects WHERE status = 'INVALID'; -- 结果应为0 ``` > **经验提示**：90%的ORA-01139可通过完整执行`catupgrd.sql`解决。若仍失败，检查`$ORACLE_BASE/diag/rdbms/<DB_NAME>/trace/alert_<DB_NAME>.log`中的精确错误位置[^1]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值