- 論壇徽章:
- 59
|
在RHAS3上成功安裝Oracle9204
Oracle Installation Errors
Here is a list of Oracle 9i (9.0.1 & 9.2.0) installation problems and issues. Some issues, errors, problems, and solutions apply only to 9.0.1 and some only to 9.2.0. Since I did not experience all of the problems here, I am not able to verify the correctness of all the solutions. However, I experienced almost all of the problems listed here. If you have other problems and you were able to resolve them, then please drop me an email at webmaster_at_puschitz.com so that I can add it to the list here.
Here is a list of issues issues, errors, problems and solutions:
Log Files
First check always the error logs for 9.2.0 in /tmp/OraInstall (e.g /tmp/OraInstall2002-07-04_09-50-19PM), and for 9.0.1 in /tmp/OraInstall. When you get make problems, check also the file $ORACLE_HOME/install/make.log.
"Various make Problems"
Make sure that gcc is installed on your system:
$ which gcc
/usr/bin/gcc
Here is the command to find the RPM package name for /usr/bin/gcc:
$ rpm -qf /usr/bin/gcc
gcc-2.96-98
Check also the other error messages below. See also Development Packages for more information.
"Error in invoking target install of makefile /opt/oracle/product/9.2.0/ctx/lib/ins_ctx.mk"
I saw this error only when I installed Oracle9iR2 (9.2.0). This was also the only problem I experienced with Oracle 9i R2 on Red Hat 8.0. However, this does not necessarily mean that you won't experience other problems described here.
When I had this problem, the following errors showed up in $ORACLE_HOME/install/make.log:
/lib/libdl.so.2: undefined reference to `_dl_addr@GLIBC_PRIVATE'
/lib/libdl.so.2: undefined reference to `_dl_open@GLIBC_PRIVATE'
/lib/libdl.so.2: undefined reference to `_dl_close@GLIBC_PRIVATE'
/lib/libdl.so.2: undefined reference to `_dl_sym@GLIBC_PRIVATE'
/lib/libdl.so.2: undefined reference to `_dl_vsym@GLIBC_PRIVATE'
This error comes up when the following step is executed:
/usr/bin/make -f ins_ctx.mk install ORACLE_HOME=/opt/oracle/product/9.2.0
Edit the file $ORACLE_HOME/ctx/lib/env_ctx.mk, go to "INSO_LINK =", and add a "$(LDLIBFLAG)dl" to the line and save it.
Here is the full line with the added "$(LDLIBFLAG)dl" flag:
INSO_LINK = -L$(CTXLIB) $(LDLIBFLAG)m $(LDLIBFLAG)dl $(LDLIBFLAG)sc_ca $(LDLIBFLAG)sc_fa $(LDLIBFLAG)sc_ex $(LDLIBFLAG)sc_da $(LDLIBFLAG)sc_ut $(LDLIBFLAG)sc_ch $(LDLIBFLAG)sc_fi $(LLIBCTXHX) $(LDLIBFLAG)c -Wl,-rpath,$(CTXHOME)lib $(CORELIBS) $(COMPEOBJS)
After that hit retry in the error popup.
If this didn't work, then try the following:
Edit the file $ORACLE_HOME/ctx/lib/env_ctx.mk again, go to "INSO_LINK =", remove the above entry you made and add a "`cat $(LIBHOME)/sysliblist`" to the line and save it.
Here is the full line with the added "`cat $(LIBHOME)/sysliblist`" string:
INSO_LINK = -L$(CTXLIB) $(LDLIBFLAG)m `cat $(LIBHOME)/sysliblist` $(LDLIBFLAG)sc_ca $(LDLIBFLAG)sc_fa $(LDLIBFLAG)sc_ex $(LDLIBFLAG)sc_da $(LDLIBFLAG)sc_ut $(LDLIBFLAG)sc_ch $(LDLIBFLAG)sc_fi $(LLIBCTXHX) $(LDLIBFLAG)c -Wl,-rpath,$(CTXHOME)lib $(CORELIBS) $(COMPEOBJS)
After that hit retry in the error popup.
ORA-27123: unable to attach to shared memory segment.
I saw this error only when I installed Oracle 9i R2 (9.2.0).
This error message came up when the Oracle Database Configuration Assistant was running. I executed the following command to temporarily increase the maximum shared memory size:
su - root
# cat /proc/sys/kernel/shmmax
33554432
# echo `expr 1024 \* 1024 \* 1024` >; /proc/sys/kernel/shmmax
# cat /proc/sys/kernel/shmmax
1073741824
#
Then click "Retry" for the Oracle Database Configuration Assistant.
It is recommended to increase the shmmax setting permanently for Oracle9i. So if you want to increase the maximum shared memory size permanently, add the following line to the /etc/sysctl.conf file:
kernel.shmmax=1073741824
For more information on setting shared memory parameters for Oracle, see Setting Shared Memory.
ORA-03113: end-of-file on communication channel
I saw this error when I've run the "Database Configuration Assistant" and "sqlplus". When the "Database Configuration Assistant" gave me this error during Oracle9iR2 (9.2.0) installation on Red Hat 2.1 AS, I simply removed the shared memory segments owned by the Oracle user and I restarted the "Database Configuration Assistant". I'm not sure if this is the right way but it always worked for me. Here is what I did to get the "Database Configuration Assistant" running again:
Database Configuration Assistant:
I executed the ipcs command to get the address of the shared memory segments that have been allocated by Oracle:
$ su - root
# ipcs
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000000 0 root 600 196608 2
0x00000001 32769 root 600 655360 2
0x00000000 458755 oracle 660 4194304 0
0x00000000 491524 oracle 660 33554432 0
0x00000000 524293 oracle 660 33554432 0
0x00000000 557062 oracle 660 33554432 0
0x00000000 589831 oracle 660 33554432 0
0x00000000 622600 oracle 660 33554432 0
0x00000000 655369 oracle 660 33554432 0
0x00000000 688138 oracle 660 33554432 0
0x3ecee0b0 720907 oracle 660 4194304 0
------ Semaphore Arrays --------
key semid owner perms nsems status
------ Message Queues --------
key msqid owner perms used-bytes messages
#
Then I removed all shared memory segments that were owned by the Oracle user during the installation with the following command:
# ipcrm shm 458755 491524 524293 557062 589831 622600 655369 688138 720907
After that I restarted the "Database Configuration Assistant". Once the installation was done I immediately restarted the DB as well.
Caveat: I'm not sure if this procedure can cause any further problems if this is done during the installation. But so far I haven't seen any issues with this approach.
sqlplus:
If you get this problem in connection with sqlplus, then simply make sure that the database is down and exit sqlplus. After that, follow the procedure above by removing all shared memory segments that belong to the Oracle user. To my knowledge, this should not cause any problems.
For more information on shared memory segments, see Determining Which Semaphore Sets and Shared Memory Segments Belong to Each Oracle Database or Instance.
NOTE:
To solve this problem permanently, increase the kernel shmmax size. For more information, see Setting Shared Memory and Setting Shared Memory.
"Error invoking target install of makefile /opt/oracle/product/9.0.1/plsql/lib/ins_plsql.mk"
"Error invoking target install of makefile /opt/oracle/product/9.0.1/precomp/lib/ins-precomp.mk"
"Error invoking target install of makefile /opt/oracle/product/9.0.1/precomp/lib/ins-net-client"
I saw this error only when I installed Oracle 9i (9.0.1). People have sent me emails pointing out that the following solution also works for Mandrake 8.1, Mandrake 8.2, and for SuSE 8.0.
Edit the file $ORACLE_HOME/bin/genclntsh and change the following line:
LD_SELF_CONTAINED="-z defs"
to read:
LD_SELF_CONTAINED=""
After that run the script $ORACLE_HOME/bin/genclntsh as the user "oracle" and not as the user "root". Also make sure you have all the Oracle environments set correctly!
$ su - oracle
$ $ORACLE_HOME/bin/genclntsh
Created /opt/oracle/product/9.0.1/lib/libclntst9.a
$
After that hit Retry in the error dialog window. This always worked for me.
Here is Oracle's official solution for Oracle 9iR1 and 9iR1 iAS on RedHat 2.1 Advanced Server:
http://otn.oracle.com/software/products/oracle9i/files/binutils_readme.html
"Error in invoking target install of make file /opt/oracle/product/9.2.0/network/lib/ins_oemagent.mk"
If you see this error on Red Hat Enterprise Linux 3, follow the guideline at Running Oracle Installation on Red Hat Enterprise Linux Advanced Server 3.
On Red Hat 9 I performed the following steps here when the ORACLE_HOME/install/make.log file contained the error messages:
...
/opt/oracle/product/9.2.0/network/lib/libnmi.a(snmitcln.o)(.text+0x159d): In function `Nls_ScanCmd':
: undefined reference to `__ctype_b'
/opt/oracle/product/9.2.0/network/lib/libnmi.a(snmitcln.o)(.text+0x1603): more undefined references to `__ctype_b' follow
The issue here is that __ctype_b() is actually gone for __ctype_b_loc() because Red Hat uses a new locale model. However, in libc.so, __ctype_b is still exported as compatibility symbol; at least that's the case with RH 9 glibc-2.3.2-5. And here is the reason why some people have this problem with Red Hat 9 and why some don't:
When you bought the Red Hat 9 CDs in a store, then you will probably find glibc-2.3.2-5.i686.rpm on the first CD. This glibc version exports __ctype_b():
$ rpm -ql glibc-2.3.2-5 | grep libc.so
/lib/i686/libc.so.6
/lib/libc.so.6
/lib/tls/libc.so.6
$ nm -a /lib/i686/libc.so.6 | grep __ctype_b
001315f8 D __ctype_b
00022340 T __ctype_b_loc
$ nm -a /lib/libc.so.6 | grep __ctype_b
00133c58 D __ctype_b
000223a0 T __ctype_b_loc
$
But when you downloaded Red Hat 9 from redhat.com or from one of the mirror sites, then you will find glibc-2.3.2-11.9.i686.rpm on the image. This glibc version does not export __ctype_b(). This is also the case with glibc-devel-2.3.2-27.9.i386.rpm.
$ rpm -ql glibc-2.3.2-11.9 | grep libc.so
/lib/i686/libc.so.6
/lib/libc.so.6
/lib/tls/libc.so.6
$ nm -a /lib/i686/libc.so.6 | grep __ctype_b
00131718 D __ctype_b@GLIBC_2.0
000223a0 T __ctype_b_loc
$ nm -a /lib/libc.so.6 | grep __ctype_b
00133d58 D __ctype_b@GLIBC_2.0
000223f0 T __ctype_b_loc
$
Check the glibc version on your system:
First check if the glibc packages on your RH 9 system work with the Oracle installer:
$ rpm -q glibc-2.3.2-5 glibc-common-2.3.2-5 glibc-devel-2.3.2-5
If you got the following error mesages:
package glibc-2.3.2-5 is not installed
package glibc-common-2.3.2-5 is not installed
package glibc-devel-2.3.2-5 is not installed
then you have glibc packages on your system that don't work with the Oracle installer and you need to follow the "Work Around" procedure here.
But if your system has the 2.3.2-5 glibc versions installed, then you are fine and you don't need to follow the described "Work Around" procedure!
Work Around Procedure:
Since I was not able to find the glibc-2.3.2-5 RPMs available for download, I'm making the RPMs available on my website. These RPMs are copies of the glibc RPMs that came with the RH 9 CDs I bought in the store. I do not recommend to use any of the "compat" RPMs from older Red Hat distributions since RH 9 contains major changes.
Here is the procedure for installing glibc-2.3.2-5 temporarely on your RH 9 server:
Download the 2.3.2-5 glibc RPMs from here on my web site.
First make sure if these downloaded RPM's are not corrupt and if they were really built and signed by Red Hat. You never know if someone fiddled with these RPMs or replaced them. To ensure the integrity and origin of these Red Hat's RPMs, run the following commands:
$ su - root
# rpm --import /usr/share/rhn/RPM-GPG-KEY # add Red Hat's PGP public key to the RPM database
# rpm --checksig glibc-2.3.2-5.i686.rpm glibc-common-2.3.2-5.i386.rpm glibc-devel-2.3.2-5.i386.rpm
glibc-2.3.2-5.i686.rpm: (sha1) dsa sha1 md5 gpg OK
glibc-common-2.3.2-5.i386.rpm: (sha1) dsa sha1 md5 gpg OK
glibc-devel-2.3.2-5.i386.rpm: (sha1) dsa sha1 md5 gpg OK
#
Downgrade glibc, glibc-common, and glibc-devel:
# rpm -Uvh --oldpackage glibc-2.3.2-5.i686.rpm glibc-common-2.3.2-5.i386.rpm glibc-devel-2.3.2-5.i386.rpm
If you get the following error:
error: Failed dependencies:
glibc = 2.3.2-11.9 is needed by (installed) glibc-debug-2.3.2-11.9
glibc = 2.3.2-11.9 is needed by (installed) glibc-utils-2.3.2-11.9
glibc-devel = 2.3.2-11.9 is needed by (installed) glibc-debug-2.3.2-11.9
glibc-devel = 2.3.2-11.9 is needed by (installed) nptl-devel-2.3.2-11.9
then you can temporarily remove these RPMs (glibc-debug, glibc-utils, nptl-devel) from your system until you upgrade the glibc RPMs after your Oracle installation:
# rpm -e glibc-debug glibc-utils nptl-devel
Now try to run runInstaller again.
After Oracle has been installed, you can upgrade glibc, glibc-common, and glibc-devel again. For example:
# rpm -Uvh glibc-2.3.2-11.9.i686.rpm glibc-common-2.3.2-11.9.i386.rpm glibc-devel-2.3.2-11.9.i386.rpm
According to Red Hat, binary compatibility in Red Hat Linux is always guaranteed for binaries and shared libraries accross releases, but not for .o files nor .a files. However, compatibility is guaranteed for .o files and .a files. _within_ a realease. Since glibc-2.3.2-5 and glibc-2.3.2-11.9 are from the same release, compatibility should be guaranteed for .o files (Oracle's .o files which have been created during the Oracle installation) and .a files.
This means that Oracle should be fine when you upgrade glibc after the Oracle installation.
If you have any problems or issues with this solution, or if you have any comments, please let me know. You can find my email address at the bottom of this web site.
$ agentctl start
DBSNMP for Linux: Version 9.2.0.4.0 - Production on 07-JAN-2004 19:11:14
Copyright (c) 2003 Oracle Corporation. All rights reserved.
Starting Oracle Intelligent Agent.../opt/oracle/product/9.2.0/bin/dbsnmpwd: line 156: 1855 Segmentation fault nohup $ORACLE_HOME/bin/dbsnmp $*
>;>;$DBSNMP_WDLOGFILE 2>;&1
/opt/oracle/product/9.2.0/bin/dbsnmpwd: line 156: 1868 Segmentation fault nohup $ORACLE_HOME/bin/dbsnmp $* >;>;$DBSNMP_WDLOGFILE 2>;&1
/opt/oracle/product/9.2.0/bin/dbsnmpwd: line 156: 1880 Segmentation fault nohup $ORACLE_HOME/bin/dbsnmp $* >;>;$DBSNMP_WDLOGFILE 2>;&1
/opt/oracle/product/9.2.0/bin/dbsnmpwd: line 156: 1892 Segmentation fault nohup $ORACLE_HOME/bin/dbsnmp $* >;>;$DBSNMP_WDLOGFILE 2>;&1
You are probably trying to start the agent on RH AS 3. See Patching Oracle Intelligent Agent on RH AS 3 how to resolve it.
$ dbca
SIGSEGV 11* segmentation violation
stackbase=0x453da000, stackpointer=0x453d9d5c
Full thread dump:
"AWT-EventQueue-0" (TID:0x411d1e20, sys_thread_t:0x453d9e0c,
state:R) prio=5 *current thread*
java.lang.Object.wait(Object.java)
java.awt.EventQueue.getNextEvent(EventQueue.java:126)
...
I got reports about dbca crashing on Red Hat 8.0 and on Red Hat 9. If this happens, try the following suggestion:
$ su - root
touch /etc/rac_on
Now try to restart dbca.
Another option is to edit $ORACLE_HOME/bin/dbca and to put the following lines under comment except the line marked in blue:
# if [ -f /etc/rac_on ]; then
# Run DBCA
$JRE_DIR/bin/jre -native -DORACLE_HOME=$OH ...
# else
# Run DBCA
# $JRE_DIR/bin/jre -DORACLE_HOME=$OH ...
# fi
Now try to restart dbca.
./runInstaller: line 58: ./runInstaller: cannot execute binary file.
You are probably trying to run a 64-bit Oracle version on a 32-bit Linux system. Make sure you downloaded the right Oracle version for your Linux system.
To check if runInstaller is a 32-bit binary or a 64-bit binary, run the following command:
$ cd /mnt/cdrom
$ file install/linux/runInstaller
install/linux/runInstaller: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), not stripped
To check if your Linux system is 32-bit system or a 64-bit system, run e.g. the following command:
$ file /sbin/init
/sbin/init: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped
The Oracle installer runInstaller hangs at: Installing Java Runtime Environment... Link pending... Copying README...
This problems comes up only on RH 9. You probably forgot to set the environment variable LD_ASSUME_KERNEL to 2.4.1.
To rectify this problem, run the following command and restart runInstaller:
oracle$ export LD_ASSUME_KERNEL=2.4.1
For more information on this issue, see Red Hat 9.
Recovery Manager rman hangs
You are probably running the wrong rman binary which belongs to the XFree86-devel RPM:
$ which rman
/usr/X11R6/bin/rman
Can't find init file for Database "SID".
I saw this error only with Oracle 9i R2 (9.2.0) when It tried to start the database with dbstart.
I copied the init file for my SID "test" from /opt/oracle/admin/test/pfile to $ORACLE_HOME/dbs to get dbstart and dbshut working:
cp /opt/oracle/admin/test/pfile/inittest.ora.642002224936 $ORACLE_HOME/dbs/inittest.ora
"Error in setting permissions of file/directory /opt/oracle/jre/1.1.8/bin/i686/native_threads/.extract_args"
This happens if you didn't burn your CD correctly.
Either you burn your CD again to include dot files or you copy the .extract_args file from your downloaded image to where runInstaller complains it is missing.
"jre was not found in /tmp/OraInstall/jre/bin/i586/green_threads/jre"
You are probably running runInstaller on a 586 machine, or your AMD CPU gets recognized as 586 (e.g. AMD K6-III-400). You can check your machine (hardware) type by executing "uname -m". If you are not running on a 586 or on a AMD machine, try to link jre to java and see if this solves your problem.
To rectify the problem with the 586 machine or with the AMD CPU, create a link for lib and bin from i586 to i686 and make the i686 directories read only. For example:
ln -s /tmp/OraInstall/jre/bin/i686 /tmp/OraInstall/jre/bin/i586
ln -s /tmp/OraInstall/jre/lib/i686 /tmp/OraInstall/jre/lib/i586
chmod u-w /tmp/OraInstall/jre/bin/i686/tmp/OraInstall/jre/lib/i686
Now restart runInstaller.
../jre/bin/i386/native_threads/java: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory
You probably forgot to install the compat-libstdc++ RPM which is a package for "Standard C++ libraries for Red Hat Linux 6.2 backwards compatibility". To rectify this problem, install the compat-libstdc++ RPM. For example on Red Hat 9:
rpm -ivh compat-libstdc++-7.3-2.96.118.i386.rpm
See also Development Packages for more information.
/opt/oracle/jre/1.1.8/bin/../lib/i686/green_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
I experienced this problem when I was running the Database Configuration Assistant dbca on Red Hat 9 without setting the LD_ASSUME_KERNEL environment variable.
To rectify this problem, run the following command on Red Hat 9 and restart dbca:
oracle$ export LD_ASSUME_KERNEL=2.4.1
For more information on this issue, see Red Hat 9.
Other Errors
You might want to check out the Oracle on Linux Discussion Forum. |
|
免費注冊
發(fā)表于 2004-07-09 00:27
ORACLE_HOME/bin
, the "Oracle Net Configuration Assistant" will sometimes hang. Simply stop the Assistant and restart it, or continue the installation. When the rest of the installation is finished, do a "Retry" for "Oracle Net Configuration Assistant". This always worked for me. 
atching Oracle9iR2 on Red Hat AS 3" for information on getting and installing opatch. To verify if opatch is in your $PATH, run the which command: