BEA-000286 Failed to invoke startup class "JRF Startup Class" ADF ManagedServer

Version:

WLS 10.3.6 and ADR 11.1.1.7.0 on Windows

Issue:

Getting errors when Managed Server was tried to start from weblogic console URL. Nodemanager was up and its status in console was Active. The same Managed Server can be started up using startManagedserver.cmd

Error:

<Dec 15, 2014 11:28:03 PM MST> <Critical> <WebLogicServer> <BEA-000286> <Failed to invoke startup class "JRF Startup Class", java.lang.ClassNotFoundException: oracle.jrf.wls.JRFStartup
java.lang.ClassNotFoundException: oracle.jrf.wls.JRFStartup
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
Truncated. see log file for complete stacktrace

Reason:

From logs it was clear that issue is because of missing JRF classes in CLASSPATH.

JRF(Java Required Files) includes important libraries and capabilities that provides APIs that many OC4J (Oracle Container for Java, Oracle’s old JVM) applications depend upon.  JRF comes (under $MW_HOME/oracle_common) when you install Fusion Middleware component like ADF, SOA, WebCenter or Identity Management. 

Solution:

This class (JRF Startup) is in $MW_HOME\modules\oracle.jrf_11.1.1\jrf.jar

1) Add this path as part of WEBLOGIC CLASSPATH in commEnv.cmd

Class Path for Service is defined in $WLS_HOME\common\bin\commEnv.cmd (Eg: C:\Middleware\wlserver_10.3\common\bin). Add the entry $MW_HOME\modules\oracle.jrf_11.1.1\jrf.jar in WEBLOGIC_CLASSPATH in commEnv.cmd file under "set WEBLOGIC_CLASSPATH=" section


2) Restart the Managed Server.

PolicySet Invalid: WSM-06102 PolicyReference for 12c Enterprise Manager Cloud control

Version: 

OEM 12c Cloud control


Issue:

Standby DB creation is tried from EM using Availability - Add Standby Database.

On the submission of the job, it hangs and then fails on preparation phase.

The error received was 

PolicySet Invalid: WSM-06102 PolicyReference The policy reference URI "oracle/wss_username_token_client_policy" is not valid.


The error can be found from the emoms_pbs.trc files available under <OMS_Instance_Home>/em/<oms_name>/sysman/log directory.


Reason:

The weblogic and nodemanager credentails for the EM was reset recently. But few of the steps as part of password change was not done. 

Because of this even if we were able to  work with EM, the submission of jobs always failed or hung.

Solution:

Followed the Support Doc ID. 1450798.1. Redid all the steps exactly as mentioned in the document.

Reset the passwords back to the existing changed value.  After completion of all the above steps, tried the standby DB creation and it was successful.

Weblogic 10.3.6: java.io.IOException: Unable to backup file "weblogic-domain-binding.jar" during patching

Version:

Weblogic Server 10.3.6 in Windows 2008

Issue:

The bsu command to apply patch errors out

Patch applied was 18040640 (Patch Set Update 10.3.6.0.8).

Error:

Installing Patch ID: T5F1..Result: Failure
java.io.IOException: Unable to backup file C:\Middleware\wlserver_10.3\server\lib\schema\
weblogic-domain-binding.jar to C:\Middleware\wlserver_10.3\server\lib\schema\weblogic-dom
ain-binding.jar19755.bak

Reason: 

Few of the WLS files were already active during patching.

Patch was tried  straight after WLS installation. Nodemanager  was enabled as a service during installation and it was running.  Due to this the patching failed.

Action:

Stopped the nodemanager service from services.msc. Verified that no DLLs and files from the WLS Home is active using processExplorer tool. Reapplied the patch.

ODI-1400 and ODI-1545: Missing odi supervisor credentials in credential store map

Version:

ODI 11.1.1.7.0 64 bit

Issue:

The startManagedWeblogic log has following errors and OracleDIAgent status would be down in Enterprise Manager.

Unable to set the activation state to true for the application 'oraclediagent'.
weblogic.application.ModuleException: [HTTP:101216]Servlet: "AgentServlet" failed to preload on startup in Web application: "oraclediagent".

