Monday, February 14, 2011

Oracle Database 10.2.0.4 on Mac OS X Snow Leopard

Its been sometime now since both the 10.2.0.4 Database Client (+ Instant Client) and Database server have been available for Apple Mac OS X x86-64 . The lowest version supported was the Mac OS X Leopard 10.5.4 .

By the time Oracle released the Oracle DB 10.2.0.4 , Snow Leopard was already out and adopted by the Mac community . If you happen to be on a SL box and trying to install Oracle , there is a know problem with the database crashing while installation . Many notable Oracle/Mac folks have worked through and found alternate solutions .

Check out the below links for information :

Link 1
Link2

I will try to list out the issues and workarounds for getting Oracle Databse 10.2.0.4 installed . Some of the points may have been already mentioned in the links mentioned earlier .

1. JDK version on Snow Leopard

JDK 1.6 ( 64 bit ) is the default JDK version available on the platform . If we can install JDK 1.4.2 ( 32-bit ) on Snow Leopard , we will *NOT* require many of the other workarounds related to JDK version mentioned below .

Searching on the web , I found this link which says how to use the older Leopard version 1.4.2 ( & 1.5 ) JDK on Snow Leopard . *NOT* sure if its officially supported , I haven't tried it out myself , but this is a suggestion if someone wants to give it a try .

http://tedwise.com/2009/09/25/using-java-1-5-and-java-1-4-on-snow-leopard/

2. Working around with the JDK 1.6 ( 64 bit ) on Snow Leopard

The next workaround is to configure the Snow Leopard system to use the default JDK 6 , but in 32-bit mode , since there is still not much support for 64 bit java ( some Oracle install related JNI libs are 32-bit ) . JDK 1.6 is pretty recent and there hasn't been much adoption though its slowly increasing .

This is *NOT* tested , but I assume this should also work out . Open "/Applications/Utilities/Java Preferences.app" and set JDK 6 32-bit by default .

The next workaround , is to make a symlink for JDK 1.4.2 point to the default JDK 1.6 . But since its 64 bit by default we need to do changes to some of Oracle's installation scripts .

i) We first need to invoke the runInstaller ( which install's Oracle ) with the "=J-d32" option so that it invokes Java in 32-bit mode , since in the default mode Java 6 is invoked in 64-bit mode .

ii) We also need to modify the $ORACLE_HOME/jdk/bin/java script and pass the "-d32" flag in the command-line . $ORACLE_HOME/jdk/bin/java is used to invoke all the different Oracle database configuration assistants ( netca, dbca etc ) .

3. Make Errors

During the install , we can still see the below issue :
Error in invoking target 'all_no_orcl ipc_g ihsodbc32' of makefile
?/rdbms/lib/ins_rdbms.mk

Workaround : Comment out the HSODBC_LINKLINE in ins_rdbms.mk . Maybe ignoring should also work .

4. Configuration Assistants failures
We should fix the $ORACLE_HOME/jdk/bin/java script to invoke Java in 32-bit mode so that we don't see any failures while running the NETwork Configuration Assistant ( NETCA ) , DataBase Configuration Assistant ( DBCA ) etc ..

5. EE/SE install's with DB creation Snow Leopard

Any of the EE/SE installs on Snow Leopard have a known problem . They fail with the below error message while running the DBCA :

ORA-03113: end-of-file on communication channel appeared.
( dbca : ORA-3113 with CloneRmanRestore )

Looking through the logs , we can see the below error messages :
ORA-07445: exception encountered: core dump [joxnfy_()+2763] [SIGSEGV] [Address not mapped to object] [0x277B8AEB8] [] []

This happens when dbca is invoked to create the database in the EE/SE installs ( not in the software only installs ) . The workarounds suggested on the previously mentioned links is to copy the old Oracle binary to overwrite the new binary .

During Oracle Installation , the Oracle binary is relinked/regenerated on the platform . Even though there shouldn't have been anything which would prevent Oracle to run smoothly on Snow Leopard , unfortunately we see the above issue when the Oracle binary is recompiled on Snow Leopard ( with the rest of the libraries oracle uses being the same old ones).

There seems to have been some changes that have gone into the Snow Leopard . Even though there were no major changes , as the naming convention of Apple would suggest ( Leopard -> Snow Leopard ) , there are still some subtle differences .

One of the changes which is linked to the Oracle Installation crash , most likely seems to be related to changes as described below ( found from a wiki ) :

