Crisp Data Solutions

Note: This document now contains updated instructions for installing Oracle on OS/X Tiger. This is now a full installation guide rather than just errata for the latest releases of Oracle (10.1.0, still no Release 2 for OS/X), OS/X (10.4.5), and XCode (2.2). The old errata document is still available, but of limited use.

Note: The installer for Autostarting Oracle is below.

If you find these instructions useful, or have any comments or suggestions, please drop me a note at the address above.

Installing Oracle 10g on Tiger

I'm using the current versions of software. That is, Oracle 10g for OS/X Release 1 (and please don't hesitate to nag Oracle about producing Release 2). Tiger 10.4.4. XTools 2.2.

There are a number of guides around with various differences in versions and instructions, therefore I'm going to go over the whole procedure. I generally follow Sergio's blog's instructions, but as that is for Panther I've altered it for Tiger. There are a few other blogs with instructions that differ. I've generally kept as close to Sergio's instructions, which are close to the quickstart.

So first, you're going to need to do a few things as root.

sudo -s

will get you a root shell.

sw_vers

will tell you the version of software that you're running. For me that is:

ProductName: Mac OS X Server
ProductVersion: 10.4.5
BuildVersion: 8H14

It doesn't matter if you are running Server or Client. If in the future Oracle checks to see if you are running Server, since only Server is actually supported, you can alias sw_vers to return the proper string. Or you can tell runInstaller to ignore preflight checks by using the parameters -ignoreChecks.

gcc -v

will tell you the version of gcc that you're running. Probably you're running 4.0x by default. Alter this to 3.3 via

gcc_select 3.3

Take a look at the groups on your system via

nireport . /groups gid name | sort -n | more

System groups are the lower numbers, generally under 100, Users generally start at 500. We'll use 600 for Oracle. If you've 600 for something else, use some other convenient #, the changes should be obvious.

Now create the oracle inventory group. OS/X uses netinfo, not the old groups file. Just do it.

nicl . -create /groups/oinstall

nicl . -append /groups/oinstall gid 600

nicl . -append /groups/oinstall passwd "*"

Same thing for the dba group. Use 600+1.

nicl . -create /groups/dba

nicl . -append /groups/dba gid 601

nicl . -append /groups/dba passwd "*"

Use the nireport command above to check your work.

Then find an unused user id.

nireport . /users uid name | more

Might as well use 601.

nicl . -create /users/oracle

nicl . -append /users/oracle uid 601

nicl . -append /users/oracle gid 600

nicl . -append /users/oracle shell /bin/bash

nicl . -append /users/oracle home /Users/oracle

nicl . -append /users/oracle realname "Oracle software owner"

nicl . -append /groups/dba users oracle

adds the oracle user to the dba group

mkdir /Users/oracle

creates a home directory, though this doesn't have to be where the actual installation goes

chown oracle:oinstall /Users/oracle

passwd oracle

Use a secure password like bl23qtui93.

Now we're going to create the actual Oracle install hierarchy. The Oracle Quick Install document suggests putting these mount points (directories) under /Volumes. I'm going to assume that you don't have dedicated drives for Oracle at this point, and if you put the mount points under /Volumes you can't see them in the Finder, and thus can't easily manipulate the files. So put them under /Users/oracle instead, or any convenient place that you like.

mkdir -p /Users/oracle/u01/app/oracle

mkdir -p /Users/oracle/u01/oradata

chown -R oracle:oinstall /Users/oracle/u01/app/oracle

chown -R oracle:oinstall /Users/oracle/u01/oradata

chmod -R 775 /Users/oracle/u01/app/oracle

chmod -R 775 /Users/oracle/u01/oradata