ODI-1400: Agent OracleDIAgent start failure: JDBC connection error occurs while connecting to the master repository.

Caused by: ODI-1545: Missing odi supervisor credentials in credential store map [oracle.odi.credmap] with key [SUPERVISOR].

Reason:

Security must be set up for the JAVA EE application to have access to the ODI repository. The entry will be created within the credential store, which will allow the JAVA EE Agent to authenticate itself to be able to use the required resources. The user is already set up in the ODI Security, in this case SUPERVISOR.

Action:

Execute Web Logic Scripting Tool (WLST), connect to our running Admin server and add the credential store

Steps:

1. Start WLST and connect

cd $ODI_HOME/common/bin

wlst.sh

wls:/offline> connect('weblogic','welcome1','t3://hostname.domain:7001')

2. Add the correct credential store for ODI Supervisor 

createCred (map="oracle.odi.credmap", key="SUPERVISOR", user="SUPERVISOR", password="SUNOPSIS", desc="ODI SUPERVISOR Credential")

Eg:
wls:/odi11g_domain/serverConfig> createCred(map="oracle.odi.credmap", key="SUPERVISOR", user="SUPERVISOR", password="sunopsis", desc="ODI SUPERVISOR Credential") 
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root. 
For more help, use help(domainRuntime)

3. Add the correct credential store for the  ODI Domain

createCred (map="oracle.odi.credmap", key="ODI Domain Name", user="weblogic", password="welcome1", desc="ODI-DOMAIN Credential")

Eg:
createCred(map="oracle.odi.credmap", key="odi11g_domain", user="weblogic", password="welcome1", desc="ODI-DOMAIN Credential")


4. Restart the Managed Server

./startManagedServer.sh odi_server1

Note:

To delete the credentials you can use deleteCred function from wlst

Eg:

deleteCred(map="oracle.odi.credmap", key="SUPERVISOR")

Oracle 12c PDB: user_dump_dest and trace file location

Version

Oracle DB 12c

USER_DUMP_DEST in PDB

The parameter user_dump_dest is deprecated in 12c. It is replaced by diagnostic_dest parameter from 11g.

Also this parameter cannot be set at PDB level. Even if it is set it doesnt have any impact and will be ignored.

Location of trace files

By default the trace files would get generated under the CDB folders under
diagnostic_dest.

diagnostic_dest                      string      /data/app/oracle

To identify issue the following query from PDB or CDB

SQL>  select value from v$diag_info where name='Diag Trace';

VALUE
--------------------------------------------------------------------------------
/data/app/oracle/diag/rdbms/orcl/orcl/trace

where orcl is my CDB name.


Verify the Path

Connect to the PDB instance and do a sample trace

SQL>  alter session set tracefile_identifier=trace_location;

SQL>  alter session set events '10046 trace name context forever, level 12';

SQL>  show parameter user_dump_dest

SQL>  select value from v$diag_info where name='Diag Trace';

SQL>  select value from v$diag_info where name='Default Trace File';

SQL>  exit

The trace file with the trace_location would be created under the folder /data/app/oracle/diag/rdbms/orcl/orcl/trace

DB Upgrade failure: wallet is not open

Scenario:

A database for which wallet is configured is being upgraded from version 11.2.0.3.0 to 11.2.0.4.0.
DB upgrade is done using DBUA

Issue:

During the initial phase of upgrade process when the DB is stopped and restarted, the upgrade process halts throwing "wallet is not open" message. 

Reason:

When the upgrade process is initiated from the new DB Home it doesn't have details to provide for the wallet file location, without which the database cannot be opened.

Solution:

Copy the sqlnet.ora file from the existing 11.2.0.3.0 Home to 11.2.0.4.0 Home's network/admin folder. Re-initiate the upgrade process

This will make the DB aware of the wallet path and the database can be opened easily

Opatch Error: The patch directory area must be a number.

Situation:

Applying  Oct 2014 SPU to Oracle DB software using opatch utility

DB Version: 11.2.0.4.0


Error:

The patch directory area must be a number.

ERROR: OPatch failed because of problems in patch area.


Solution:

Upgraded opatch to latest version.

