Applying RU (Release Update) to Oracle 18c

Since Oracle 12cR2 RU(Release Update) and RUR (Release Update Revision) was introduced by Oracle for patching every quarter.

The following is the guide in how to apply RU to Oracle 18c release, as you might know Oracle introduced 18c on-premise with 18.3 release….here i am applying January 2019 Oracle Security Patch release which is 18.5.

its worth pointing out that you might face patching issues…..check the below helpful references i blogged about it before:

https://geodatamaster.com/2018/07/19/oracle-psu-july-2018-error-ora-20001-latest-xml-inventory-is-not-loaded-into-table/

https://geodatamaster.com/2018/11/04/oracle-ojvm-psu-error/

download the latest RU patch and place it in a directory accessible by your database server:

cd /oracle-app/linux/18c_RU/18.5_DB/28822489

/$ORACLE_HOME/OPatch/opatch apply

opatch2

opatch222

sqlplus / as sysdba

SQL> STARTUP

exit

cd $ORACLE_HOME/OPatch

./datapatch -verbose

datapatch1

*** Post-Patch verification:

sqlplus / as sysdba
SQL> @?/rdbms/admin/utlrp.sql
//check your database components

SQL> select COMP_NAME,STATUS from dba_registry;
// query to list applied patches on the database instance:

SQL > select * from dba_registry_sqlpatch;

dba_registry_sqlpatch1

so the database has been successfully patched with full release number 18.5.0.0190115

if your database has “java” component, you need to download the java patch (OJVM) and repeat the above steps….except that you will startup the database in upgrade mode before running the data-patch.

I hope this is helpful……have a nice day.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

JVM Corruption and ORA-7445

The intention of this blog is to share a problem faced in a production instance. its strongly advised when you face ORA-7445 error is to contact Oracle Support and open a case with them.

So, my objective is to help here ….

what are the symptoms faced ?

Database version is 12cR1 (12.1.0.2.181016)

Database Alert log file has the following errors:

Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x7440038090] [PC:0x7FEA4DB100D4, java_nio_Bits__byteOrder()+204] [flags: 0x0, count: 1]

DDE: Problem Key ‘ORA 7445 [java_nio_Bits__byteOrder]’ was completely flood controlled (0x6) Further messages for this problem key will be suppressed for up to 10 minutes

When executing SQL Scripts using sqlplus….for example utlrp.sql the following errors were thrown:

SQL> @/rdbms/admin/utlrp.sql
ERROR at line 1:
ORA-03113: end-of-file on communication channel 

Process ID: 105404
Session ID: 2878 Serial number: 20833

Errors received from application side deployed in weblogic:

No More Data To Read From Socket

 

The reason of such symptoms is JVM Corruption !

To resolve this issue:

 

  1. Check JVM status by executing the following script:

 

spool jvm_info.log
—— REGISTRY INFO ——
SELECT SUBSTR(comp_name, 1, 30) comp_name, SUBSTR(version, 1, 20) version, status
FROM dba_registry
ORDER BY comp_name;
—— REGISTRY HISTORY ——-
SELECT TO_CHAR(action_time, ‘DD-MON-YYYY HH24:MI:SS’) act_time, action, version, id, comments
FROM dba_registry_history
ORDER BY action_time DESC;

—— JAVA OBJECT INFO ——
— Are there a substantial number of VALID Java objects in SYS?
SELECT owner, object_type, status, COUNT(*)
FROM dba_objects
WHERE object_type LIKE ‘%JAVA%’
GROUP BY owner, object_type, status
ORDER BY owner, object_type, status;
— Is the DBMS_JAVA package VALID?
SELECT owner, object_name, object_type, status
FROM dba_objects
WHERE object_name LIKE ‘DBMS_JAVA%’
OR object_name LIKE ‘%INITJVMAUX%’
ORDER BY owner, object_name, object_type;
— Are there any INVALID Java objects in SYS?
SELECT owner, NVL(longdbcs,object_name) long_name, object_type, status
FROM dba_objects, sys.javasnm$
WHERE object_type LIKE ‘%JAVA%’
AND status <> ‘VALID’
AND short (+) = object_name
ORDER BY owner, long_name, object_type;
—— JAVA ROLE INFO ——
— The number expected varies by release.
SELECT role
FROM dba_roles
WHERE role LIKE ‘%JAVA%’
ORDER BY role;
—— MEMORY INFO ——
SELECT *
FROM v$sgastat
WHERE pool = ‘java pool’ OR name = ‘free memory’
ORDER BY pool, name;
—— DATABASE PARAMETER INFO ——
show parameter pool_size
show parameter target
show parameter sga
—— TEST JAVAVM USAGE (and return the JDK version if > 11g) ——
— Calling routines in DBMS_JAVA will invoke the JavaVM and expose certain problems.
SET SERVEROUTPUT ON
DECLARE
ver NUMBER := 0;
val VARCHAR2(30);
BEGIN
BEGIN
SELECT TO_NUMBER( SUBSTR(version, 1, 2) )
INTO ver
FROM dba_registry
WHERE comp_name = ‘JServer JAVA Virtual Machine’;
EXCEPTION
WHEN OTHERS THEN NULL;
END;
IF ver >= 12 THEN
EXECUTE IMMEDIATE
‘SELECT ”JDK version is ” ||
dbms_java.get_jdk_version() FROM dual’
INTO val;
ELSE
val := dbms_java.longname(‘JDK version not available’);
END IF;
dbms_output.put_line(val);
END;
/

spool off;

  1. Repair JVM:

 

**** Note down the current value of parameters JAVA_JIT_ENABLED & JOB_QUEUE_PROCESSES

 

spool create_Java.log

set echo on

connect / as sysdba

Alter system set JAVA_JIT_ENABLED=FALSE scope=both;

alter system set “_system_trig_enabled” = false scope=memory;

alter system set JOB_QUEUE_PROCESSES=0;

create or replace java system

/

@?/rdbms/admin/utlrp.sql

set echo off

spool off

exit

Then reset it back to original values you noted down:

SQL> alter system set java_jit_enabled = true;

SQL> alter system set “_system_trig_enabled”=TRUE;

SQL> alter system set JOB_QUEUE_PROCESSES=50;

SQL> @?/rdbms/admin/utlrp.sql

  1. Test that everything is ok:

 

Check database components

SQL> select * from dba_registry;

SQL> SELECT dbms_java.longname(‘TEST’) long_name FROM dual;