Monday, September 6, 2010

Oracle Database Server Install Frustrations

After once again installing a local Oracle Database server instance for some local development, this post is mostly focused on some repeated frustrations that I felt are worth sharing.

Database Server

The first issue is the download. 2.06 GB for "Oracle Database 11g Release 2 ( for Microsoft Windows (x64)". This should be easily and significantly reducible, if a "core" package were provided with optional features available separately (more later). I am aware of the "Express Edition". Unfortunately, the Express Edition only appears to be available for 10g, and won't help for development containing 11g-specific features.

During installation, the "Select Database Edition" is a rather interesting screen:

Enterprise Edition, Standard Edition, Standard Edition One, Personal Edition

4 editions, all weighing in at 3.29 GB or 3.34 GB - with a difference of only about 51 MB. Additionally, the "Select Options" button is only enabled for "Enterprise Edition" - and only allows for selection of 7 components: Oracle Partitioning, Oracle OLAP, Oracle Label Security, Oracle Data Mining RDBMS Files, Oracle Database Vault option, Oracle Real Application Testing, and Oracle Database Extensions for .NET.

As far as I can tell, there are no additional options for controlling the individual desktop features to install, e.g. the various "Configuration and Migration Tools", "Warehouse Builder", and "SQL Developer".

After installation, a quick review finds the following unnecessary components (maybe necessary, but duplicated). Most are also rather outdated:

  • Java:
    • Under the Oracle Home folder, a "jdk" folder containing a 64-bit version of 1.5.0_17-b04, consuming 71 MB. I found that this is also the version used by the Universal Installer.
    • Also under the Oracle Home folder, a "jre" folder containing a 64-bit version of, consuming 61 MB. Can't whatever uses this JRE just use the JRE contained within the above JDK instead?
    • The version of Java returned from within the Oracle Database is 1.5.0_10, so the database server itself doesn't appear to depend on either of the above.
    • The latest update of Java 1.5 is update 22 - compared to the 10, 11, and 17 from above. Also, where's the support for Java 1.6 / 6.0?
  • Oracle SQL Developer:
    • The version installed is 1.5.5, from April 2008, compared to the significantly-improved and latest 2.1 from December 2009-March 2010.
    • Consumes 81 MB.
    • Does not even launch from the Start Menu after installation, as the shortcut references a non-existent "C:\oracle\product\11.2.0\dbhome_1\SQLDEVELOPER\SQLDEVELOPER\BIN\SQLDEVELOPER.BAT".
    • Even after fixing the shortcut to point directly to "sqldeveloperW.exe" in the same directory, this version of SQL Developer is 32-bit only, and requires a 32-bit JVM - which isn't installed as part of the 64-bit Oracle Database server installation.

Why can't Java be optionally unbundled from the server installation, listed as a pre-requisite, and an appropriate version prompted for during installation? Many other Java-based products do this, including Oracle's own JDeveloper and SQL Developer.

SQL Developer should also be unbundled, or at least made an optional component during installation - especially as it follows its own release cycle.

As the server installation appears to include the full client, why can't the server installer also include the options from the client installer - which provides 27 components to select from, including SQL*Plus and Oracle SQL Developer? Otherwise, the server installation should be restricted to server components only - and then the client installation used to install the desktop components.

Database Instances

Again, my purpose is only for a development database instance. As it is non-production, I am not concerned with all the best practices around disk usages - such as data files, index files, and redo logs all on separate disks. However, I do prefer to have the database files stored on a separate drive (physical or logical) from the server. This allows for re-installation the operating system and any "program files" (including Oracle Database server), without concern for documents and other data files (such as the Oracle database data files). While Oracle provides their "Optimal Flexible Architecture" (OFA), this does not appear to provide for any of the concerns mentioned above - at least not through the current UIs, and the default templates used by the "Database Configuration Assistant". The "File Location Variables" shows 5 default and unmodifiable variables, including "ORACLE_BASE" and "ORACLE_HOME", with all storage files configured under "{ORACLE_BASE}\oradata\" in the default templates.

The best solution I found is to create a new File Location Variable e.g. "DB_FILES" (which is allowed through the UI), set it to a location on another drive, update all the references from "ORACLE_BASE" to "DB_FILES" in the "Database Storage" configuration screen, then save the configuration as a new Database Template for future use.

Enterprise Manager

A typical Windows process tree for Enterprise Manager (EM) looks like this:
  • nmesrvc.exe
    • cmd.exe
      • perl.exe
        • cmd.exe
          • java.exe
        • emagent.exe
        • cmd.exe
          • emdctl.exe

Even on an idle server without any user connections, the "cmd.exe / emdctl.exe" sub-tree is constantly re-spawned - running for only a few seconds, and then gone for another few seconds until the processes are restarted by perl. emagent.exe also regularly starts its own child processes, including another perl.exe - as well as others.

This looks like another great opportunity for Oracle development to make some improvements. Even just removing the extra cmd.exe instances and having perl call out to java.exe and emdctl.exe would be a significant improvement. Or does cmd.exe bring some extra value to the process that I'm not seeing, and that perl.exe can't offer?

For now, this looks like a lot of extra bloat to leave running, especially for a developer machine where EM will rarely be used after initial configuration. I recommend changing the "OracleDBConsole<SID>" Windows service to have a "Startup type" of "Manual" instead of "Automatic" - and to only have it running when necessary.

No comments: