Thursday, February 16, 2012

DBUA failing with ORA-00823 ORA-01078 followed by ORA-01034

In the process of upgrading 10.2.0.4 database to 11.2.0.2, got below error when dbua tried to start the database instance using 11g binaries:


Background:
This database has below parameters EXPLICITLY set
sga_max_size 500M
sga_target 500M


Output of Pre-Upgrade tool:
I had run pre-upgrade tool(utlu112i.sql), before starting dbua. It showed me:

..
..
--> If Target Oracle is 64-Bit, refer here for Update Parameters:                                
WARNING: --> "sga_target" needs to be increased to at least 708 MB                              

..
..
DBUA:
DBUA takes care of changing the values. So I did not attempt to modify it manually.

And dbua did change for sga_target.

DBUA apparently changed value of "sga_target" to 708MB but did not change the value of "sga_max_size" accordingly.

Its a known fact that if sga_max_size can not be set lower than sga_target.

Now when dbua tried to start the instance after changing JUST sga_target , it threw ORA-00823.

If you are thinking ignore might work, then its wrong. Because the upgrade would eventually fail with ORA-01034 because dbua was not able to start the instance at first place.

Resolution:

1. You will have to Abort the upgrade.
2. Remove sga_max_size from your pfile. If you are using spfile, then create pfile first.
3. Create spfile if you want to use spfile instead of pfile.
4. Restart dbua.


Tuesday, February 14, 2012

cc: warning 487: Possibly incorrect message catalog.

On HP-UX PA RISC:
===============
I was applying patch 13343244(CPU JAN'12) to 11.2.0.2 RDBMS home. The make step failed with below message:
Running make for target client_sharedlib
Running make for target client_sharedlib
Running make for target ioracle

OPatch found the word "failed" in the stderr of the make command.
Please look at this stderr. You can re-run this make command.
Stderr output:
cc: warning 487: Possibly incorrect message catalog.
total_lntt_bytes is 0, assuming size of .debug_lntt
Failed to mmap lntt temp file. File won't be debuggable (still a valid executable).



The local system has been patched and can be restarted.


UtilSession: N-Apply done.
--------------------------------------------------------------------------------
The following warnings have occurred during OPatch execution:
1) OUI-67215:
OPatch found the word "failed" in the stderr of the make command.
Please look at this stderr. You can re-run this make command.
Stderr output:
cc: warning 487: Possibly incorrect message catalog.
total_lntt_bytes is 0, assuming size of .debug_lntt
Failed to mmap lntt temp file. File won't be debuggable (still a valid executable).


--------------------------------------------------------------------------------
OPatch Session completed with warnings.

OPatch completed with warnings.


I checked output of "opatch lsinventory" and it showed correct information.
I restarted the database and listener without any issues.

Searched on Google to find if anyone has encountered this error. From the information I gathered it seems ansi C compiler issue.

So far I haven't seen any negative impact of this warning.

I searched by "total_lntt_bytes is 0, assuming size of .debug_lntt" and found below link which says we can ignore this warning (issue 4):

ftp://ftp.hj.se/Oracle/Patchar/11.1.0.7/PSU_OCT_2011/download.htm#BGBGADGB

Hope this helps.


Friday, February 10, 2012

opatch[432]: -d64: not found.

This is only happening on HP boxes.

Whenever I type any opatch command, the opatch runs fine but it shows below line at the beginning of output:


./opatch[432]: -d64:  not found.


I wanted to see what does that mean. opatch has below at line# 432
..
..
JRE_MEMORY_OPTIONS=${MEM_ARGS} ${JVM_D64}
..
..




Putting double quotes around ${MEM_ARGS} ${JVM_D64} fixed the issue.

e.g.
..
..
JRE_MEMORY_OPTIONS="${MEM_ARGS} ${JVM_D64}"
..
..

BTW, this is not just limited to HP-IA, this also happened on HP PA-RISC.

Also realized that this is fixed in new version of opatch i.e. OPatch Version: 11.1.0.9.4

Monday, February 6, 2012

rwserver: error while loading shared libraries: libXm.so.3

Reports server failed to start while domain configuration:
$INSTANCE_HOME/diagnostics/logs/ReportsServerComponent/RptSvr_<host>_<inst_name> has console~RptSvr_<hostname>_<inst_name>~1.log file which showed below error:

..
--------
12/02/02 16:03:20 Start process
--------
/oracle/product/Middleware11g/fmw11g/bin/rwserver: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory
..


In our case openmotif22 64-Bit  was NOT installed. 32-Bit was installed.

After installing 64-Bit openmotif22, we were able to start reports server without any issues.

Friday, February 3, 2012

OPatch failed with error code 39 (oracle.jrf.j2ee)

I was applying patch 13113594 (CPU JAN'12) to Oracle Web Tier home and received below error:
Oracle Interim Patch Installer version 11.1.0.9.4
Copyright (c) 2011, Oracle Corporation.  All rights reserved.


Oracle Home       : /oracle/product/Middleware11g/Oracle_WT1
Central Inventory : /oracle/oraInventory
   from           : /oracle/product/Middleware11g/Oracle_WT1/oraInst.loc
OPatch version    : 11.1.0.9.4
OUI version       : 11.1.0.9.0
Log file location : /oracle/product/Middleware11g/Oracle_WT1/cfgtoollogs/opatch/13113594_Feb_02_2012_12_32_20/apply2012-02-02_12-32-19PM_1.log


OPatch detects the Middleware Home as "/oracle/product/Middleware11g"

OPatch will do the following:
[Oracle Home discovery]                      : Configure and Validate Oracle Home info.
[Prerequisite for apply]                     : Invoke prerequisites to see if patch can be applied.
[Patch conflict detection for apply patch]   : Check if any conflict with already installed patches in Oracle Home.

Applying interim patch '13113594' to OH '/oracle/product/Middleware11g/Oracle_WT1'
Verifying environment and performing prerequisite checks...
Prerequisite check "CheckApplicable" failed.
The details are:
Patch 13113594: Required component(s) missing : [ oracle.jrf.j2ee, 11.1.1.4.0 ]
Log file location: /oracle/product/Middleware11g/Oracle_WT1/cfgtoollogs/opatch/13113594_Feb_02_2012_12_32_20/apply2012-02-02_12-32-19PM_1.log

Recommended actions: This patch requires some components to be installed in the home. Either the Oracle Home doesn't have the components or this patch is not suitable for this Oracle Home.

OPatch failed with error code 39

The problem is evident when I carefully read the patch README. The patch should be applied to $MW_HOME/oracle_common as the JRF component is installed in oracle_common automatically.

So follow readme preinstall instructions which say set ORACLE_HOME to $MW_HOME/oracle_common