After upgrade the patch application went smooth.

It can happen for other reasons also like  if  we try to apply a wrong release patch or instead of "opatch napply" "opatch apply" is  tried etc

The local BEA product registry is corrupted on weblogic silent mode installation

Version:

WLS 12.1.1 installation in Linux 64 bit

Issue:

On invoking the silent mode installation, getting the following mesage:

"The local BEA product registry is corrupted. Please select another Middleware Home or contact Oracle Support"

Command:

java -jar wls1211_generic.jar -mode=silent -silent_xml=./silent.xml -log=wlsinstall.log

Reason:

Check for correct spelling and case in the silent.xml file. If there is any mismatch then you may get this error.

For eg: in my silent.xml file in the COMPONENT_PATHS section I used "WebLogic Server/Configuration Wizard and upgrade Framework" instead of "WebLogic Server/Configuration Wizard and Upgrade Framework".

The only difference was that I used a small case for 'u'pgrade instead of 'U'pgrade.

Also make sure that the entire COMPONENT_PATHS comes in a single line inside the xml file and there is no space between pipe delimiters.

Solution:

Corrected the case in silent.xml. The installation was successful this time.

bash-3.2$ java -jar wls1211_generic.jar -mode=silent -silent_xml=./silent.xml -log=wlsinstall.log
Extracting 0%....................................................................................................100%

Silent.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<bea-installer> 
<input-fields> 
<data-value name="BEAHOME" value="/home/user/Middleware"/> 
<data-value name="WLS_INSTALL_DIR" value="/home/user/Middleware/wlserver_12.1"/> 
<data-value name="OCP_INSTALL_DIR" value="/home/user/Middleware/coherence"/>
<data-value name="COMPONENT_PATHS" value="WebLogic Server/Core Application Server|WebLogic Server/Administration Console|WebLogic Server/Configuration Wizard and Upgrade Framework|WebLogic Server/Web 2.0 HTTP Pub-Sub Server|WebLogic Server/WebLogic SCA|WebLogic Server/WebLogic JDBC Drivers|WebLogic Server/Third Party JDBC Drivers|WebLogic Server/WebLogic Server Clients|WebLogic Server/Xquery Support|Oracle Coherence/Coherence Product Files"/> 
<data-value name="INSTALL_NODE_MANAGER_SERVICE" value="yes"/>
<data-value name="NODEMGR_PORT" value="5559"/>
<data-value name="INSTALL_SHORTCUT_IN_ALL_USERS_FOLDER" value="no"/> 
<data-value name="LOCAL_JVMS" value="/home/user/jdk1.7.0_51"/> 
</input-fields>

</bea-installer> 

Unable to create Patch Object Exception occured : PatchObject constructor: Input file does not exist.

Version: 

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

Issue:

Error found on invoking patch conflict check using opatch for a PSU patch on database Home.

Error:

Invoking prereq "checkconflictagainstohwithdetail"
Prereq "checkConflictAgainstOHWithDetail"not executed 
Unable to create Patch Object.
Exception occured : PatchObject constructor: Input file "/u01/stage/etc/config/actions" or "/u01/stage/etc/config/inventory" does not exist.

OPatch succeeded.

Reason:

Error is due to the location (directory) given for the Patch folder given using -ph.

I used the command, "opatch prereq CheckConflictAgainstOHWithDetail -ph ./". Since I gave -ph . the command should have been executed from the directory where the patch was extracted.

In this case the patch folder after extraction was /u01/stage/18522509. 

But I invoked the patch conflict check from /u01/stage and specified -ph ./ where it will look for patch files in the current directory and resulted in the error.

Fix:

Move to the folder created after extracting the patch zip file and execute the command again from there.

[oracle@DBServer1 stage]$ cd  /u01/stage/18522509

[oracle@DBServer1 18522509]$ opatch prereq CheckConflictAgainstOHWithDetail -ph ./

or specify the full directory to -ph command from current directory

opatch prereq CheckConflictAgainstOHWithDetail -ph /u01/stage/18522509

ORA-20001: Latest xml inventory is not loaded into table

Version:

Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production

Issue:

