标签云
asm 恢复 asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (100)
- 数据库 (1,597)
- DB2 (22)
- MySQL (70)
- Oracle (1,463)
- Data Guard (49)
- EXADATA (7)
- GoldenGate (21)
- ORA-xxxxx (158)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (13)
- ORACLE 21C (3)
- Oracle ASM (65)
- Oracle Bug (7)
- Oracle RAC (47)
- Oracle 安全 (6)
- Oracle 开发 (27)
- Oracle 监听 (27)
- Oracle备份恢复 (530)
- Oracle安装升级 (84)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (75)
- PostgreSQL (17)
- PostgreSQL恢复 (5)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (36)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (19)
-
最近发表
- Oracle 19c/21c最新patch信息-202404
- PostgreSQL恢复系列:pg_filedump批量处理
- PostgreSQL部分主要字典信息
- PostgreSQL恢复系列:pg_filedump恢复字典构造
- PostgreSQL 16 源码安装
- ORA-00742 ORA-00312 恢复
- 数据库open成功后报ORA-00353 ORA-00354错误引起的一系列问题(本质ntfs文件系统异常)
- ORA-600 ktsiseginfo1故障
- ORA-00600: internal error code, arguments: [16703], [1403], [4] 原因
- 最近遇到几起ORA-600 16703故障(tab$被清空),请引起重视
- ORA-600 2662快速恢复之Patch scn工具
- TNS-12518: TNS:listener could not hand off client connection
- ora.storage无法启动报ORA-12514故障处理
- 断电引起文件scn异常数据库恢复
- ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
- .[hudsonL@cock.li].mkp勒索加密数据库完美恢复
- 模拟带库实现rman远程备份
- 又一例:ORA-600 kclchkblk_4和2662故障
- Oracle误删除数据文件恢复
- Oracle 19C 备库DML重定向—DML Redirection
月归档:十月 2014
ORA-27069: skgfdisp: 尝试在文件范围外执行 I/O
接到网友技术支持请求,win 2003 ntfs格式文件系统,Oracle 8.1.7版本,主机重启后,数据库无法正常启动,offline datafile 15,数据库open成功,但是datafile 无法正常online,报错为:ORA-27069: skgfdisp: attempt to do I/O beyond the range of the file,请求协助处理
SQL> recover datafile 'D:\ORACLE\ORADATA\ORCL\ZSF_DATA.DBF'; ORA-00283: 恢复会话因错误而取消 ORA-01115: 从文件 15 读取块时出现 IO 错误 (块 # 1030071) ORA-01110: 数据文件 15: 'D:\ORACLE\ORADATA\ORCL\ZSF_DATA.DBF' ORA-27069: skgfdisp: 尝试在文件范围外执行 I/O OSD-04026: 无效的参数经过. (OS 1030071)
使用bbed,成功online datafile 15
Tue Oct 28 16:30:35 2014 ALTER DATABASE RECOVER datafile 15 Tue Oct 28 16:30:35 2014 Media Recovery Datafile: 15 Media Recovery Start Media Recovery Log Recovery of Online Redo Log: Thread 1 Group 1 Seq 245110 Reading mem 0 Mem# 0 errs 0: D:\ORACLE\ORADATA\ORCL\REDO03.LOG Media Recovery failed with error 1115 ORA-283 signalled during: ALTER DATABASE RECOVER datafile 15 ... Tue Oct 28 16:32:53 2014 Shutting down instance (abort) License high water mark = 6 Instance terminated by USER, pid = 1548 Starting up ORACLE RDBMS Version: 8.1.7.0.0. System parameters with non-default values: processes = 600 shared_pool_size = 52428800 large_pool_size = 20971520 java_pool_size = 20971520 control_files = D:\oracle\oradata\ORCL\control01.ctl, D:\oracle\oradata\ORCL\control02.ctl db_block_buffers = 19200 db_block_size = 8192 compatible = 8.1.0 log_buffer = 32768 log_checkpoint_interval = 10000 log_checkpoint_timeout = 1800 db_files = 1024 db_file_multiblock_read_count= 8 max_enabled_roles = 30 remote_login_passwordfile= EXCLUSIVE global_names = TRUE distributed_transactions = 500 instance_name = ORCL service_names = ORCL mts_dispatchers = (PROTOCOL=TCP)(PRE=oracle.aurora.server.SGiopServer) open_links = 4 sort_area_size = 65536 sort_area_retained_size = 65536 db_name = ORCL open_cursors = 500 ifile = D:\oracle\admin\ORCL\pfile\init.ora os_authent_prefix = job_queue_processes = 4 job_queue_interval = 10 parallel_max_servers = 5 background_dump_dest = D:\oracle\admin\ORCL\bdump user_dump_dest = D:\oracle\admin\ORCL\udump max_dump_file_size = 10240 oracle_trace_collection_name= PMON started with pid=2 DBW0 started with pid=3 LGWR started with pid=4 CKPT started with pid=5 SMON started with pid=6 RECO started with pid=7 SNP0 started with pid=8 SNP1 started with pid=9 SNP2 started with pid=10 SNP3 started with pid=11 Tue Oct 28 16:33:01 2014 starting up 1 shared server(s) ... starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'... Tue Oct 28 16:33:02 2014 ALTER DATABASE MOUNT Tue Oct 28 16:33:06 2014 Successful mount of redo thread 1, with mount id 1389958722. Tue Oct 28 16:33:06 2014 Database mounted in Exclusive Mode. Completed: ALTER DATABASE MOUNT Tue Oct 28 16:33:49 2014 ALTER DATABASE RECOVER database until cancel Tue Oct 28 16:33:49 2014 Media Recovery Start Media Recovery Log kcrrga: Warning. Log sequence in archive filename wrapped to fix length as indicated by %S in LOG_ARCHIVE_FORMAT. Old log archive with same name might be overwritten. ORA-279 signalled during: ALTER DATABASE RECOVER database until cancel ... Tue Oct 28 16:34:03 2014 ALTER DATABASE RECOVER LOGFILE 'D:\ORACLE\ORADATA\ORCL\REDO02.LOG' Tue Oct 28 16:34:03 2014 Media Recovery Log D:\ORACLE\ORADATA\ORCL\REDO02.LOG Incomplete recovery applied all redo ever generated. Recovery completed through change %s139866389 Media Recovery Complete Completed: ALTER DATABASE RECOVER LOGFILE 'D:\ORACLE\ORADA Tue Oct 28 16:34:29 2014 alter database datafile 15 online Tue Oct 28 16:34:29 2014 Completed: alter database datafile 15 online Tue Oct 28 16:34:36 2014 alter database open resetlogs RESETLOGS is being done without consistancy checks. This may result in a corrupted database. The database should be recreated. RESETLOGS after incomplete recovery UNTIL CHANGE 139866389 Tue Oct 28 16:34:38 2014 Thread 1 opened at log sequence 1 Current log# 2 seq# 1 mem# 0: D:\ORACLE\ORADATA\ORCL\REDO02.LOG Successful open of redo thread 1. Tue Oct 28 16:34:38 2014 SMON: enabling cache recovery Tue Oct 28 16:34:38 2014 Dictionary check beginning Dictionary check complete Tue Oct 28 16:34:39 2014 SMON: enabling tx recovery Tue Oct 28 16:34:44 2014 Completed: alter database open resetlogs
数据库datafile 15 online成功后,客户操作业务继续发生ORA-600[ktsxs_add2]错误
Tue Oct 28 17:07:42 2014 Errors in file D:\oracle\admin\ORCL\udump\ORA02340.TRC: ORA-00600: 内部错误代码,自变量: [ktsxs_add2], [14], [15], [42534], [5732], [5733], [], [] Tue Oct 28 17:07:53 2014 Errors in file D:\oracle\admin\ORCL\udump\ORA02340.TRC: ORA-00600: 内部错误代码,自变量: [ktsxs_add2], [14], [15], [42534], [5732], [5733], [], [] Tue Oct 28 17:08:03 2014 Errors in file D:\oracle\admin\ORCL\udump\ORA02340.TRC: ORA-00600: 内部错误代码,自变量: [ktsxs_add2], [14], [15], [42534], [5732], [5733], [], [] Tue Oct 28 17:08:16 2014 Errors in file D:\oracle\admin\ORCL\udump\ORA02340.TRC: ORA-00600: 内部错误代码,自变量: [ktsxs_add2], [14], [15], [42534], [5732], [5733], [], [] Tue Oct 28 17:08:23 2014 Errors in file D:\oracle\admin\ORCL\udump\ORA02308.TRC: ORA-00600: 内部错误代码,自变量: [ktsxs_add2], [14], [15], [42534], [5732], [5733], [], [] Tue Oct 28 17:08:31 2014 Errors in file D:\oracle\admin\ORCL\udump\ORA02340.TRC: ORA-00600: 内部错误代码,自变量: [ktsxs_add2], [14], [15], [42534], [5732], [5733], [], [] Tue Oct 28 17:08:38 2014 Errors in file D:\oracle\admin\ORCL\udump\ORA02308.TRC: ORA-00600: 内部错误代码,自变量: [ktsxs_add2], [14], [15], [42534], [5732], [5733], [], []
通过分析相关日志发现是insert插入表报错,很好理解,该库的datafile 15已经超过了系统的限制,现在继续插入数据,因此报错,查询可能异常对象
SQL> col segment_name for a20 SQL> SELECT distinct OWNER, SEGMENT_NAME, SEGMENT_TYPE, A.PARTITION_NAME 2 FROM DBA_EXTENTS A 3 WHERE FILE_ID = 15 4 AND 1030071 <= BLOCK_ID; OWNER SEGMENT_NAME SEGMENT_TYPE ------------------------------ -------------------- ------------------ PARTITION_NAME ------------------------------ ZSF DETAIL TABLE ZSF DETAIL1 INDEX ZSF DETAIL2 INDEX OWNER SEGMENT_NAME SEGMENT_TYPE ------------------------------ -------------------- ------------------ PARTITION_NAME ------------------------------ ZSF DETAIL3 INDEX ZSF DETAIL4 INDEX ZSF FK_RECI_ORD INDEX OWNER SEGMENT_NAME SEGMENT_TYPE ------------------------------ -------------------- ------------------ PARTITION_NAME ------------------------------ ZSF PREPAY1 INDEX ZSF RECEDETAIL1 INDEX
创建新表空间
Create tablespace zsf_new datafile 'D:\ORACLE\ORADATA\ORCL\ZSF_DATA_new01.dbf' size 4096m; alter tablespace zsf_new add datafile 'D:\ORACLE\ORADATA\ORCL\ZSF_DATA_new02.dbf' size 128m autoextend on next 128M maxsize 4096m;
迁移异常对象到新表空间
alter table ZSF.DETAIL move tablespace ZSF_new; alter index ZSF.DETAIL1 rebuild tablespace ZSF_new; alter index ZSF.DETAIL2 rebuild tablespace ZSF_new; alter index ZSF.DETAIL3 rebuild tablespace ZSF_new; alter index ZSF.DETAIL4 rebuild tablespace ZSF_new; alter index ZSF.FK_RECI_ORD rebuild tablespace ZSF_new; alter index ZSF.PREPAY1 rebuild tablespace ZSF_new; alter index ZSF.RECEDETAIL1 rebuild tablespace ZSF_new;
然后对于datafile 15所在表空间增加新文件,因为已经迁移了异常对象,然后resize datafile 15小于8G,关闭自扩展,至此该数据库恢复完成
发表在 非常规恢复
标签为 ktsxs_add2, ORA-00283, ORA-01115, ORA-27069, ORA-600 ktsxs_add2, OSD-04026, skgfdisp
评论关闭
11g中 connect by 语句执行计划改变
从10.2.0.3升级到11.2.0.4的朋友,如果细心会发现,以下sql在11.2.0.4中执行效率变低(该sql主要是获取连接用户获取权限信息)
select privilege#,level from sysauth$ connect by grantee#=prior privilege# and privilege#>0 start with grantee#=:1 and privilege#>0
如果你接触是Oracle版本比较多,而且还比较细心,你可能会进一步发现在11.2.0.2中该条sql是:select /*+ connect_by_filtering */ privilege#, level from sysauth$ connect by grantee#=prior privilege# and privilege#>0 start with grantee#=:1 and privilege#>0 也就是说使用了/*+ connect_by_filtering */提示.我这里通过简单测试说明问题.
在11.2.0.4环境中
14:16:19 SQL> set autot trace exp stat 14:16:20 SQL> set time on 14:16:20 SQL> set timing on 14:16:20 SQL> var a1 number; 14:16:20 SQL> exec :a1:=6; PL/SQL 过程已成功完成。 已用时间: 00: 00: 00.00 14:16:20 SQL> select privilege#,level from sysauth$ connect by grantee#=prior 14:16:20 SQL> privilege# and privilege#>0 start with grantee#=:a1 and privilege#>0 14:16:22 SQL> / 已用时间: 00: 00: 00.01 执行计划 ---------------------------------------------------------- Plan hash value: 2624122540 ------------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 7 | 182 | 3 (34)| 00:00:01 | |* 1 | CONNECT BY NO FILTERING WITH START-WITH| | | | | | | 2 | INDEX FAST FULL SCAN | I_SYSAUTH1 | 618 | 4944 | 2 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("GRANTEE#"=PRIOR "PRIVILEGE#") filter("PRIVILEGE#">0 AND "GRANTEE#"=TO_NUMBER(:A1) AND "PRIVILEGE#">0) 统计信息 ---------------------------------------------------------- 1 recursive calls 0 db block gets 7 consistent gets 0 physical reads 0 redo size 599 bytes sent via SQL*Net to client 520 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 2 sorts (memory) 0 sorts (disk) 1 rows processed
这里可以看出来这里使用的执行计划使用了CONNECT BY NO FILTERING WITH START-WITH,逻辑读为7.
10.2.0.3环境中
14:32:57 SQL> set lines 150 14:33:00 SQL> set autot trace exp stat 14:33:01 SQL> set time on 14:33:01 SQL> set timing on 14:33:01 SQL> var a1 number; 14:33:01 SQL> exec :a1:=6; PL/SQL procedure successfully completed. Elapsed: 00:00:00.00 14:33:01 SQL> select privilege#,level from sysauth$ connect by grantee#=prior 14:33:01 SQL> privilege# and privilege#>0 start with grantee#=:a1 and privilege#>0 ; Elapsed: 00:00:00.00 Execution Plan ---------------------------------------------------------- Plan hash value: 2620769641 ---------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 3 | 24 | 2 (0)| 00:00:01 | |* 1 | CONNECT BY WITH FILTERING| | | | | | |* 2 | INDEX RANGE SCAN | I_SYSAUTH1 | 3 | 24 | 2 (0)| 00:00:01 | | 3 | NESTED LOOPS | | | | | | | 4 | CONNECT BY PUMP | | | | | | |* 5 | INDEX RANGE SCAN | I_SYSAUTH1 | 3 | 24 | 2 (0)| 00:00:01 | ---------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("GRANTEE#"=PRIOR "PRIVILEGE#") filter("PRIVILEGE#">0) 2 - access("GRANTEE#"=TO_NUMBER(:A1) AND "PRIVILEGE#">0) 5 - access("GRANTEE#"=PRIOR "PRIVILEGE#" AND "PRIVILEGE#">0) Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 4 consistent gets 0 physical reads 0 redo size 583 bytes sent via SQL*Net to client 492 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 3 sorts (memory) 0 sorts (disk) 1 rows processed
这里执行计划使用的为CONNECT BY WITH FILTERING,而且逻辑读为4,对于这个sql来说,使用CONNECT BY WITH FILTERING执行效率更高.
这里可以很明显的看到:connect by查询的执行计划从10g的CONNECT BY WITH FILTERING变为了11g中的CONNECT BY NO FILTERING WITH SW (UNIQUE),从而使得执行计划发生改变。但是Oracle一般有个特性,就是当引入新特性之时,一般都会伴随隐含参数或者event来屏蔽新特性.这里也例外,我们可以通过”_optimizer_connect_by_elim_dups” = false和”_connect_by_use_union_all” = “old_plan_mode”来屏蔽11g中关于connect by执行计划的改变,使得执行计划恢复到10G的CONNECT BY WITH FILTERING方式
14:30:45 SQL> alter session set "_optimizer_connect_by_elim_dups" = false; 会话已更改。 已用时间: 00: 00: 00.00 14:30:46 SQL> alter session set "_connect_by_use_union_all" = "old_plan_mode"; 会话已更改。 已用时间: 00: 00: 00.00 14:30:46 SQL> set autot trace exp stat 14:30:46 SQL> set time on 14:30:46 SQL> set timing on 14:30:46 SQL> var a1 number; 14:30:46 SQL> exec :a1:=6; PL/SQL 过程已成功完成。 已用时间: 00: 00: 00.00 14:30:46 SQL> select privilege#,level from sysauth$ connect by grantee#=prior 14:30:46 SQL> privilege# and privilege#>0 start with grantee#=:a1 and privilege#>0 ; 已用时间: 00: 00: 00.01 执行计划 ---------------------------------------------------------- Plan hash value: 2620769641 ---------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 2 | 16 | 2 (0)| 00:00:01 | |* 1 | CONNECT BY WITH FILTERING| | | | | | |* 2 | INDEX RANGE SCAN | I_SYSAUTH1 | 2 | 16 | 2 (0)| 00:00:01 | | 3 | NESTED LOOPS | | | | | | | 4 | CONNECT BY PUMP | | | | | | |* 5 | INDEX RANGE SCAN | I_SYSAUTH1 | 2 | 16 | 2 (0)| 00:00:01 | ---------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("GRANTEE#"=PRIOR "PRIVILEGE#") filter("PRIVILEGE#">0) 2 - access("GRANTEE#"=TO_NUMBER(:A1) AND "PRIVILEGE#">0) 5 - access("GRANTEE#"=PRIOR "PRIVILEGE#" AND "PRIVILEGE#">0) 统计信息 ---------------------------------------------------------- 1 recursive calls 0 db block gets 4 consistent gets 0 physical reads 0 redo size 599 bytes sent via SQL*Net to client 520 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 3 sorts (memory) 0 sorts (disk) 1 rows processed
11.2.0.2中也许是考虑到connect by 不够成熟,因此使用了hint /*+ connect_by_filtering */ 来固定执行计划
14:22:09 SQL> select /*+ connect_by_filtering */ privilege#,level from sysauth$ connect by grantee#=prior 14:22:09 SQL> privilege# and privilege#>0 start with grantee#=:a1 and privilege#>0 14:22:10 SQL> / 已用时间: 00: 00: 00.00 执行计划 ---------------------------------------------------------- Plan hash value: 2620769641 ---------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 7 | 182 | 8 (25)| 00:00:01 | |* 1 | CONNECT BY WITH FILTERING| | | | | | |* 2 | INDEX RANGE SCAN | I_SYSAUTH1 | 2 | 16 | 2 (0)| 00:00:01 | | 3 | NESTED LOOPS | | 5 | 105 | 4 (0)| 00:00:01 | | 4 | CONNECT BY PUMP | | | | | | |* 5 | INDEX RANGE SCAN | I_SYSAUTH1 | 2 | 16 | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("GRANTEE#"=PRIOR "PRIVILEGE#") filter("PRIVILEGE#">0) 2 - access("GRANTEE#"=TO_NUMBER(:A1) AND "PRIVILEGE#">0) 5 - access("GRANTEE#"="connect$_by$_pump$_002"."prior privilege# " AND "PRIVILEGE#">0) 统计信息 ---------------------------------------------------------- 1 recursive calls 0 db block gets 4 consistent gets 0 physical reads 0 redo size 599 bytes sent via SQL*Net to client 520 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 3 sorts (memory) 0 sorts (disk) 1 rows processed
CONNECT BY NO FILTERING WITH SW (UNIQUE)和CONNECT BY WITH FILTERING,没有明显的优劣之分,只有在特定的情况下,进行了实际的测试,选择合适自己的sql的执行计划
数据库启动报ORA-00704 ORA-39714错误解决
数据库启动失败,报ORA-00704、ORA-39714错误
[oracle@www.xifenfei.com ~]$ sqlplus / as sysdba SQL*Plus: Release 12.1.0.1.0 Production on Thu Aug 7 08:15:35 2014 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options SQL> startup ORACLE instance started. Total System Global Area 663945216 bytes Fixed Size 2291808 bytes Variable Size 369100704 bytes Database Buffers 289406976 bytes Redo Buffers 3145728 bytes Database mounted. ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00704: bootstrap process failure ORA-39714: upgrade script utlmmig.sql failed Process ID: 11592 Session ID: 1 Serial number: 5 SQL> startup upgrade SP2-0642: SQL*Plus internal error state 2133, context 3114:0:0 Unsafe to proceed ORA-03114: not connected to ORACLE SQL> exit Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
alert日志报错
Thu Aug 07 07:42:25 2014 SMON: enabling cache recovery Thu Aug 07 07:42:25 2014 Errors in file /u01/app/oracle/diag/rdbms/orcl/ORCL/trace/ORCL_ora_11592.trc: ORA-39714: upgrade script utlmmig.sql failed Thu Aug 07 07:42:25 2014 Errors in file /u01/app/oracle/diag/rdbms/orcl/ORCL/trace/ORCL_ora_11592.trc: ORA-00704: bootstrap process failure ORA-39714: upgrade script utlmmig.sql failed Thu Aug 07 07:42:25 2014 Errors in file /u01/app/oracle/diag/rdbms/orcl/ORCL/trace/ORCL_ora_11592.trc: ORA-00704: bootstrap process failure ORA-39714: upgrade script utlmmig.sql failed Thu Aug 07 07:42:25 2014 Error 704 happened during db open, shutting down database USER (ospid: 11592): terminating the instance due to error 704
通过分析utlmmig.sql脚本知道,数据库在升级bootstrap$之前会先在props$表中插入BOOTSTRAP_UPGRADE_ERROR相关记录,数据库在启动之时会检测该值,如果发现该值存在,数据库只能以upgrade模式启动,清理掉相关记录,数据库即可正常启动
[oracle@www.xifenfei.com ~]$ sqlplus / as sysdba SQL*Plus: Release 12.1.0.1.0 Production on Thu Aug 7 07:42:44 2014 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to an idle instance. SQL> startup upgrade ORACLE instance started. Total System Global Area 663945216 bytes Fixed Size 2291808 bytes Variable Size 369100704 bytes Database Buffers 289406976 bytes Redo Buffers 3145728 bytes Database mounted. Database opened. SQL> delete from props$ where name = 'BOOTSTRAP_UPGRADE_ERROR'; 1 row deleted. SQL> delete from props$ where name = 'LOGMNR_BOOTSTRAP_UPGRADE_ERROR'; 0 rows deleted. SQL> commit; Commit complete. SQL> SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup ORACLE instance started. Total System Global Area 663945216 bytes Fixed Size 2291808 bytes Variable Size 369100704 bytes Database Buffers 289406976 bytes Redo Buffers 3145728 bytes Database mounted. Database opened. SQL>
数据库虽然正常启动成功,但是由于bootstrap$对象升级失败,后续还是有很大风险,建议分析报错原因,解决原因然后继续升级bootstrap$基表