Re: V6.0.37 on Solaris 2.2

From: Steve Essery <sessery_at_lucifer>
Date: 22 Aug 93 09:40:19 GMT
Message-ID: <1993Aug22.094019.14208_at_oracle.us.oracle.com>


csoderbe_at_garond.cray.com (Curt Soderberg) writes:
:
:
: We are having trouble getting Oracle to come up after the
: installation. Oracle says it can't attach the SGA when
: doing the start nomount. We are running Oracle 6.0.37
: under Solaris 2.2 on a SparcCenter 2000. If anyone else
: has this up and running we'd like to get a copy of
: your shared memory and semaphore parameters in the /etc/system
: file or any other suggestions would be appreciated.
:

Contact Oracle support and request the libknl.so fix they have for this. Its known as bug XXXXXX or bug 177861.

It is possible to workaround this temporarily but I would recommend getting the correct fix. For this reason I will not detail the workaround. The catch with the workaround is that there are a number of executables which you cannot relink which are used in the install process - these will hang with the workaround in place (though you can workaround these hanging executables by replacing them with shell scripts which perform the same functions).

The problem is basically the 1000 and 2000 machine have a slightly different shared memory architecture to the other machines in Sun's range and Oracle's standard SGA attach address of 0xe0000000 is no good on them - instead an attach address of 0xd000000 must be used.

This isn't normally a problem except where Oracle uses shared libraries. On machines where we use standard archive libraries its just a case of generating a new ksms.o object with the corrected SGA address and archiving that into libknl.a. This approach does not work with shared libraries and the approach I took with the workaround was to create a new shared library out of the ksms.o file and then a replacement liboraext.so shared library which is a collection of other shared libraries (including libknl.so) Whoops!

In future releases I believe that instead of having the ksms.o in libknl.so where we can't touch it, it will be a shared library of its own.

As I said at the start - get the fix from Oracle.


Steve Essery        Unix Support, Oracle UK       In between the velvet lies
                                                  There's a truth that's hard
						  as steel.               JRD
===============================================================================
Received on Sun Aug 22 1993 - 11:40:19 CEST

Original text of this message