April 2014 PSU - Patch 18522516 - 12.1.0.1.4 Patch Set Update is applied successfully to the DB Home. On the post patching step, to loadi modified SQL files into the database, datapatch is invoked and it results in the error.

Error:

bash-4.1$ ./datapatch -verbose

SQL Patching tool version 12.1.0.1.0 on Tue Aug  5 01:08:49 2014

Copyright (c) 2014, Oracle.  All rights reserved.

Connecting to database...OK

Determining current state...

Currently installed SQL Patches: 

DBD::Oracle::st execute failed: ORA-20001: Latest xml inventory is not loaded into table

ORA-06512: at "SYS.DBMS_QOPATCH", line 1011

ORA-06512: at line 4 (DBD ERROR: OCIStmtExecute) [for Statement "DECLARE

       x XMLType;

     BEGIN

       x := dbms_qopatch.get_pending_activity;

       ? := x.getStringVal();

     END;" with ParamValues: :p1=undef] at /u01/app/product/12.1.0/dbhome_1/sqlpatch/sqlpatch.pm line 1227.

Description:

An error lookup just shows that latest inventory file is not loaded. It could be due to some kind of permission issues with the QOpatch directory and files under it. Database uses two directories to pint to $ORACLE_HOME/QOPatch location, OPATCH_SCRIPT_DIR and OPATCH_LOG_DIR.

Solution:

Followed the Oracle support Doc (Doc ID 1602089.1) and tried workarounds mentioned there, like recreating OPATCH_SCRIPT_DIR and OPATCH_LOG_DIR from sqlplus. Also edited opatch script file as mentioned in the support doc. But both steps did not work.

1. Check the _disable_directory_link_check parameter value in the DB 

2. If its value is FALSE, set it to TRUE

3. Bounce the DB

4. Rinvoke datapatch command.

1. SQL> SELECT a.ksppinm "Parameter",b.ksppstvl "Session Value",c.ksppstvl "Instance Value" FROM x$ksppi a, x$ksppcv b, x$ksppsv c  WHERE a.indx = b.indx AND a.indx = c.indx AND a.ksppinm LIKE '/_disable_direc%' escape '/';   

Parameter                      Session Value Instance Value

------------------------------ ------------- ---------------

_disable_directory_link_check   FALSE         FALSE

2. SQL> alter system set "_disable_directory_link_check"=TRUE scope=spfile;

System altered.

3. SQL> Shutdown immediate

    SQL> startup;

4. ./datapatch -verbose

.....................

.....................

     Installing patches...

     Patch installation complete.  Total patches installed: 1

     Validating logfiles...

     Patch 18522516 apply: SUCCESS

The OPatch version is not applicable for current OUI version

Version:

Oracle WLS 12.1.2.0

Issue:

Opatch lsinventory returns error when opatch command is issued from 12.1.2.0 version of Weblogic. 

Error:

opatch lsinventory -jdk $JAVA_HOME

OPatch Version : 13.1.0.0.0

OUI  Version : 12.1.0.1.0

The OPatch version is not applicable for current OUI version.

Since OUI Version starts with 12.1, Please go to 'My Oracle Support' and get right OPatch 12.1.*.*.* based on patch 6880880, release version 12.1.0.0.0 and \appropriate platform.

OPatch failed with error code 19

Reason:

The Error was due to the mismatch in opatch version and the inventory version. A DB software of 12C version is also available in same server. In my case  MW_HOME environment variable is set and PATH is set to $MW_HOME/OPatch directory. But the ORACLE_HOME environment variable was still set to the DB Home. Because of that the opatch utility checked the inventory file which it got from the Oracle DB Home oraInst.loc and error out

Solution:

Set ORACLE_HOME to MW_HOME_PATH location and re invoke opatch. 

Still better to close the previous Unix session and open a new one to avoid reference to any variables set previously.

After the correct ORACLE_HOME setting the versions read as follows

OPatch version    : 13.1.0.0.0

OUI version       : 13.1.0.0.0

Note: The error can come also if the opatch version is old compared to the inventory version

ORA-39142: incompatible version number 4.1 in dump file with IMPDP

Scenario:

Import to a database using IMPDP is erroring out

Versions:

Source DB 12.1.0.1.0
Target DB 11.2.0.4.0

Error:

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-39001: invalid argument value
ORA-39000: bad dump file specification
ORA-39142: incompatible version number 4.1 in dump file "/u01/stage/schema_dump.dmp"

Reason:

As the error message rightly points out it is due to the incompatibility of EXPDP/IMPDP versions used.
Here the export was done using 12.1.0.1.0 EXPDP utility and dump created was tried to be imported using 11.2.0.4.0 IMPDP utility, resulting in the error.

Solution:

Use the "VERSION" option available with datapump.

The export data pump has the "VERSION" option which allows to create the dump file which is compatible with the previous releases.

Here is the syntax and description of VERSION from Oracle’s document.

VERSION={COMPATIBLE | LATEST | version_string}

The legal values for the VERSION parameter are as follows:

COMPATIBLE – This is the default value. The version of the metadata corresponds to the database compatibility level. 
Database compatibility must be set to 9.2 or higher.
LATEST – The version of the metadata corresponds to the database release.
version_string – A specific database release (for example, 11.2.0). In Oracle Database 11g, this value cannot be lower than 9.2.

Eg:

expdp system directory=EXPDP_DIR dumpfile=schema.dmp log=schema_expdp.log SCHEMAS=scott version=11.2.0.0.0

ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr] in Oracle 12C

