客户数据库升级测试过程中出现了这个错误。
由于升级方案比较复杂,在升级之后运行utlrp.sql的时候出现了这个错误。
SQL*Plus: Release 11.2.0.2.0 Production on Sun Apr 10 15:18:17 2011
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_BGN 2011-04-10 15:18:19
DOC> The following PL/SQL block invokes UTL_RECOMP to recompile invalid
DOC> objects in the database. Recompilation time is proportional to the
DOC> number of invalid objects in the database, so this command may take
DOC> a long time to execute on a database with a large number of invalid
DOC> objects.
DOC>
DOC> Use the following queries to track recompilation progress:
DOC>
DOC> 1. Query returning the number of invalid objects remaining. This
DOC> number should decrease with time.
DOC> SELECT COUNT(*) FROM obj$ WHERE status IN (4, 5, 6);
DOC>
DOC> 2. Query returning the number of objects compiled so far. This number
DOC> should increase with time.
DOC> SELECT COUNT(*) FROM UTL_RECOMP_COMPILED;
DOC>
DOC> This script automatically chooses serial or parallel recompilation
DOC> based on the number of CPUs available (parameter cpu_count) multiplied
DOC> by the number of threads per CPU (parameter parallel_threads_per_cpu).
DOC> On RAC, this number is added across all RAC nodes.
DOC>
DOC> UTL_RECOMP uses DBMS_SCHEDULER to create jobs for parallel
DOC> recompilation. Jobs are created without instance affinity so that they
DOC> can migrate across RAC nodes. Use the following queries to verify
DOC> whether UTL_RECOMP jobs are being created and run correctly:
DOC>
DOC> 1. Query showing jobs created by UTL_RECOMP
DOC> SELECT job_name FROM dba_scheduler_jobs
DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>
DOC> 2. Query showing UTL_RECOMP jobs that are running
DOC> SELECT job_name FROM dba_scheduler_running_jobs
DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>#
DECLARE
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 30660
Session ID: 125 Serial number: 35
ERROR:
ORA-03114: not connected to ORACLE
DOC> The following query reports the number of objects that have compiled
DOC> with errors (objects that compile with errors have status set to 3 in
DOC> obj$). If the number is higher than expected, please examine the error
DOC> messages reported with each object (using SHOW ERRORS) to see if they
DOC> point to system misconfiguration or resource constraints that must be
DOC> fixed before attempting to recompile these objects.
DOC>#
ERROR:
ORA-03114: not connected to ORACLE
DOC> The following query reports the number of errors caught during
DOC> recompilation. If this number is non-zero, please query the error
DOC> messages in the table UTL_RECOMP_ERRORS to see if any of these errors
DOC> are due to misconfiguration or resource constraints that must be
DOC> fixed before objects can compile successfully.
DOC>#
ERROR:
ORA-03114: not connected to ORACLE
ERROR:
ORA-03114: not connected to ORACLE
ERROR:
ORA-03114: not connected to ORACLE
ERROR:
ORA-03114: not connected to ORACLE
ERROR:
ORA-03114: not connected to ORACLE
ERROR:
ORA-03114: not connected to ORACLE
ERROR:
ORA-03114: not connected to ORACLE
SQL> Error 45 initializing SQL*Plus
Internal error
而数据库后台对应的错误信息为:
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x18] [PC:0x8F15D0E, kkslod()+58] [flags: 0x0, count: 1]
Errors in file /u01/app/oracle/diag/rdbms/xe5/XE5/trace/XE5_ora_30660.trc (incident=10937):
ORA-07445: exception encountered: core dump [kkslod()+58] [SIGSEGV] [ADDR:0x18] [PC:0x8F15D0E] [Address not mapped to object] []
Incident details in: /u01/app/oracle/diag/rdbms/xe5/XE5/incident/incdir_10937/XE5_ora_30660_i10937.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
虽然在metalink中没有找到和当前对应的问题描述,不过在了解了这个数据库的升级步骤后,大概知道了这个错误产生的原因。
数据库在升级之前是Oracle 11.1.0.7 for Windows 32bit,采用拷贝数据文件的方式将整个数据库拷贝到Oracle 11.2.0.2 for Linux x86-64平台上,然后重建了控制文件,并利用catupgrd.sql进行升级。
由于出现了32位到64为的改变,因此需要在升级前运行utlirp.sql,而后运行catupgrd.sql最后才是utlrp.sql。
而升级过程中,运行utlrp.sql的时机不对,放到了catupgrd.sql之前,导致了这个错误的产生,同时可以看到,SQLPLUS工具的退出状态也是不正常的。
其实如果数据库的数据量不是很大,那么可以利用数据泵来进行升级,而没有必要运行这个复杂的升级步骤。