ORA-7445(kkslod)错误

最新推荐文章于 2021-04-15 14:58:10 发布

ckawt40802

最新推荐文章于 2021-04-15 14:58:10 发布

阅读量117

点赞数

文章标签：数据库

客户数据库升级测试过程中出现了这个错误。

由于升级方案比较复杂，在升级之后运行utlrp.sql的时候出现了这个错误。

SQL*Plus: Release 11.2.0.2.0 Production on Sun Apr 10 15:18:17 2011

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

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工具的退出状态也是不正常的。

其实如果数据库的数据量不是很大，那么可以利用数据泵来进行升级，而没有必要运行这个复杂的升级步骤。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/4227/viewspace-700164/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/4227/viewspace-700164/