Version:

DB: 12.1.0.1.0
OS: OEL 6, 64 bit

Issue:

The file system on which DB files were available crashed, resulting in a DB crash. The next DB startup is failing with Internal errors. DB is coming up to the mount stage only.

Error:

Database mounted.
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1],
[1895], [12597], [12603], [], [], [], [], [], [], []

Reason:

Because of the file system crash when DB was running,the data files became in accessible. This resulted in a "lost Write" into the Online RedoLogs. So the normal Instance Recovery procedure became impossible to happen causing the ORA-600 error.

Solution:

We can manually recover the DB by specifying the online redo thread at the time of crash if the full set of redo logs are available in the storage. 

Note: It is better to have a full backup of all the files before trying the steps.

1. Backup all DB files if possible

2. Identify the current log sequence group and file.

SQL> startup mount;

SQL> select GROUP#,STATUS from v$log;

    GROUP# STATUS

---------- ----------------

         1 INACTIVE

         3 INACTIVE

         2 CURRENT

SQL> select GROUP#,MEMBER from v$logfile;

    GROUP# MEMBER

---------  -----------------------

1   /u01/oradata/orcl/redo01.log  

2   /u01/oradata/orcl/redo02.log

3   /u01/oradata/orcl/redo03.log

Here Group# 2 is current. So I am going to pass it manually

3. Manually Recover the DB

SQL> recover database until cancel using backup controlfile;

ORA-00279: change 23977161 generated at 07/18/2014 07:00:59 needed for thread 1

ORA-00289: suggestion :

/u01/app/oracle/product/121010/dbs/arch1_1895_847740493.dbf

ORA-00280: change 23977161 for thread 1 is in sequence #1895

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

/u01/oradata/orcl/redo02.log

Log applied.

Media recovery complete.

SQL> alter database open resetlogs;

Database altered.

DB is now open.

Note: If the above step fails then the only option left is to restore/recover from latest backup.

ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT

Version:

DB: 12.1.0.1.0 EE

Issue:

Errors are obtained while running migration script in a 12C DB and the sessions are getting killed.

ORA-00028: your session has been killed
ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT
PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT of 2048 MB

Reason:


From Oracle 12C, a new parameter called PGA_AGGREGATE_LIMIT sets a hard limit on the amount of PGA taken up by an instance.

The parameter pga_aggregate_limit, if not explicitly defined, defaults to the greater of these three numbers:
a) 2 GB
b) 3 MB times the value of the processes parameter
c) 2 times the value of the parameter pga_aggregate_target

SQL> show parameter pga_ag

NAME                                            TYPE                        VALUE
------------------------------------ -----------       ------------------------------
pga_aggregate_limit                       big integer                       2G
pga_aggregate_target                     big integer                       764M

