Socket Based Licensing for Standard Edition

I ran across this article today on Oracle’s new strategy for Standard Edition and Standard Edition One licensing.

As a consultant, there are times when I have to tackle licensing questions, though I usually try to stay away from it and let Oracle’s salespeople do that job.

However, I found this news quite interesting. In order to compete with Microsoft and other database vendors in the small and midsize business market, Oracle has changed their licensing model on Standard Edition and Standard Edition One. Instead of a per-core licensing scheme, licensing for these products is now on a per-socket basis. Not only does this make pricing cheaper on multi-core systems, it also makes things much easier for the accounting department!

Of course, it’s still the same for Enterprise Edition (the article calls it tortuous), but perhaps that will change soon as well. Hey, at least we’re no longer using Power Units!

I’m not a big fan of ignoring errors with OUI (we all have our horror stories), and so when I ran across this one I was loathe to ignore or cancel:

Error in invoking target 'all_no_orcl ipc_g' of makefile

Now, an experienced Oracle installer/patcher/troubleshooter/slave knows full well that most of these problems are compiler related, and this one was no different. I was patching a 10.2.0.1.0 RAC installation to 10.2.0.3.0.

To fix the problem, simply go to Oracle’s Open Source Downloads and download the latest binutils release. Install it with the following command:

rpm -Uvh binutils-2.15.92.0.2-15.0.0.0.2.x86_64.rpm

Once installed, click “retry” on your OUI screen and everything should be taken care of! However, if this is a RAC system, don’t forget to install binutils on both nodes!

If you DID ignore the error and kept going with the patch, you’ll probably find that ASM does not work. To fix this, you will have to install binutils, relink all, and find a good working copy of $ORACLE_HOME/lib/libskgxp10.so from another Oracle installation to replace the one on your patched system.

The moral of the story is, of course, to fix problems before continuing whenever possible.

Errors During CATUPGRD.SQL

While I’m at it, another problem I found was during the execution of the CATUPGRD.SQL script that must be run after installing the Oracle software. I received the following error:


SELECT version_script AS file_name FROM DUAL
*
ERROR at line 1:
ORA-06575: Package or function VERSION_SCRIPT is in an invalid state

Thankfully, this was an easy enough problem to fix. Simply change some initialization parameters:

1. alter system set plsql_code_type string = INTERPRETED
2. alter system set plsql_compiler_flags string = INTERPRETED, NON_DEBUG
3. Rerun ?/rdbms/admin/catupgrd.sql

Or, if you really want to use native PL/SQL compilation, just set your plsql_native_library_dir and then rerun the script.

One Last Note

Make SURE you set your JAVA_POOL_SIZE and SHARED_POOL_SIZE to at least 150M before running catupgrd.sql! If you do not have a large enough shared pool, you will get errors during the install. You may be able to workaround these by flushing the shared pool (alter system flush shared_pool), but you’re better off doing it right the first time.

Good luck with your patch upgrades!