Installing Oracle 9i on Mac OS X, Part 1
Pages: 1, 2

What to expect from Oracle 9i on Mac OS X, for an Oracle DBA experienced with Solaris

The first thing to remember is that this is a developer release and not a production release of the database. But, even for a developer release it's surprisingly complete. All of the really difficult to implement and important features relating to building, backing up and recovering a database instance appear to be functional. This is no small feat for a product as complex as Oracle, which is often considered to be as complex as an entire operating system. Complete standby database functionality is included if you write your own setup/maintenance scripts instead of using the Data Guard Manager utility.

What's included:

The following features are based upon some common Oracle features I install and test during a typical database installation. I have by no means tested every possible feature within the Oracle 9i database.

• Basic database functionality: The basic features of creating tables and tablespaces, inserting and querying data, which we expect of a database, is functional.
• Intermedia: Standard scripts for building Intermedia for Oracle 9.2 instances seems to work OK. You do need to create the DRSYS tablespace prior to running these scripts.
• SqlPlus: SqlPlus is functional via the command line for starting up, creating the instance, and shutting down the database. The Java and Web based versions of SqlPlus are not supplied with this release.
• RMAN: RMAN is functional for backing up, restoring, recovering, and cloning the database as a standby database.
• Standby database: Managed standby database functionality appears complete in regards to setup, propagation of archivelogs via RFS, switchover, switchback, and failover.

What is not included:

• Oracle Universal Installer application: Installing Developer Release 1 is actually a little easier and much quicker than the typical install done with the Oracle Universal Installer Java application. This is because all you really do is uncompress and untar the binary file to install the database software. There is no delay waiting for the installer to copy and assemble the various components together, no waiting for root.sh to run and no delay waiting for the binaries to be linked.
• JServer: JServer functionality and all components which require JServer are not included in this release. This omission also affects the XDB and UltraSearch features.
• XDB: requires JServer
• UltraSearch: requires JServer
• dbms_obfuscation toolkit: The owninst.plb file is not available for building the dbms_obfuscation toolkit feature into the database.
• Oracle Management Server OMS: External Java based utilities are not yet available. The intelligent agent software is also not yet available, which would be used to register the instance and manage it with an external OMS server.
• Oracle Enterprise Manager Console (OEM Console): External Java- based utilities are not yet available, therefore Replication Manager, Schema Manager, Storage Manager, Security Manager, and Data Guard Manager functionality are not yet available.
• dbms_stats.gather_system_stats(): The dbms_stats.gather_system_stats() procedure does not appear to be populating the DBA defined stats table, thus preventing the dbms_stats.import_system_stats() procedure from making these stats available to the CBO.
• No automated startup/shutdown script: The database needs to be manually started and stopped by running shell scripts or SqlPlus according to Oracle's instructions. In Part 3 of this series, I will show you how to automated the startup of the database during Mac OS X startup, but the execution of shutdown scripts is not supported by Mac OS X at this time.
• No OFA file structure: If you follow Oracle's instructions you will end up with all of your datafiles located within the orahome directory. Part 3 will discuss how to perform a more standard Oracle database install in which the datafiles are spread out across multiple disks for improved I/O and reliability.

Related Reading Oracle Essentials: Oracle9i, Oracle8i and Oracle8 By Rick Greenwald, Robert Stackowiak, Jonathan Stern

Mac OS X Specific Features:

• Use /etc/oratab instead of /var/opt/oracle/oratab: The $ORACLE_HOME/dbstart script is expecting the oratab file to be located at the top level of the /etc directory. So if you are going to use dbstart or dbshut then you will either need to put the oratab file in this location or edit dbstart/dbshut with the path where oratab is located.

• No reboot required: It is necessary to edit kernel tuning parameters in the /etc/system file when performing an install on Solaris, and then reboot the server for the changes to take effect. On Mac OS X it is only necessary to configure ulimit commands in the shell, therefore a reboot is not necessary.

• No editing of /etc/hosts, /etc/passwd, /etc/groups files: Apple has made an improvement to the commonly required tasks of editing the many configuration files within the /etc directory. Most of these parameters can be changed by using the NetInfo directory service on Mac OS X. With Mac OS X 10.2 and higher, you can still edit the /etc directory configuration files as well if necessary. Adding these parameters to NetInfo does provide a centralized location for most of the basic operating system configuration info. This can be an advantage when creating scripts because it is no longer necessary to worry about duplicating info if all you want to do is append info to a configuration file.