When the overall PGA occupied by all the sessions in that instance exceed the limit, Oracle kills the session holding the most untunable PGA memory, releasing all PGA memory held by that session.

The error can be noticed in the alert log file and the incident would be reported in a trace file, where the current offending SQL can be found.

ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT
Incident details in: /u01/app/diag/rdbms/orcl/orcl/incident/incdir_24367/orcl_ora_13239_i24367.trc

In trace file

----- Current SQL Statement for this session (sql_id=2fsstt9a4tqz7) -----


Solution:

One way is to go back to the previous (pre-12c) behavior. To do that set the value of pga_aggregate_limit to 0 and the parameter will not have any impact.

alter system set pga_aggregate_limit=0 scope=both;

Obviously another option is to set this value to a much higher value if you have enough physical memory in the server

alter system set pga_aggregate_limit=3072M scope=both;

Could not connect to asm due to following error ora-01031: insufficient privilege on RAC DB creation

Version: 

11.2.0.3.0 in RHEL 6

Scenario: 

A RAC DB creation on two nodes using DBCA.
Chose ASM as storage type in the Storage Type details screen of DBCA. But the disk groups those were created already were not visible.

Tried giving +DATA manually and clicked Next, and ended up getting the following error.


"Could not connect to asm due to following error ora-01031: insufficient privilege"

Verified from ASMCMD > lsdg command that all the disk groups were mounted.

Reason:

This was clearly a case of missing privilege as indicated by the error

Grid software owner was "grid" and DB S/W owner was "oracle". I missed to add "asmdba" as a secondary group to oracle user. 

[root@node1 app]# id oracle
uid=1901(oracle) gid=54321(oinstall) groups=8500(dba),8501(oper),54321(oinstall)


Solution:

Added asmdba as a secondary group to oracle. 

/usr/sbin/usermod -g oinstall -G dba,oper,asmdba oracle

[root@node1 app]# id oracle
uid=1901(oracle) gid=54321(oinstall) groups=8500(dba),8501(oper),9601(asmdba),54321(oinstall)

Took a new terminal session as "oracle" and re initiated DBCA.

This time the disk groups were displayed and chosen by default.

Oracle database 12 C Listener configuration for PDBs

Version:

Oracle DB 12C

Topic:

Configure listener for database involving PDBs

Steps:

1. Add new listener details to listener.ora file. 

Note: Make sure to add only the CDB instance in the file. That means no entries should be there in listener.ora for any of the PDBs.

I have created the file using netmgr here in the example

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = myhost.mydomain)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = /u01/app/oracle/product/121010)
      (PROGRAM = extproc)
    )
    (SID_DESC =
     (GLOBAL_DBNAME = orcl.mydomain)
      (ORACLE_HOME = /u01/app/oracle/product/121010)
      (SID_NAME = orcl)
    )
  )

My lsitener name is "LISTENER" and CDB name is orcl

2. Set "LOCAL_LISTENER" parameter in CDB. 

You can either set it to the listener name or pass the hostname:port number of listener as show below

SQL> alter system set local_listener='myhost.mydomain:1521';

System altered.

3. Register the PDB instances with listener.

SQL> alter system register;

System altered.

That is it. The CDB and all PDBs would get registered with the listener now. Confirm with lsnrctl status or services commands.

lsnrctl status LISTENER
..........
....
Service "orcl.mydomain" has 1 instance(s).
Instance "orcl", status READY, has 1 handler(s) for this service...
Service "pdb1.mydomain" has 1 instance(s).
Instance "pdb1", status READY, has 1 handler(s) for this service...

DRG-11422: linguistic initialization failed in Oracle 12C Database

Version:

Oracle 12C Release 1 (12.1.0.1.0) 64 bit EE

OS: Solaris 11 on Sparc 64 Bit


Issue:

Getting linguistics errors on trying to rebuild indexes


Error Stack:


SQL> alter index DICT_CI1_IDX1 rebuild; 
alter index DICT_CI1_IDX1 rebuild 
* 
ERROR at line 1: 
ORA-29874: warning in the execution of ODCIINDEXALTER routine 
ORA-29960: line 1, 
DRG-10595: ALTER INDEX DICT_CI1_IDX1 failed 
DRG-11422: linguistic initialization failed 
DRG-11446: supplied knowledge base file 
/u01/app/oracle/product/121010/ctx/data/enlx/droldUS.dat not installed 
. 
. 

