Applying Patchset 10.2.0.3 - A Warning

I will soon be installing Oracle Database 10g 10.2.0 at several customer locations, so I began going through our local installation procedures using an old Pentium III single CPU with 512MB RAM running Windows 2000. Thought it might be a good idea to apply the 10.2.0.3 patchset. No problems until I got to these post-installation instructions:

Determine the current values of these parameters:
SQL> SHOW PARAMETER SHARED_POOL_SIZE
SQL> SHOW PARAMETER JAVA_POOL_SIZE

So I ran the commands and got the following response:

NAME TYPE VALUE
------------------------------------ ----------- -----
shared_pool_size big integer 0

NAME TYPE VALUE
------------------------------------ ----------- -----
java_pool_size big integer 0

Hmmm. . . 0, as in ZERO. So I followed the next step in the readme:

If the system is using a server parameter file: If necessary, set the value of the SHARED_POOL_SIZE initialization parameter to at least 150 MB:

SQL> ALTER SYSTEM SET SHARED_POOL_SIZE='150M' SCOPE=spfile;

If necessary, set the value of the JAVA_POOL_SIZE initialization
parameter to at least 150 MB:

SQL> ALTER SYSTEM SET JAVA_POOL_SIZE='150M' SCOPE=spfile;

I executed the above commands without errors, and then attempted to start the database in upgrade mode. This was the response I got:

SQL> startup upgrade
ORA-00821: Specified value of sga_target 160M is too small, needs to be at least 320M

The readme addresses this error:

Note:

The value of the SGA_TARGET parameter depends on the environment. If you receive a system error when you restart the database, increase the value of the SGA_TARGET parameter to the value specified in the error.

So I tried to start the instance using the nomount option:

SQL> startup nomount

ORA-00821: Specified value of sga_target 160M is too small, needs to be at least 320M

I went ahead and tried setting the SGA_TARGET parameter anyways:

SQL> alter system set sga_target='320m' scope=spfile;
alter system set sga_target='320m' scope=spfile
*
ERROR at line 1:
ORA-01034: ORACLE not available

Okay, let's use the pfile I made before applying the patchset (and successfully started the database with):

SQL> startup pfile=D:\oracle\foobardb_init.ora
ORACLE instance started.

Total System Global Area 167772160 bytes
Fixed Size 1289484 bytes
Variable Size 88081140 bytes
Database Buffers 71303168 bytes
Redo Buffers 7098368 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced

Looks like it's well and truly hosed. I could spend several hours (more likely days) on the OTN forums and Metalink looking for a fix, or I could wipe Oracle from the registry, delete the ORACLE_HOME from the hard drive, and re-install the database saving myself hours (likely days) of confusion and frustration.

I don't know what I did wrong. The SHARED_POOL_SIZE and JAVA_POOL_SIZE parameters returned values of 0. Did I really need to alter them to run the catupgrd.sql script?

But if anyone out there does know what went wrong, I'd be interested to know.

xmlns:xsi Strikes Again

I thought I would work through a simple JSF tutorial - very easy, no data sources, just three JSPs. But when I try to deploy it to my OAS 10g 10.1.2.0.2 dev server, I get the dreaded

Deployment failed: Nested exception
Resolution:

Base Exception:
java.rmi.RemoteException
deploy failed!: ; nested exception is:
oracle.oc4j.admin.internal.DeployerException: Unknown assembly root-tag attribute: xmlns:xsi. deploy failed!: ; nested exception is:
oracle.oc4j.admin.internal.DeployerException: Unknown assembly root-tag attribute: xmlns:xsi

This is a compatibility problem between JDeveloper 10.1.3 and OAS 10.1.2 that I've run into before. So I searched my JDeveloper project folders for xmlns:xsi, found two files, removed the offending tag and I still get the error.

WTF?

This is why there's an I Hate Oracle club. . .

Screw it. It's Friday afternoon; I have a sailboat race tomorrow, and, unlike Larry Ellison, I'll probably win.

SSO, OID, Multiple Realms, and Windows - A Sob Story

Was in the process of setting up a test environment to test my PKI certificate Forms/SSO login module's ability to login users who's DNs didn't match the default realm and discovered I would need to register the second realm with SSO after creating it in OID.

Dug into section 10 of the Oracle Application Server Single Sign-On Administrator's Guide and lo and behold the two scripts provided by Oracle to register a second realm with SSO are C shell scripts, specifically enblhstg.csh and addsub.csh.

C shell scripts don't run on a Windows box. In fact, the guide helpfully tells you this. No .bat files, no perl, just C shell scripts.

I worked until 10:00 p.m. last night (we're on a Monday deadline to deliver this solution) de-coding the scripts. I found two PL/SQL scripts and one procedure that applied to SSO (the rest are for Portal, which we don't use). I did some further de-coding and figured out what parameters these scripts needed. I got one of the scripts to run successfully from SQL*Plus, the second I de-coded further and did a manual insert into orasso.wwsub_model$ of what I assumed to be the correct values. But it didn't work, SSO does not recognize the second realm and now I'm waiting while my OAS 1012 installation wipes itself out. I'll rebuild it and set the default OID realm at the highest level possible (dc=com) and hope that the containers I create under it for the different DN's works - but I'm not too optimistic and I've kissed my weekend goodbye.

I discovered this blog has been linked to an Oracle blog aggregator - if anyone from Oracle is reading this please tell us WHY you would ship a product for a Windows platform but provide scripts that can only be run on UNIX/LINUX platforms?

I mean really - what the hell?

#%@$&! data-sources.xml!

After chugging along happily with my project and figuring out how to connect to an Oracle database using the jdbc thin driver from a servlet I ran into yet another JDev 10.1.3 - OAS 10.1.2 gotcha - the data-sources.xml file.

This file contains the jndi database connection info used by an OC4J to connect an application to a backend database. Although the ADF Developer's Guide for Forms/4GL Developers contains instructions for creating OAS 10.1.2 compliant deployment descriptor files, it doesn't mention that when JDev 10.1.3 actually loads data into these files it won't be OAS 10.1.2 compliant.

My project ran great with JDev's 10.1.3 embedded OC4J, but when I tried to deploy it to my OAS 10.1.2 OC4J, I got errors complaining of unrecognized tags in the data-sources.xml file. I searched the J2EE directory in OAS 10.1.2, found a sample data-sources.xml file, and copied what I hoped was the correct information from my JDev 10.1.3-created data-sources.xml file. Long story short: it worked. But what a PITA.