• No need to add a lot of UNIX utilities to the operating system: On a typical Solaris 7/8 database installation, it is generally necessary to add quite a few utilities to the server just to get everything installed that you would need to do your work. Some of the utilities I typically have to install include:

  binutils
  Perl 5.6.1
  gnu make
  gzip
  top
  less
  ncurses
  openssl
  openssh
  prngd
  zlib
  Mail::Sendmail (Perl module)

  Mac OS X has virtually all of these useful open source utilities already installed if you install the Developer Tools CD. The only additional utility I need to install manually is the Mail::Sendmail Perl module. After installing Mac OS X you don't have to feel like you need to rebuild the operating system just to get the functionality you require. In all fairness to Sun I am sure that Solaris 9 is much better in this regard. But not all UNIX system administrators are ready to upgrade to the very latest version of Solaris as soon as it ships.

• Excellent patch install functionality: Once again, Solaris 9 contains improved functionality in this area, but your typical server will often be running Solaris 8 which requires some manual work to upgrade to the latest patches. Mac OS X shows how to do UNIX patch management the right way. The OS automatically checks for updates at Apple and puts up a dialog prompting the system administrator to install some or all of the latest patches.

• Easier configuration of primary and alternate boot volumes: In order to speed up the disaster recovery process I generally prefer to configure Sun servers with primary and alternate boot drive configurations. If a server hits a hardware fault which causes it to reboot by itself, then it will boot up from the alternate boot drive automatically and restart the database as well. This configuration assumes that none of the critical database control or datafiles are located on the boot drives, and that there is a periodic CRON job scheduled to automatically copy the contents of the primary to the alternate boot drive. On Solaris, open firmware commands need to be used to actually configure the primary and alternate boot drives. However, on Mac OS X it is as simple as installing the OS on two drives and selecting the appropriate one to serve as the boot drive. If the server reboots and can't find the previously selected boot drive, it will boot from the alternate drive automatically. An application like Carbon Copy Cloner could be scheduled either with the standard CRON utility or with the Cronnix graphical CRON utility to keep the alternate boot drive updated with the primary drive .

• Case insensitive file/directory names when using HFS+: One item which may come as a pleasant surprise to experienced Solaris DBAs is that pathnames and filenames are case insensitive when issuing shell commands which operate on HFS+ volumes. This is a nice feature when typing commands in the terminal. However you can't necessarily count on all UNIX applications making use of this functionality, especially commands that you issue within the database or from within database utilities. When setting up a non-boot drive to store Oracle datafiles, I generally recommend formatting the drive with a UFS filesystem in order to prevent myself from relying on being able to use this case insensitivity feature. This way I can ensure that all of my scripts will be easily portable to other Linux/UNIX servers.

Mac OS X Specific Issues

No shutdown capability from /sbin/SystemStarter: On Solaris, a DBA would generally install an /etc/init.d/dbora database startup/shutdown script with symlinks to /etc/rc3.d/S88dbora and /etc/rc0.d/K88dbora. During system startup the scripts in the rc3.d directory are executed with the "start" argument, and during shutdown the scripts in the rc0.d directory are executed with the "stop" argument. On Mac OS X 10.2.1 (client and server) the /sbin/SystemStarter program executes startup scripts placed within subdirectories within the /Library/StartupItems and /System/Library/StartupItems directories with the "start" argument. It appears that the intended behavior for SystemStarter is that it should also pass the "stop" argument to these same scripts upon system shutdown, but this does not currently occur. So, at least for now, it is necessary to shutdown the database manually before shutting down Mac OS X.

Summary for Solaris DBAs

Mac OS X offers the potential to be a robust platform for installing workgroup-sized Oracle databases while offering the reliability we would normally expect from a Sun server. Even if the application is expected to grow beyond the hardware offerings available from Apple, Mac OS X can provide a reliable starting point for a database which may eventually end up being migrated to larger Sun hardware. Mac OS X offers the reliability of a an operating system like Solaris at a hardware price of a Windows server. Reliability and manageability exceeds that which is available from a Windows server, while not requiring as many changes to DBA written scripts when migrating up to a Solaris server.

Next Time

Today I discussed similarities and differences between running Oracle on Mac OS X to Solaris. In part two I'll talk to FileMaker Pro DBAs who might be considering migrating to Oracle on Mac OS X. See you next time.

David Simpson is president of .com Solutions Inc. and the developer of the Installgen application.

---

Return to the Mac DevCenter.