Reason:

The Indexes in question uses Oracle Text option which require context knowledge bases. These contexts are not part of the typical Oracle software. It is only available with Examples (previously companion) CD.


Solution:

One method is to download and install the examples cd to the Oracle Home. In this case, we would have to install all the additional components available in examples. 

Another approach is to manually extract and copy the missing files from example CD to ORACLE_HOME. 
I have followed the second option here to install the CTX Knowledge Base.

1. Download the Oracle Examples CD for the Operating system we use. Solaris on Sparc in this case.

Download from OTN: http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html

Eg: solaris.sparc64_12cR1_examples.zip

2. Unzip the file

unzip solaris.sparc64_12cR1_examples.zip

3. Move to CTX File groups folder in the unzipped location. In 12c the path is as follows

cd /u01/app/oracle/software/examples/stage/Components/oracle.ctx.companion/12.1.0.1.0/1/DataFiles


4. Extarct the content of filegroup1.jar file to get the knowledge base files in English. 

Note: filegroup1.jar for the english files (enlx) and filegroup2.jar for the french (frlx) and so on

unzip filegroup1.jar


This will create the ctx folder and its subdirectories

5. Move to ctx/data/enlx from the same location

ie, /u01/app/oracle/software/examples/stage/Components/oracle.ctx.companion/12.1.0.1.0/1/DataFiles/ctx/data/enlx

We will have all the missing files here

-rw-r--r--   1 oracle   dba      2585766 Aug 29  1999 drolkUS.dat
-rw-r--r--   1 oracle   dba      3263531 Aug 29  1999 droliUS.dat
-rw-r--r--   1 oracle   dba      37766593 Aug 29  1999 droldUS.dat
-rw-r--r--   1 oracle   dba      2652662 Aug 29  1999 drofiUS.dat
-rw-r--r--   1 oracle   dba      3497330 Aug 29  1999 drofdUS.dat
-rw-r--r--   1 oracle   dba           12 Feb 29  2000 drolsUS.dat


6. Copy all the files to $ORACLE_HOME/ctx/data/enlx location

Currently it has only two files as shown below

bash-4.1$ ls $ORACLE_HOME/ctx/data/enlx
dren.ds  dren.is


bash-4.1$ cp -r *.dat  $ORACLE_HOME/ctx/data/enlx/

7. Confirm that the files are available under $ORACLE_HOME 

bash-4.1$ ls $ORACLE_HOME/ctx/data/enlx
dren.ds      drofdUS.dat  droldUS.dat  drolkUS.dat
dren.is      drofiUS.dat  droliUS.dat  drolsUS.dat

8. Can continue with index rebuild/creation now.

ORA-32000: write to SPFILE requested but SPFILE is not modifiable

DB Version:

11.2.0.3.0 64 Bit - Single instance/local storage

Issue:

DB was started using spfile. When I tried to modify certain parameters with scope=both/spfile clause, the following error message was received.

ERROR at line 1:
ORA-32000: write to SPFILE requested but SPFILE is not modifiable

The description of the error message gave me following information
Cause: An ALTER SYSTEM command or an internal self-tuning mechanism requested a write to the SPFILE but the SPFILE was not modifiable.
Action :Perform an in-memory parameter update only

I wanted to make the update happen in spfile and want the change to be persistent on next bounce. So planned to create pfile from spfile and add the required entries to the text file.

Steps:

SQL> create pfile from spfile;

File created.

I viewed the contents of the pfile which was just been created. It had only one line.

*.spfile=/u01/app/oracle/product/11.2.0.3.0/database/spfiledev1.ora

So I created pfile again by giving the full path as specified above

SQL> create pfile from spfile='/u01/app/oracle/product/11.2.0.3.0/database/spfiledev1.ora';

File created.


This time the file had all the entries as required by me. I updated the pfile with additional parameters required.

