Editor's note: In this first part of a three-part series exploring Oracle 9i on Mac OS X, David Simpson provides you with some excellent background information and a look at the ramifications for Solaris administrators. In Part 2, he'll discuss the conversion for FileMaker administrators, followed by Part 3, where he pulls information from Oracle's documentation, various Web sites, and personal research to detail the actual installation process of Oracle 9i Developer Release 1 on Mac OS X.
I've been an Apple customer since I bought my 128K Macintosh in 1984, and I make my living performing Solaris and Windows system administration in my role as an Oracle DBA. So it's been very exciting for me to see the introduction of Mac OS X and now the availability of Oracle 9i on Mac OS X. With its highly regarded BSD UNIX core, Mac OS X enjoys the reliability previously obtained only from UNIX/Linux servers.
This UNIX core also enhances developer's ability to efficiently port applications to Mac OS X. Applications such as OpenOffice, Sybase, and now Oracle 9i would probably never have been ported to the Mac platform if it were not for Mac OS X. UNIX developers who already have a non-graphical program running on an existing UNIX/Linux platform often need to make very few changes to their application in order to support Mac OS X.
Because Oracle databases generally work almost identically on each platform upon which they run, it's really only a matter of learning the quirks of platform-specific installation steps such as running oradim.exe on Windows to create entries in the Services Control Panel or creating a database startup/shutdown script within the /etc/rc3.d directory on Solaris. On Mac OS X, this same task is accomplished by creating the /Library/StartupItems/Oracle/Oracle startup/shutdown script along with its associated StartupParameters.plist file within the same directory.
I have some background information that I need to cover before getting into the specifics of installing Oracle on Mac OS X. So let's take care of that business now.
Why is the availability of Oracle 9i on Mac OS X important to Apple?
Oracle is one of the best known names in enterprise class software used by corporate customers. Having the Oracle database available for Mac OS X adds significant credibility for Apple whenever a Fortune 500 company is considering the installation of Apple systems. Having enterprise class software available for Mac OS X helps to dispel the myth that the Macintosh is only used by graphics and multimedia professionals.
Now that Oracle 9i is available on Mac OS X, other enterprise class software vendors such as SAP and Seibel whose products use Oracle databases could also choose to port their products to Mac OS X.
The Oracle database represents an excellent purchasing justification for companies to consider buying the Xserve and especially its companion disk array (recently demonstrated at Seybold).
|
Related Reading 
Oracle in a Nutshell |
Customers who currently host FileMaker Pro Server on Mac systems may now consider upgrading to an Oracle database running on Mac OS X if they need better performance, recoverability, or the advanced replication features available within Oracle. This is a non-trivial upgrade as will be discussed later, but it's a possible alternative to buying a Sun or Windows server. This is good for Apple because it means that customers have the option to continue using Macintosh systems along with the inherent server manageability advantages available with Mac OS X. However, for truly massively scalable systems in which a customer might need terabytes of disk space or dozens of CPUs in the server, the customer may still need to upgrade to a large UNIX server like a Sun F15K. But even this situation can be turned to Apple's advantage because the customer can start with a smaller Macintosh server for their initial development and rollout, then upgrade to the larger hardware when the actual server load makes it necessary. Data is easily portable between Oracle databases on any platform by using the Oracle export/import utilities, so the customer doesn't have to be stuck with one type of system or another.
There's interest by some Apple customers in using the Oracle Collaboration Suite to consolidate and reduce the costs associated with licensing and managing Microsoft mail and file servers. This is another opportunity for Apple to prevent existing customers from migrating to another platform and provides a new business opportunity which never previously existed for Apple. The Oracle Collaboration Suite is currently available as a production release for Solaris, and a developer release for Linux. A Mac OS X version is not yet available, but this is understandable because Oracle needs to get the database fully operational on Mac OS X prior to adding the Collaboration Suite to their Mac OS X product development effort.
Is Mac OS X just another UNIX platform?
To some extent, Mac OS X is just another platform to a large software developer like Oracle. They don't port millions of lines of code between operating systems just for the fun of it! Having Larry Ellison on the board of directors (until recently) at Apple and having the close friendship between Larry Ellison and Steve Jobs probably didn't hurt the situation. However Oracle does need to have good business reasons for making this development effort.
Apple ships roughly 700,000 Mac OS X compatible computers in a typical quarter. Each one of these systems is really a UNIX workstation in disguise underneath the Mac OS X GUI. Based upon a recent Gartner Dataquest press release, Sun shipped 68,000 UNIX systems and HP shipped 330,000 systems. Most of these HP systems were not UNIX systems, but even if they were Apple would still be the highest volume UNIX systems vendor worldwide. This represents a sizable potential base of systems which could run an Oracle database, even if some of these systems are laptops which might only be used by a software developer for testing purposes.
Having the Oracle database available for another robust and popular UNIX platform does provide a wider range of choices for Oracle customers. Don't tell Microsoft, but competition is good for the marketplace.
For customers who simply don't want to run Windows due to security, reliability, or anti-trust concerns, Mac OS X provides an easily manageable alternative to other operating systems. Customers who wouldn't normally consider buying a Sun server due to their lack of UNIX experience may be very willing to consider at least testing an Oracle database on an Apple system.
Oracle charges the same price for their database licensing regardless of the operating system with pricing determined by either the number of users or the number of CPUs installed in the server. By adding yet another platform to their product line, Oracle can make the same revenue per server but pick up a customer who might never have previously considered licensing an Oracle database.
I would not expect for Oracle to see a large difference in their support costs on Mac OS X compared to other platforms. Unlike many applications which would probably see reduced support costs, complex products like enterprise class database servers generally get supported via a command line interface by technical support departments. Oracle Worldwide Support services will generally troubleshoot customer issues via the command line so that they can clearly understand exactly what the customer is doing. When troubleshooting over the phone or via the Web, you just can't tell what a customer has clicked when using a graphical interface.
Oracle may actually see a slight increase in support costs for Mac OS X customers if significant numbers of FileMaker Pro Server customers choose to migrate to Oracle. Managing the complexity of an Oracle database will be quite a challenge compared to working with FileMaker.
A production release of Sybase is currently available for Mac OS X. Oracle does not want to concede this market to Sybase, so it is necessary for Oracle 9i to be available as an alternative to Sybase. Sybase actually takes advantage of the newest Mac OS X features such as Rendezvous for auto-discovery and auto-configuration of clients. Oracle has not indicated whether it will support these features on Mac OS X for the 9.2 release. However, it is likely that this first production release of Oracle 9i will simply support the basic database functionality which is already available on other UNIX platforms. Even this is no trivial task when dealing with a product as complex as Oracle.
Oracle generally takes a conservative approach by adding features to its database on an incremental basis. For instance, every revision of Oracle for Windows lists "improved compatibility" with the Windows platform. One of these Windows-specific features makes use of a Windows domain controller to authenticate user access to the database. This would be equivalent to Oracle using the NetInfo directory service to authenticate Mac OS X user access to the database. This functionality would enable a company to setup a master NetInfo server for company wide authentication to desktop systems and access to the Oracle database. This feature is not hinted at in any of the Oracle 9i documentation for Mac OS X, but this is the type of feature which could be made available in future revisions.
There is significant interest in the Oracle database by Apple customers. Oracle exhibited at the January 2002 MacWorld Expo in order to demonstrate its Web-based E-Business suite of applications. These Web-based applications are available for client access via a Web browser on almost any platform. However the E-Business Suite is not available for hosting on platforms which don't run the Oracle database server. Oracle booth personnel who worked at the Oracle booth reported that quite a few customers were disappointed that the Oracle database was not available for Mac OS X. They were actually a bit surprised by the amount of negative comments they received from customers. Perhaps this feedback from the sales people helped Oracle to determine that there was enough interest to warrant porting Oracle 9i to the Mac OS X platform. If Oracle chooses to exhibit at the January 2003 MacWorld Expo, then I think that they will find an enthusiastic audience among the attendees.
Oracle corporation has a lot of learning to do in regards to improving the usability of their products. Mac OS X users can greatly assist Oracle with this learning process. When I attend Oracle instructor led training classes, the instructors keep telling us that Oracle's goal is to make their database as easy to use as Microsoft SQL Server. I estimate that the Oracle database is an order of magnitude more complex to setup and administer than a Microsoft SQL Server database. I think that Microsoft SQL Server is still about an order of magnitude more complex than FileMaker. Considering that there are almost 500 configuration parameters available for the Oracle database, they have quite a ways to go to improve in this area. I suggest that Oracle is setting their goal too low. They should really attempt to become as easy to use as FileMaker Pro. If they miss this goal, they may succeed in achieving Microsoft SQL Server ease of use, which would still be a significant improvement.
This doesn't mean that Oracle isn't trying or making progress with improving usability. The latest versions of the Oracle Enterprise Manager Console are rich with features and continue to improve with each revision. And with each revision of the database, additional database configuration parameters are automatically tuned by the database instead of the DBA. Some of the complexity is the result of the fact that the database has so many features and options available. And customers certainly like as many features and options as they can get in any product.
Oracle may end up being surprised at the usability demands made by Macintosh customers. Macintosh customers have very high standards for usability. In the UNIX server marketplace, most applications have two user interfaces. One interface is the pretty looking graphical interface you see on the marketing brochures, and the other interface is the command line interface. It is generally accepted by UNIX administrators that the GUI interface versions of most applications just simply don't work well. Experienced system administrators will often go right to the command line interface and seldom use the GUI interface.
This is quite different from the environment expected by Macintosh customers. On a Macintosh, the GUI interface to an application has usually been the only interface available therefore it had to work correctly every time. And if the GUI interface didn't work correctly, the application would receive very poor reviews. Therefore Macintosh customers will push Oracle (and all other Mac OS X software vendors) to improve the user experience with their products. The end result will be an improvement in usability on all platforms. This would be especially true for Oracle because the Oracle GUI tools are all written in Java, which is very portable between platforms.
|
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.
What is not included:
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 |
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.
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.
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.
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.
Copyright © 2007 O'Reilly Media, Inc.