In the wake of a small flurry of announcements yesterday about the release of Oracle 10gR2 for Mac OS X Intel (almost two weeks after April Fools' Day, so knock it off with the jokes already ), I decided to try a test installation on my Macbook Pro. The good news is that it works, even if you aren't running OS X Server 10.5.4 as specified in the release notes:

For the record, this is Mac OS X Leopard, desktop version 10.5.6. I'm still considering whether or not to post an "install guide," since everything more or less worked as advertised. And really, does the Internet need another dozen screenshots of OUI and DBCA doing their usual thing? I feel guilty enough for the screenshot above.

Install guide updates, 12-13 April 2009:

• Ronald Rood has posted a quick installation guide.
• So has Raimonds Simanovskis, with additional instructions on how to auto-start oracle on boot.
• Alex Gorbachev also has posted his install guide, so you now have a wide variety of options.

So now what?

Apart from the novelty of it all, is this a worthwhile exercise? I'm not sure yet. I've been using the "Oracle in a VM" approach for a really long time, and I really like the flexibility of being able to play around with system configurations, etc. without worrying about doing any damage to my host system. With snapshots enabled, I don't even have to worry very much about permanently damaging the VM itself. Also, as stated in the release notes  (and called out in this thread on the OTN Apple forum, where hope springs eternal and no one is ever bitter or cranky), the list of supported features for the OS X version is a bit shorter than one might expect. On the other hand, "unsupported" doesn't always mean "won't work," and the memory footprint of a native database is a bit less than that of a full OS + database running in a virtualized environment. My expectation is that for quick testing and tinkering, the native database install could fit a niche, but VM still rules for more advanced stuff like RAC, ASM, 11g, etc.

What's encouraging is that it appears that Oracle hasn't abandoned OS X as a platform. Feature set aside, I suspect they'll need to do more frequent releases before many people would be very comfortable using this in an enterprise setting. But this also opens the possibility of different licensing options...Express Edition for OS X, anyone? OSXXE?

If someone manages to port this to iPhone, though, let me know. That would rock.

It's almost a perfect setup. Between SQL Developer, JDeveloper, and Instant Client, I can do a lot of Oracle-related work natively on my Mac. For those instances where I need a tool that doesn't exist for OS X, virtualization software like Parallels and VMware Fusion can help to fill in the gaps. One feature of VMware Fusion that I really like is Unity, especially now that it's available for Linux in Fusion 2.0. Simply put, Unity allows the display of individual windows from a virtual machine without displaying that VM's desktop, offering a slightly more seamless user experience. The application launched from the VM behaves like any other application window on the Mac desktop: it appears in the Dock; I can use Cmd-Tab to select the app, minimize it, etc.

To tie all of that introductory rambling together, here's the topic of the post: an example of creating a Linux Unity application for an Oracle tool that I miss having on my Mac. I use Linux Unity to launch the Oracle 10gAS oidadmin client. The method I'm about to describe is a little bit clunky, but until VMware provides a more straightforward way to add your own apps, it'll do.

Setup steps

1. Launch a Linux virtual machine that has the oidadmin tool installed. For my example, I just installed the 10gR2 client software in an OEL5 VM, which was pretty straightforward. Michael McLaughlin has some good material on his blog on installing and configuring Oracle software in VMware Fusion, if you're looking for more direction.
2. Log in to your VM as a user that can run the oidadmin tool.
3. Invoke Unity mode. (cmd-ctrl-U)
4. Launch an application from the VMware Fusion Applications menu (cmd-L). I used Terminal for this example, which for me is the under Utility menu. This will create an application at the host level in your VM bundle, which you'll be using to create an application (oidadmin) of your own. Note: in the course of testing these instructions, I found that I needed to launch Terminal twice to generate the application bundle used in subsequent steps. YMMV.
5. Locate the package on your host that contains your VM, navigate to the folder named Applications, and create a copy of the Terminal application. If you're doing this in Finder, you'll need to 'Show package contents' on the VM bundle, as shown:

   

6. Rename the copied application to something suitable. In my case, I chose 'oidadmin'.
7. Open the Contents folder of the copied application (again, if you're using Finder, you'll need to Show Package Contents on the app bundle):

   

8. Edit the Info.plist file, and change the values of the CFBundleDisplayName, CFBundleName, and DOGuestAppURI keys to the appropriate values. the first two should reflect the new name of your app, and DOGuestURI needs to contain the absolute path to your oidadmin executable in your VM:

   

9. Save the changes to Info.plist and close the file.
10. Launch your new application!

Wow, that's a lot of screenshots

It's true; I went a little Flysketch-happy with this one. If you prefer the command line, here are alternatives to steps 5-8:

5. Use cd to navigate to the Applications folder of the VM bundle. No need to 'show package contents,' since the VM bundle just appears as a directory. In my example, the command would be: cd ~/VMs/VMware/ClientSoup.vmwarevm/Applications
6. Make a copy of the app bundle created in step 4: cp -r Terminal\ —\ ClientSoup.app oidadmin\ —\ ClientSoup.app
7. Use your favorite text editor to modify the Info.plist file: vi oidadmin\ —\ ClientSoup.app/Contents/Info.plist The contents won't be as pretty to browse as they are with the Property List Editor, but hey, they're all just strings, right?
8. Enjoy having one less step than those non-command-line people.

Launching the app

Here's your reward for all that hard work:

Once the new application is created, you can launch it just as you would any other Mac application. For best results, your virtual machine should be running and logged in as the use that can launch oidadmin. It's worth noting, however, that if the VM is suspended, attempting to launch the application will resume the VM. You'll just need to wait for the VM to restore its previous state. Here are just a few ways to launch the new oidadmin application:

• Navigate to the Applications folder of your VM package, as in step 5 above, to find the oidadmin.app and launch it directly. (yeah, I know: Ugh.)
• Create an alias to the new application and put the alias somewhere that's easier to access.
• For launching from the command line, you could create an alias:

  zathras:~ jpiwowar$ alias oidadmin='open -a ~/VMs/VMware/ClientSoup.vmwarevm/Applications/oidadmin\ —\ ClientSoup.app'
  zathras:~ jpiwowar$ oidadmin

• Use QuickSilver, if you're into that sort of thing:

  

It's still not perfect

I'm still tinkering with using the Unity feature in Linux VMs, and figuring out whether the limitations I'm seeing are perceived or real. This is what I've seen so far that is less than ideal:

• I haven't found a way to easily add my own applications to the seeded list in the Applications menu, which is why I engage in the copy app/rename app/edit info.plist cycle described above.
• The host OS doesn't seem to always recognize when an application launched from the VM has exited. Even after closing the window on the VM, an icon for the app still remains in the Dock. To re-open the application, I've found that I either have to launch it twice, or click on the orphan Dock icon to make it go away prior to attempting a re-launch.

That's all, folks

And that's how I run oidadmin on my Mac. I hope that someone out there in Internet-land finds this to be useful. If so, toss me a comment!

• Multiple snapshots can be a blessing and a curse. The curse mostly comes into play when cleaning up snapshots on VMs that have large disks (such as E-Business Suite servers), but there are a lot of instances where I wish I had more than one "save point."
• Lower resource utilization probably doesn't mean the ability to create 4GB of RAM from 2GB, but anything that frees up more resources for the host has to be a good thing, and based on my experience using ESX server, VMware knows resource management pretty well.
• Linux Unity may seem like a fluffy thing to like, but it fits a need for me: the ability to run non-Mac-native Oracle client tools, such as oidadmin, without having to deal with either setting an X display (involves typing) or using a Windows OS (involves, um, Windows).
• Scripting with vmrun may allow me to throw out my functional-but-clunky Perl script for cloning VMs, and stop worrying if a vmx file format change in future releases will break the script.
• Running a VM "headless" would be pretty cool. That's not in the release notes, but it is in the VMware Fusion Power User's Guide, which, by the way, is a document well worth reading.

The current version of VMware Fusion is already a pretty solid product, but the 2.0 features are really bringing Fusion up to a level that more closely matches its Windows counterpart, VMware Workstation. Virtualization on the Mac is becoming a much richer experience. Now, if VMware could just release a Mac version of the Virtual Infrastructure Client, my VMware+Mac wish-list would be all but complete.

Of course, I've yet to take the beta for a test drive, so maybe I'm falling prey to marketing ("Ooo, look, shiny things"). Regrettably, it wouldn't be the first time. My initial plan was to hold off rocking the boat with my VMware machines and just wait until VMware Fusion 2.0 was fully released, but some of these features are making me rethink my "betas in VMs, not VMs in betas" rule. If nothing else, I think I have to satisfy my "I wonder if that means what I think it means" curiosity. After all, it's not like I have a production environment to worry about these days...

Whoops

Apologies for the two-post drift into Mac-land. It is a bit of a risk when reading here...I try not to be a drooling fanboy, but I really like my MBP. I'll be getting back to Oracle stuff, Oracle Apps specifically, with my next few posts.

The setup

As it turns out, while the release notes provide an example for configuring the desired behavior, getting SQL Developer to effectively launch SQL*Plus is non-trivial on a system where Instant Client is the only other client software available. I'll discuss the reasons in the next section, but for the benefit of any impatient googlers, here's what I ended up doing.

First, I created a small shell script, called launchsqlplus.sh, as shown below. The values for the three environment variables (ORACLE_HOME, PATH, DYLD_LIBRARY_PATH) on your system will likely be different from mine, but you get the idea.

#!/bin/bash
export ORACLE_HOME=/u01/app/oracle/product/10gClient
export PATH=$PATH:$ORACLE_HOME/bin
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$ORACLE_HOME/instantclient_10_2
dbuser=$1
dbconn=`echo $2 | awk -F \@ '{print $2}'`
sqlfile=$3
sqlplus $dbuser@\'$dbconn\' @$sqlfile

This shell script does the following:

1. Adds the location of sqlplus on my system to the PATH. I've deviated slightly from the Instant Client install docs here, and created a separate bin directory for sqlplus.
2. Adds the location of the Instant Client shared libraries to DYLD_LIBRARY_PATH.
3. Assigns more human-readable names to the input parameters for the script, and parses the database connect string generated by SQL Developer to something usable by the Instant Client (more on that later).
4. Launches SQL*Plus with the arguments passed from SQL Developer

After saving the script in an appropriate place, and setting it executable (chmod u+x launchsqlplus.sh), I moved on to setting up SQL Developer. The following screenshots demonstrate the steps:

Quick notes on the contents of the fields, especially since the 'Arguments' field would require a ridiculously wide (and large) screenshot:

Program executable

I'm launching SQL*Plus in an xterm. If you have a favorite terminal window that takes arguments in a way that's similar to xterm's -e option, you could probably substitute the path to that window here. I briefly played around with trying to launch SQL*Plus with Terminal.app, but decided I just didn't care enough and stuck with xterm instead.

Arguments

Pasted here in full since they don't show in the screenshot:
-e /Users/jpiwowar/bin/launchsqlplus.sh ${sqldev.dbuser} ${sqldev.conn} ${file.path}
Note the full path to the shell script, and the use of some of the macros discussed in the SQL Developer release notes.

Run Directory

I don't have anything defined here, but if your SQL script dumps out log information without an absolute path for the logfile, you might want to set up a default directory here.

Command sample

Not user-editable, but a thoughtful feature nonetheless for debugging purposes. Here's how it looks for my demo:
/usr/X11/bin/xterm -e /Users/jpiwowar/bin/launchsqlplus.sh system jdbc:oracle:thin:@vir:1563/JPTEST.dbdomain /Applications/SQLDeveloper.app/Contents/Resources/sqldeveloper/sqldeveloper/bin/test.sql

Not too much to say here. Specify whatever you like for the menu item label...

Choose what you like for Step 3 as well. I leave the "Save All before tool starts" option unchecked, because I'd rather forget to save before running the script than accidentally wreck a file by running SQL*Plus. But maybe that's just me.

...and we're done!

The payoff

After putting it all together, here's the outcome:

Some things to note:

• I ran the script in SQL Developer with the "Run script" option before invoking SQL*Plus. As far as I know, this is necessary to associate the script with a database connection and populate the sqldev.user and sqldev.conn macros used in the External Tools definition. As you can see from the screenshot, SQL Developer strips out the 'set linesize' output format command.
• The password prompt for the SQL*Plus connection appears in the xterm. It may be possible to make SQL Developer prompt for the password and pass it along to the shell script, probably via the "Prompt" or "Prompt with Label" macro. I haven't tinkered with that option yet.
• The log window at the bottom of the SQL Developer UI can be a useful place to start investigation if SQL*Plus doesn't launch as you'd expect.

The annoying bits

Why go through all the work of setting up a shell script wrapper for launching SQL*Plus? Well, for a handful of reasons. First, SQL Developer's database connection string generated by the sqldev.conn macro doesn't work as-is with the Instant Client. The JDBC Thin connect string provided needs to be parsed a little to strip out the jdbc:oracle:thin:@, which is the purpose of the awk command in the shell script.

There are a lot of ways to work around the above issue without resorting to a shell script. The tougher problem is that SQL Developer doesn't seem to care about your environment. Well, you know, it cares, but it's just been really busy... I not only had to call executables by absolute path, but also had to find a way to set DYLD_LIBRARY_PATH in order for SQL*Plus to run. In theory, it's possible to use environment.plist at the user level to set these environment variables, or to modify the Info.plist file for SQL Developer, or even insert the environment variable definitions in the sqldeveloper.sh script that launches the application. In practice, however, the ability to set DYLD_LIBRARY_PATH via environment.plist was apparently broken a while back, perhaps intentionally as part of a security update, and I'm reluctant to modify files shipped with the application that are likely to be overwritten during an update.

I'll admit that I haven't researched all of these issues to the point where I am 100% certain that they are unresolvable. After spending a little time playing around with different options (and engaging in some decidedly unprofessional muttering), I just decided to slap together a short shell script to do what I wanted. Inelegant, but predictable. I'm sure a cleaner solution exists, and would love a demonstration that I'm making this way more complicated than it needs to be.