SQL> startup nomount pfile='/u01/app/oracle/product/112030/dbs/initdev1.ora';

Verified that the modified parameters are available. Then created spfile again

SQL> create spfile from pfile;

File created.

SQL> shutdown immediate

SQL> startup

The final startup was with spfile and all the changes I made was available after this.

OPATCH apply fails with the error: OUI-67124:Archive not applied and Failed file pair information (archive)

DB and O/S Version:

11.2.0.3.0 on Linux 64 bit


Scenario:

Applying April 14 PSU (18031683)


Error:

Received the following error stack on applying one of the patches bundled with the PSU

The following actions have failed:
OUI-67124:Archive not applied /stage/software/18031683/17540582/files/lib/libserver11.a/kcb.o to $ORACLE_HOME/lib/libserver11.a... ''
Do you want to proceed? [y|n]
Finish saving patch to inventory at Thu May 15 07:24:18 EDT 2014
Verifying the update...
Inventory check OK: Patch ID 17540582 is registered in Oracle Home inventory with proper meta-data.
erifying 21 copy files.
verifying 112 archive files.
Failed file pair information (archive)::
Source file name is : /stage/software/18031683/17540582/files/lib/libserver11.a/kcb.o,  size is : 1118552
Destination file name (extracted from Oracle Home) is : $ORACLE_HOME/.patch_storage/verify/archive/lib/libserver11.a/kcb.o,  size is : 1114480
Failed file pair information (archive)::
Source file name is : /stage/software/18031683/17540582/files/lib/libserver11.a/kcbb.o,  size is : 395968
Destination file name (extracted from Oracle Home) is : $ORACLE_HOME/.patch_storage/verify/archive/lib/libserver11.a/kcbb.o,  size is : 396400
.......
.......
verifying 5 plugin actions.
There are 82 archive files under ORACLE_HOME that are not patched.
OUI-67124:Files check failed: Some files under ORACLE_HOME are not patched. Please see log file for details.
OUI-67124:ApplySession failed in system modification phase... 'Verification of patch failed: Files are not updated completely.'

Reason:

The failure was due to insufficient storage space in the ORACLE_HOME mount point where the patch was also staged.

Solution:

Make sure we have sufficient free space available in the storage location where Oracle Home is installed.

Clear old trace/log files or old staging software and reclaim enough space.

Re run the patch

BEA-141223 : The server name specified with -Dweblogic.Name does not exist.

Issue:

While trying to startup the AdminServer using startWeblogic.sh script, the following error is received.

<BEA-141223> <The server name base_domainAdminServer specified with -Dweblogic.Name does not exist. The configuration includes the following servers {AdminServer,odi_server1}.> 

Analysis:

Due to some reason the AdminServer Name which normally should be addressed as "AdminServer" is passed as "base_domainAdminServer" to the startup script.
The base_domain is the name of the domain configured.

Solution:

Based on Support Doc ID.1338461.1, it could be because of an environment variable set some where which resulted in passing a wrong Server Name. 
So if such an env variable is set, and if the user defined environment variable is created with an incorrect server name,it will fail with this error at startup.
But in our case, such an env variable was not defined any where as verified by the command echo $SERVER_NAME.

As a work around I tried setting the SERVER_NAME variable to AdminServer and able to start the server after that using startWeblogic.sh

export SERVER_NAME=AdminServer
./startWeblogic.sh

OPW-00001: Unable to open password-file

Issue:

The connection to DB as "/" and "sys" as sysdba was failing with password not matching error.
When tried to reset the password using orapwd received the following error

"OPW-00001: Unable to open password-file"

Version:

DB 11.2.0.2.0
Platform: Windows 

Reason:

The reason behind "OPW-00001" is normally syntax error. We have to specify the command in the proper format.

It should be in the following syntax in windows servers

orapwd file=%ORACLE_HOME%\database\PWD%ORACLE_SID%.ora password=<PWD>

In my case I missed to specify ".ora" as part of the file name. 

ie, initially I tried with orapwd file=%ORACLE_HOME%\database\PWDorcl

Later I added .ora to file name and corrected it as

orapwd file=%ORACLE_HOME%\database\PWDorcl.ora