再谈DBCA

ochef — Fri, 13 Mar 2009 05:34:15 +0000

前几天有朋友问在DBCA的时候有没有碰到如下类似的错误：

$ dbca
/u01/app/oracle/jre/1.1.8/bin/../lib/i686/native_threads/libzip.so: symbol errno,
version GLIBC_2.0 not defined in file libc.so.6 with link time reference (libzip.so)
Unable to initialize threads: cannot find class java/lang/Thread
Could not create Java VM

我已记不清安装oracle多少次了，但记忆中好像没有遇到过，难道是我运气太好每次都设对了LD_ASSUME_KERNEL参数，做技术的不仅要知其然，而且还要知其所以然，故在metalink上一顿疯狂search，可以参考下面的文档。
Doc ID:243979.1 Doc ID:377217.1 Note:443475.1

这些文档适用于linux 2.4的内核，下面来看看关于LD_ASSUME_KERNEL变量的解释：

Kernel 2.4 comes with a i686 optimized glibc package. The optimized glibc package contains two versions of the libc itself, one with and one without “floating stack” support. Which one an application picks up depends on the setting of the environment variable LD_ASSUME_KERNEL. If this is set to “2.2.5″ the application will use the lib without “floating stack”. Some older java versions do not work correctly if the glibc “floating stack” is used. As a result, “universal installer” and some utilities as “database configuration assistant” will not work if the glibc “floating stack” is activated. On Sues SLES8 for Oracle to scale well, this variable must be set. With a glibc with “floating stack” support Oracle scales significantly worse (number of users) than without (several thousand vs. less than 1000 users in tests).

首先查看提供libc.so.6的RPM:

# rpm -q --whatprovides libc.so.6
  glibc-2.3.4-2.19

可以用find查看libc.so.6的其它版本:

# find /lib/ -name libc.so.6
/lib/libc.so.6
/lib/i686/libc.so.6
/lib/tls/libc.so.6

再查看机器的类型:

# uname -m
 i686

So your system is looking into /lib/i686/libc.so.6 and getting error.

Recommended Settings for Installing Oracle Products

Operating System	LD_ASSUME_KERNEL setting
RHAS 2.1	2.2.5
RHEL3, RHEL4, OEL4	any value from 2.4.1 to 2.4.19
SLES8, SLES9	2.4.21
RHEL5, OEL5, SLES10	Should not be set

DBCA failed when press finish button

ochef — Fri, 13 Mar 2009 03:15:38 +0000

以前安装完oracle，在用DBCA创建数据库时，在配置了一系统列参数之到了最后点”完成”的时候，创建画面异常消失没了任何反映，以前用在网上找到的方法解决如下：
Case：JRE 的版本不对, Oracle 一般使用的JRE是1.1.8到$ORACLE_BASE/jre 目录下，发现Oracle本身已经有1.3.1版的JRE
#ls $ORACLE_BASE/jre
1.1.8/ 1.3.1/
Fix：只要改变一下链接使用1.3.1的JRE就可以了。（可以查看dbca的script）

   1. #rm $ORACLE_HOME/JRE    (此JRE目录是1.1.8 的符号链接)
   2. #ln -s $ORACLE_BASE/jre/1.3.1  $ORACLE_HOME/JRE
   3. #cd $ORACLE_BASE/jre/1.3.1/bin
   4. #ln -s $ORACLE_BASE/jre/1.3.1/bin/.java_wrapper   jre
       OR: #ln -s Java jre
   5. #cd i386/native_threads
   6. #ln -s java  jre

完成以上步骤后再启动dbca问题就解决了。

今天再次遇到该问题，在metalink上查了一下有更好的解决办法：
Doc ID: 292278.1
Fix：
Perform the following steps to correct the defect in DBCA.

Step 1-->
Backup $ORACLE_HOME/bin/dbca shell script
 
Step 2-->
Change only line #124 in the $ORACLE_HOME/bin/dbca script to include -native flag as follows
 
$JRE_DIR/bin/jre -native -DORACLE_HOME=$OH -DJDBC_PROTOCOL=thin -mx64m
-classpath $CLASSPATH oracle.sysman.assistants.dbca.Dbca $ARGUMENTS
 
Step 3-->
Run the root.sh and continue running the configuration assistants
DIFF will something like this.
======================
diff $ORACLE_HOME/bin/dbca $ORACLE_HOME/bin/dbca.ORG
124c124
<$JRE_DIR/bin/jre -native -DORACLE_HOME=$OH -DJDBC_PROTOCOL=thin -mx64m
-classpath $CLASSPATH oracle.sysman.assistants.dbca.Dbca $ARGUMENTS
---
>$JRE_DIR/bin/jre -DORACLE_HOME=$OH -DJDBC_PROTOCOL=thin -mx64m -classpath
$CLASSPATH oracle.sysman.assistants.dbca.Dbca $ARGUMENT

天道酬勤 » dbca

再谈DBCA

DBCA failed when press finish button