With the introduction of Apple's Mac OS X 10.6 platform the Mach-O file has undergone a significant modification that causes binaries compiled on a 10.6 computer to be by default only able to run on a 10.6 computer. The difference stems from load commands that Mac OS X's linker (dyld) can not understand on previous Mac OS X versions. Another significant change to the Mach-O format is the change in how the Link Edit tables (found in the __LINKEDIT section) function. In 10.6 these new Link Edit tables are compressed by removing unused and unneeded bits of information, however Mac OS X 10.5 and earlier cannot read this new Link Edit table format. To resolve this issue, the linker flag "-mmacosx-version-min=" is heavily used and depended on. Apple, current maintainer of the Mach-O format, recommends that all developers now use this flag along with the appropriate SDK headers when creating an application/binary.

Below is the dyld ( Dynamic Loader ) release notes of Mac OS X 10.6 ( Snow Leopard )
DYLD release notes for Mac OS X 10.6 ( Snow Leopard )

Researching based on the above data , made me stumble upon a couple of new compiler/linker flags which can help control the generation of the __LINKEDIT section format ( traditional relocation format or the new compressed format ) .

-mmacosx-version-min=version ( Apple GCC Flag )
The earliest version of MacOS X that this executable will run on is version. Typical values of version include 10.1, 10.2, and 10.3.9 .

-macosx_version_min version ( LD Flag )
This is set to indicate the oldest Mac OS X version that that the output is to be used on. Specifying a later version enables the linker to assumes features of that OS in the output file. The format of version is a Mac OS X version number such as 10.4 or 10.5.

Please note the difference between hyphen ("-") vs the underscore ("_") and also the names of the flags for GCC and LD respectively .

-no_compact_linkedit ( LD Flag )
Normally when targeting Mac OS X 10.6, the linker will generate compact information in the __LINKEDIT segment. This option causes the linker to instead produce traditional relocation information.

The "-no_compact_linkedit" linker flag is used / makes sense / allowed only in conjunction with the -mmacosx-version-min=version ( Apple GCC Flag ). You can also use the -macosx_version_min version ( LD Flag ) instead of the GCC flag if you want.

Now , passing the -mmacosx-version-min=version ( Apple GCC Flag ) & "-no_compact_linkedit" linker flag to the Oracle link-line generates a Oracle which is compatible with the older format and also works fine on the Snow Leopard version.

Below is the modification we need to make , to change the Oracle Link-link manually in the env_rdbms.mk Makefile :

$ diff env_rdbms.mk.new env_rdbms.mk.orig
< ORACLE_LINKER=gcc -flat_namespace -mmacosx-version-min=10.5 -Wl,-no_compact_linkedit $(OLAPPRELINKOPTS) $(LDFLAGS) $(COMPSOBJS)
---
> ORACLE_LINKER=gcc -flat_namespace $(OLAPPRELINKOPTS) $(LDFLAGS) $(COMPSOBJS)

With this generated binary , DBCA should proceed through cleanly and so also the Oracle Database 10.2.0.4 install on the Mac OS X Snow Leopard.

6 comments:

Rama Notowidigdo said...

I tried your instruction for using DBCA but keep failing with the same exception ORA-07445: exception encountered: core dump [joxnfy_()+2763] [SIGSEGV] [Address not mapped to object] [0x2773FAEB8] [] []


I'm using 10.6.8, is that an issue? Any other suggestion?

Rohitash said...

I had tried this on a Mac OS X 10.6.0 ( Snow Leopard ) machine and things worked . I don't think there can be another such incompatibility in a later patch , Mac OS X 10.6.8 . Please follow the steps exactly .

If not , you can work backwards . Our idea is just to get the Oracle server binary working . You can manually edit/modify the Oracle link-line related makefiles and recompile Oracle too . While recompiling check that the link-line has the proper flags we introduced . Also read up your release notes to find any change in flags or any in-between 10.6.0 - 10.6.8 .

HTH

Kiran said...

Thanks for the detailed information. and also most of the times both 32 bit and 64 bit works as these expect in some cases where if there are any machine specific calls are called. 32 bit takes 4 bytes long,64 bit takes 8 bytes of size, so 32 bit takes less size compared to 64 bit machines.
To find out the 32 bit or 64 bit 32 bit or 64 bit

bainsteven said...

I got all the way through this install on OSX 10.7.3 - until I click the "Finish" button in "dbca" to create a database... nothing happens!!!

I can go Back, and exit, "dbca" without any issues... but no database is created! SOMETIMES, if I choose to also "generate scripts" this will complete to 100%, but it freezes!

Any idea?!

Thanks,

Steve.

saunak said...

Hello,

after following the steps i was successful in installing oracle 10g in OS X lion but when i try to run
sqlplus system@orcl i get the following error

segmentation fault: 11

please help.

saunak said...

i also have the same problem as bainsteven

dbca does not exit when i click finish