Well, you can’t install Oracle on a Mac, not really. You sort of can. I did it! More or less. Allow me to describe how I, a hacker who prefers Mac but can speak Linux, made a few compromises to build an Oracle-based development environment on my MacBook. (It’s running Mavericks, but as we shall see, that doesn’t really matter much.)

Earlier this month I needed to set my machine up for a new client who made deep use of Oracle, with lots of custom stored procedures and all that. Their large extant codebase, full of Oracle-specific magic, made it no use to try faking their DB for local development using SQLite or the like. Connecting to their database through the internet was not an option, and I certainly didn’t want to resign myself to developing directly on their machines through a VPN. I had to get a local Oracle instance running on my laptop, somehow.

It took the better part of a weekend, but I made it work, and work stably. I am sure there’s plenty of ways to do this, but the following describes the path I took — eliding many false starts and blind alleys that inevitably befell me.

Research taught me a few things:

  • Oracle’s current version number, as of May 2014, was 12. My client used some flavor of 10. I decided to split the difference and go with 11, mainly because most of the online documentation I could find was 11-flavored; 12 seemed a bit new and untested, and 10 a bit long in the tooth.
  • The package I wanted, as a single developer targeting the production environment of an existing Oracle customer, was called “Oracle Express Edition” — “Oracle XE” or just “XE” for short. This is a free-beer edition of the software that anyone can download if they’re willing to sign up for a free-beer Oracle account.
  • Oracle XE, for all intents and purposes, doesn’t run on Mac OS.
  • It does run on Linux!
    • But it strongly prefers to run on certain Linux distributions.
    • Oracle has their own Linux distribution! I guess!
      • But I’d never used it before, let alone had to set up and manage an instance.
      • I couldn’t find any VMWare images for it anyway.
    • Oracle also loves RHEL.
      • That means they also love CentOS, whether they want to or not.
      • CentOS has been the distro of choice for more than one of my clients. I knew I could get it up and dancing pretty quickly.

Armed with all the above knowledge, I decided to roll ahead with Oracle XE running on a Centos VM, which would in turn run on my MacBook. My instincts suggested that Oracle’s own distro might be a wise choice for someone setting up a new database that would serve a whole company, but for a short-term consulting gig a more familiar Linux flavor would serve me better.

I thought that I’d allow the VM to act as a thin wrapper around Oracle, but I’d otherwise do all my development work on Mac OS, just as I prefer it.

So, my next steps:

  1. I downloaded a fresh CentOS VMWare image from the friendly folks at ThoughtPolice. (Update, April 2017: Sadly, this resource no longer seems to exist — sorry! You’ll have to find a VMWare image elsewhere, or use VirtualBox, as mentioned below.)

    I am led to believe that others have had success using VirtualBox for this step, and I heard tell of VirtualBox images with one of those Oracle-brewed Linux distributions already on it. Cool! But I already liked VMWare, and I am comfortable with CentOS, so these are the tools I gathered.

    For the remainder of this adventure I naturally made liberal use of sudo yum install [...] to solder new packages onto the VM every time I attempted a task that revealed some missing common Linux program or library. This ought to be familiar to most any experienced Linux user and I shan’t bother you with the details.

  2. Followed steps 1 through 3 on this excellent article by David Ghedini.

  3. By this point I had a CentOS VM with Oracle XE running on it. I could ssh in and run sqlplus and connect to the DB’s admin account, just as the article described. Great!

    My next step, as originally planned, involved configuring that Oracle server to allow remote access, and then layering various magics upon Mac OS (Oracle client libraries, X11, and so on) so that I could manage and talk to Oracle on CentOS as needed, but otherwise develop on Mac OS. As it turned out, I backed away from this strategy; I found the entire process (which steps 4 and beyond of the Ghedini article only begin to describe, at least for a VM setup like this) simply too fraught and hairy, and after sinking most of a day into it I gave up.

    (Maybe had I followed the advice on this page and started out with Oracle’s VM, based on their own Linux distro, things would have gone better? I don’t know, I only found that page just now. It’s probably worth closer investigation for someone just starting out. But it’s not the path I took — and again, I regret nothing, because I do like CentOS.)

    The strategy I would instead embrace, to comfortable success, has me using the CentOS VM as my development environment, giving the software I’m working on the much easier task of connecting to an Oracle instance running on the same (virtual) machine. The remainder of my steps involved making this environment less painful to use from a Mac.

  4. I took the advice of this article by Donald K. Burleson to install the command-line program rlwrap and set up a certain shell alias, allowing sqlplus to have basic bash-style command-history features (e.g. up-arrow to retrieve the previous command), making that program much friendlier.

  5. I shut off the VM’s firewall completely (after double-checking that my Mac’s remained up and running), and reconfigured it to default-off on startup. I didn’t want it getting in the way of subsequent communication shenanigans between it and Mac OS.

  6. Copied my SSH public keys to my home directory on the VM, allowing quick, password-free login from my laptop. This article by Steve Kemp shows how it works, on most any flavor of Unix.

  7. Installed FUSE for OS X and its companion sshfs command-line program, which makes trivially easy the process of mounting a remote, SSH-accessible filesystem on a Mac.

And that’s it, really. Everything else I did was either specific to my client project, or false-start work I needed to undo. After all the above, I could use sshfs to locally mount the directory containing my client’s codebase, allowing me to use BBEdit or whatever to work with it, and I considered that a huge win. I still had to ssh into the VM to run sqlite and other programs that used my new Oracle setup, but I considered that a small price to pay to get everything else working.

Next post: Why I won’t suffer another whiteboard grilling

Previous post: A letter about a creepshotter

Thank you for reading this post, written by me, Jason McIntosh.

I welcome your comments! (I reserve the right to remove comments I find obnoxious or misplaced.) You can also find me on Twitter, or send me an email.