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.

HP-UX software ( patch ) Information and query

Software and patch management in HP-UX is done using HP Software Distributor called SD-UX. The software in SD-UX is organized in a hierarchy of components or objects. These components are filesets, subproducts, products and bundles. The place where these components are stored is called a software depot.

Few Common Terms in SD-UX :

Filesets: It is a collection of files and some control scripts. It is the basic entity in the SD-UX hierarchy. One file set can belong to only on product. But it can be included in a number of sub-products and bundles.

Here is an example: Keyshell.KEYS-END-A-MAN B.11.30

where
1st field is the fileset name
2nd field is the fileset version

Sub-products: If a file set contains several filesets, it is better to combine logically related filesets in to subproducts.

Here is an example:
X11.MessagesByLang X11 Localized Messages

This sub-product contains the filesets for X11 messages in several languages.

Product:
It is nothing but a set of filesets. In another words, it is a superset of filesets / subproducts.

Here is an example ,
X11 B.11.30 HP-UX X Windows Software

where
X11 is the product name
B.11.30 is the product version
third field is the product description

Bundles: Bundles are usually packaged by HP-UX for the distribution of software. The bundle may contain filesets that may belong to different products.

Here is an example,
OnlineDiag B.11.20.06 HP-UX 11.0 Support Tools Bundle

Patch Commands
swconfig - configure software / patches
swlist - display software / patch information
swinstall - installs software / patches
swremove - removes software / patches

Patch Logs / Listing
/var/adm/sw/swagent.log --> contains entries from swagent daemon
/var/adm/sw/swinstall.log --> entries/errors from swinstall

Gather Patch Install/State data
swlist -l fileset -a state PH* > /tmp/swlist.txt
swlist product PH* > /tmp/swlist.txt ( $ swlist -l product 'PH??_*' )

Other patch Commands
check_patches --> Checks for common problems and issues ie. Patch attributes, missing patch filesets, etc.
/usr/contrib/bin/show_patches ---> displays only active patches on system

How to tell what patches are loaded using the swlist command (10.x)?
Patches are named PHxx_nnnn, where xx can be KL, NE, CO, or SS.
nnnn refers to the patch number, which is always unique no matter what PHxx category is specified.

If a patch has been loaded on a 10.x system, the patch should be listed in the output of swlist . All patches named PHKL*, and some patches named PHNE*, are kernel patches.

A patch name consists of the characters "PH" (Patch HP-UX), followed by a two-character type-identifier, followed by an underscore, followed by a four or five-digit number.

The currently defined patch types are:

CO - COmmands & libraries
KL - KerneL
NE - NEtworking
SS - SubSystems

Kernel patches always require a system reboot, so that the newly updated kernel can be loaded. Many Networking patches (PHNE*) also make modifications to the kernel, and hence require a reboot.

Note that the numerical portion of any given patch name is unique, among ALL patches. So there would never be a patch named "PHCO_23507", in addition to a patch named "PHKL_23507." This lends itself nicely to grepping for a particular patch (ie - to see if "PHKL_23507" is installed, one could use "swlist -l product | grep 23507" .

QPK = Quality Pack - which is a bundle of patches that HP provides twice yearly for each version of HP-UX.

HP-UX 11i v2
# swlist -l bundle BUNDLE11i HWEnable11i FEATURE11i QPKBASE QPKAPPS

HP-UX 11i v3
# swlist -l bundle BUNDLE11i HWEnable11i FEATURE11i QPKBASE

Contrast the installed patches against the latest available on www.itrc.hp.com

Examples :
To list the installed bundles :
# swlist -l bundle

To list the installed products :
# swlist -l product

To list the installed subproducts :

# swlist -l subproduct

To list the installed filesets alone :
# swlist -l fileset
# swlist -l fileset openssl

To list all the files belonging to the product X11 or fileset openssl :
# swlist -l file X11
# swlist -l file openssl

To open swlist in GUI mode :
# swlist -i

To view the readme file for a product :
# swlist -a readme OS-Core

To find out Which Operating Environment Currently installed
# swlist -l bundle | grep HPUX11i

To generate a comprehensive listing that includes all filesets for the product NETWORKING
# swlist -v -l fileset NETWORKING

To find out which product a file belongs to 1st way, its slow:
# swlist -l file |grep /bin/ls

2nd way much quicker, as root:
# find /var/adm/sw/products -name INFO -exec grep -l /bin/ls {} +