Bug in Oracle DST Patch Rollback

I’ve done a few patches now — on Windows, Linux, Solaris and on many platforms for both 9i and 10g, some with physical standbys and others without. The lesson that I’ve taken away from them is that rolling back is twice the fun of actually applying the patch.

Last week, we discovered a bug related to the rollback of the Java DST patch for 9206 on Linux x86. If you’re in the unfortunate position of needing to roll this patch back, you won’t be able to. It turns out that the patch instructions omit telling you to also back up the classes.bin file in addition to
$ORACLE_HOME/javavm/admin/libjox9java_util.so.

When you rollback, you need to restore both of these files, and then do a create or replace java system. Otherwise you risk hitting a dreaded ORA-03114 End of file on communication channel.

In my case, when I followed the patch instructions, the Java test case given to us by Oracle still returned a 1. Those of you familiar with DST patching will have seen this, but for those who haven’t, here are the scripts you need to check for
a successful Java implementation:

create or replace java source named "OffsetFromStandard" as
import java.util.Calendar;
import java.util.GregorianCalendar;
import java.util.TimeZone;

public class OffsetFromStandard
{
    public static int getDSTOffset(String timezone, int year,                                 
                                   int month, int mday, 
                                   int hour, int min, int sec)
    {
        TimeZone tz = TimeZone.getTimeZone(timezone);
        GregorianCalendar c = new GregorianCalendar(tz);
        c.set(year, month-1, mday, hour, min, sec);
        return c.get(Calendar.DST_OFFSET);
    }
}
/

alter java class "OffsetFromStandard" resolve
/

CREATE OR REPLACE function get_dst_offset (
                           timezone VARCHAR2, year NUMBER,
                           month NUMBER, mday NUMBER,
                           hour NUMBER, min NUMBER, sec NUMBER
                                          ) 
RETURN NUMBER AS LANGUAGE JAVA NAME 
'OffsetFromStandard.getDSTOffset (java.lang.String, int, int, int, int, int, int) 
return int';
/

select get_dst_offset('America/Los_Angeles', 2007, 3, 11, 10, 0, 0)/(60*60*1000) as OFFSET_FROM_STANDARD_TIME from dual;

OFFSET_FROM_STANDARD_TIME
-------------------------
1

Of course, you would expect a 0 after a rollback, but alas that isn’t the case — it still gave me a 1. So, I ran the process to reinstall jvm (using rmjvm and initjvm). The initjvm dies on an ORA-03114.

The only way to fix this is to also restore a classes.bin file from an unpatched system. Only then will your Java be restored to a pre-patched state. Do not expect to find anything on this bug in metalink. Apparently we were the first people to be hit with this.

Best of luck!
Shakir.