Note that the actual database installer (the dbca, which will run later and crash...) may want to put the oradata directory under u01/app/oracle. It doesn't really matter. You can change it or keep it. If you're configuring a production machine (and please email me if you do - I'm curious about how many people are really using OS/X for production) then you will want to be particular about the layout of course, and use multiple disks at that. I think that using the u01/oradata hierarchy is more kosher according to Oracle standards.

Now some kernel parameters will need to be changed. Check the current values with

/usr/sbin/sysctl -a | grep corefile

/usr/sbin/sysctl -a | grep sem

/usr/sbin/sysctl -a | grep maxproc

The required values must be at least those in this table:

You need to change them for the running kernel, and also configure them to change after restart.

I only had to change the maximum # of processes, and processes for userid.

/usr/sbin/sysctl -w kern.maxproc=2068

/usr/sbin/sysctl -w kern.maxprocperuid=2068

then alter (or create) the file /etc/sysctl.conf so it looks like this (at least):

kern.maxproc=2068

kern.maxprocperuid=2068

Now change some shell parameters:

cd /System/Library/StartupItems/IPServices

right after the last fi in StartServices add 4 lines:

ulimit -Hu 2068

ulimit -Su 2068

ulimit -Hn 65536

ulimit -Sn 65536

Is this strictly necessary? Probably not. Do it anyway, because I say so.

I'm going to assume that you've downloaded Oracle, probably to the desktop. Safari also probably uncompressed it to a Disk1 directory and threw away the original file. Just to be safe, take the original file (ship_mac_db.cpio or ship_mac_db.cpio.gz) out of the trash and put it in /Users/oracle. Change the owner.

chown oracle:oinstall /Users/oracle/ship_mac_db.cpio

That's all we need to do as root for now.

OK, we're almost there. Now we need to set the profile for the oracle user

su - oracle

Or however you want to do it. This will go down another level in the shell.

create .bash_profile

vi .bash_profile

with the following lines:

umask 022

ORACLE_SID=ORCL

ORACLE_BASE=/VOlumes/u01/app/oracle

export ORACLE_BASE ORACLE_SID

later we'll add 2 more lines after installation

load the profile:

. .bash_profile

Uncompress the oracle distribution. If the file still has a .gz at the end, unzip it first. Otherwise only execute the cpio command.

gunzip ship_mac_db.cpio.gz

cpio -idm < ship_mac_db.cpio

Now we're going to deal with an issue that causes a lot of problems, particularly with Client installations. That is the IP address and naming issues.

There are two parts to this. First, you need to set things up so that you can properly install. Then later, you need to do more to get Enterprise Manager (dbconsole) to run properly since it's even more picky. It's even worse if you are on a PowerBook, since you might be using the WiFi interface or the wired interface.

The easiest thing to do at this point is to add the hostname to the hosts file, and make sure that OS/X will use the file. Later we'll worry about enterprise manager. Right now we just want to get through the install without too much trouble.

First, find out your hostname by typing (as root)

hostname

Then get your ip address by typing

ifconfig -a

which will list all of the network interfaces (and more). Find the one which you are using.

Now edit the hosts file. Add this line at the top before the first localhost entry

(your IP) (your hostname)

Now make sure that the hosts file is enabled, which I'm pretty sure is the default in Tiger.

lookupd -configuration

check the LookupOrder line, make sure it includes FF (Flat File), meaning the hosts file, in the Host Configuration line. If it doesn't, well send me an email for now...

OK, now we can install.

cd into Disk1

./runInstaller

Just follow the screens. I'm not going to go over the interface. When the installer tells you to, open a new terminal shell as root and execute the orainstRoot.sh file.

cd /Users/oracle/u01/app/oracle/oraInventory/

./orainstRoot.sh

Go back to the interface and continue. Pick a nicer name for the installation on the next screen.

And then it crashes when the DBCA tries to start the database! Thanks Oracle!

We need to fix it and relink.

First, go back and edit the .bash_profile file. Now it should look like this (add two lines and change the export)

ORACLE_HOME=/VOlumes/u01/app/oracle/10.1.0/db_1

PATH=$PATH:~/bin:$ORACLE_HOME/bin

export ORACLE_SID ORACLE_BASE ORACLE_HOME PATH

reload it

. .bash_profile

At this point you may want to take advantage of an undocumented environmental variable that may make it easier to run Enterprise Manager later. You can set EMHOSTNAME to your local host name. That will force Oracle to use that name when setting up Enterprise Manager, which it does when it creates the actual database (each database has it's own Enterprise Manager settings). IP Addresses and Hostnames are the #1 problem with Oracle installations, especially if you are using a computer with an IP Address that changes because it's a portable and gets a dynamic address. Using the variable you know that you will get a resolvable hostname even if the installer wants to pick a dumb one.

If you want to do this then add a line for EMHOSTNAME and add it to the export:

EMHOSTNAME=<your hostname>

export ORACLE_SID ORACLE_BASE ORACLE_HOME EMHOSTNAME PATH

Your hostname on Tiger is probably <machinename>.local. This will resolve. You can still use the IP address when accessing from another computer.

reload it:

. .bash_profile

Now we can continue and relink Oracle:

cd $ORACLE_HOME/lib

mv libnnz10.dylib libnnz10.dylib.ori

relink all

mv libnnz10.dylib.ori libnnz10.dylib

Oracle is installed at this point, but since the DBCA never ran there is no database. Run DBCA and create a database.

dbca

- The network configuration can give you a lot of trouble if you don't have a static IP with a DNS record. Several Oracle utilities store their configurations by IP address and/or hostname, and the installer also checks to see if the machine name maps to the IP address. If the installer starts coughing up errors saying "thrown when the IP address of the machine cannot be determined", or something like that, then you should probably abort the installation and fix the problem, because it will bite you later. The EMHOSTNAME variable will help.

If you have a static IP, and this IP has a real DNS name, then there is no problem. Otherwise, you need to make it look like this is properly configured or you may have problems later. The easiest way to fix this is to add the machine name (which can be anything, since you're forcing it) and the IP address to /etc/hosts. Panther is configured by default to check first in the /etc/hosts file for address resolution, which wasn't true in previous versions of OS/X.

If you have a static IP, but it has no real DNS entry, you can just add one to your /etc/hosts file or your nsinfo service if you're feeling ambitious. The format is:

IP HOSTNAME

For instance my /etc/hosts files is:

192.168.0.19 my.hostname.com
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost

Just put in the static IP and give it whatever name you like.

If you have a DHCP hostname, then you can do the same thing for installation purposes. Just put in the assigned address as the IP and give it a name. That's the 192.168.0.19 address at the top of my /etc/hosts.

If you have more than one IP address, say you have airport on and also a land line, you should just pick the one that you are more likely to use, and disconnect one of them during installation.

If your IP is dynamic and later changes, then you will have problems because enterprise console, for instance, goes by the configured hostname. This can be a pain, because these utilities need to be set for the new address. Also the SQL*NET configuration files need to be changed. So you may install using 127.0.0.1, which is the loopback address and will always resolve. To do this you need to disconnect from all networks before you install. There are a lot of potentially different situations, so this is not a complete description.

- One user reports that you also need to add the database global name to /etc/hosts in order for the listener to autodiscover the oracle instance. I didn't run into this, but FYI.

- Additional users need to go into the "dba" group. Not an installation issue, but required to access Oracle's shared memory from other accounts.

Autostarting Oracle:

OS/X and Darwin don't use the standard System V way of starting daemons that Linux and most Unix systems use. I don't see it as an improvement, and it seems to be unfinished at this point since there is no Shutdown procedure. In order to get Oracle to begin automatically upon startup, you need to install a StartupItem into /Library/StartupItems that contains the proper commands. I'm not going to go into the details here, you can check Apple's documentation and other places for the detailed specs. Essentially, you need to create a directory for the StartupItem (call it Oracle), a Properties file called StartupParameters.plist that describes the startup item, a script to be invoked with the same name as the directory, Oracle, and another script that is called by that script, start_oracle, which starts the listener, database, and enterprise manager. So just download those files and put them into /Library/StartupItems/Oracle and Oracle will be automatically started. Don't forget to make Oracle and start_oracle executable.

At the current time, the flexibility of the automatic startup is somewhat limited. It assumes that the oracle user sets the proper ORACLE_HOME and ORACLE_SID in .bash_profile. Only that SID is started (not all in /etc/oratab). At the very least they should show you how to use the Startup facility to get to your normal unix startup scripts. If you need to customize the startup script, you can just edit oracle_start or point to a different script.

You can download an installer that will install these files here. This is a brute force procedure at present. It will overwrite anything in /Library/StartupItems/Oracle, so use with care, especially if you customize the script. In the near future I will be putting together a more comprehensive installer and Preference Pane to give greater control over what the Startup Item does.

Autostopping Oracle:

You actually don't need to stop Oracle. Oracle can crash without any data loss, and will automatically repair itself when it starts back up. The only inconvenience is a few seconds/minutes while it does the automatic recovery, and complaints from anyone using it at the time that it crashed.

Memory Concerns:

I think that the majority of users are using Oracle for development or testing on machines that don't necessarily have loads of memory. 512M is the bare minimum, and 640M is preferable if you want to do anything else with the machine (like run EM in Firefox), and 1G is better.

There are 3 quick things that you can do to reduce the memory requirements without impacting your development capability.

- Reduce the # of Processes to 50 from 150

150 is the default, but you will never need this if you're just developing.

Log on as SYSDBA

ALTER SYSTEM SET PROCESSES=50 SCOPE=SPFILE ;

- Reduce the size of the SGA from 160M to 128M

Normally, you wouldn't want to do this, and if you start getting errors about memory increase this #. But for a lot of development you don't need as much SGA. And every little bit counts when you only have 640M.

ALTER SYSTEM SET SGA_MAX_SIZE=128M SCOPE=SPFILE;

ALTER SYSTEM SET SGA_TARGET=128M SCOPE=SPFILE;

- Remove the Shared Server for HTML/XML

The default dbca installs set up a shared server to respond to HTML/XML requests. This is great if you're using these features, but most people are only using Oracle as a DBMS, not a web server or even an XML server. So turn it off.

ALTER SYSTEM SET DISPATCHERS='' SCOPE=BOTH;

You have to restart Oracle after these changes (except the DISPATCHERS change). The 'SCOPE=SPFILE' part means that it only affects the parameter file, which will be read on the next startup.

Questions, feedback, etc.., please contact me at .