Command to find Oracle ADF/Jdeveloper version

Question:

How to find out the version of ADF or JDeveloper installed particularly after an upgrade of ADF/ADR

Weblogic version: 11g

Solution:

Navigate to MW_HOME/oracle_common/modules/oracle.adf.model_11.1.1  location

Use the command as follows from the shell/cmd

java -cp adfm.jar oracle.jbo.common.PrintVersion

We would get an output similar to the one below

BC4J Version is:  11.1.2.64.36

Another method:

1. Navigate to ADF Home folder (cd $MW_HOME/oracle_common) and search for adf-share-support.jar file.
  
   Eg: find . -name adf-share-support.jar 
       ./modules/oracle.adf.share_11.1.1/adf-share-support.jar

2. Move to the file's folder and copy the file to the user's Home folder.

   Eg: cp adf-share-support.jar $HOME/

3. Extract the contents of the jar file
   
   Eg: cd $HOME
        jar -xf adf-share-support.jar

   The above command extracts the jar file to a folder named META-INF


4. Move to META-IN and read the file MANIFEST.MF
   
   cat MANIFEST.MF

   Look for Oracle version and label in the file we opened
   Oracle-Version: 11.1.2.4.39.64.36.1

   Oracle-Label: JDEVADF_11.1.2.4.0_GENERIC_130421.1600.6436.1

ORA-28007: the password cannot be reused

Scenario:

Trying to reset to the existing password throws following error.

ERROR at line 1:
ORA-28007: the password cannot be reused

Solution:

Check the user profile set for the user. Check for the existence of a password verify function in the profile.

Set the password_verify_function to NULL

Another reason could be that the PASSWORD_REUSE_MAX limit has reached. If so set to a higher value or to UNLIMITED and reset the password as shown below.

SQL> alter profile default limit PASSWORD_REUSE_MAX unlimited;

SQL> alter user USERNAME identified by <PREV_PWD>;

Step by step: Set up Transparent Data Encryption(TDE) in Oracle RAC database

Requirement:

To set up TDE for an eight node RAC database. DB version 11.2.0.2.0. Below given are the steps I used. 

Steps:


1. Create directory structure for wallet (Steps done as root user)

Oracle recommends placing the Oracle Wallet outside of the $ORACLE_BASE directory tree to avoid accidentally storing the wallet with the encrypted data on a backup tape. So we are going to store the wallet files under /etc as shown below. In my case database name is ORCL.

a. [root@node01 etc]# mkdir -pv ORACLE/WALLETS/ORCL

b. [root@node01 etc]# chown -R oracle:oinstall ORACLE

c. [root@node01 etc]# chmod -R 700 ORACLE


2. Configure sqlnet.ora file in first node (Step done as oracle user).

Edit sqlnet.ora and add following entry.


ENCRYPTION_WALLET_LOCATION =
  (SOURCE = (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY=/etc/ORACLE/WALLETS/ORCL)))


3. Create the wallet. 

The following SQL command will initialize the wallet and add master encryption key. This creates a file by name ewallet.p12 under Wallet directory

SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "<WalletPwd>";

System altered.


[oracle@node01 ORCL]$ pwd
/etc/ORACLE/WALLETS/ORCL
[oracle@node01 ORCL]$ ls -ltr
total 4
-rw-r--r-- 1 oracle dba 1573 Oct 10 22:34 ewallet.p12

The wallet would be already open. Else you can use the SQL command to open it.

ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "<WalletPwd>";


4. Reduce permission on wallet file to 600

[oracle@node01 ORCL]$ chmod 600 ewallet.p12
[oracle@node01 ORCL]$ ls -ltr
total 4
-rw------- 1 oracle dba 1573 Oct 10 22:34 ewallet.p12



5. Enable Autologin. This will create cwallet.sso file in Wallet directory

orapki wallet create -wallet /etc/ORACLE/WALLETS/ORCL -auto_login


6. Make Wallet Immutable: So that even root cant delete it. Execute this as root user

Set the immutable but with chattr +i command as show below.

[root@node01 ORCL]$ ls -ltr
total 8
-rw------- 1 oracle dba      1573 Oct 10 22:34 ewallet.p12
-rw------- 1 oracle oinstall 1651 Oct 10 22:39 cwallet.sso

[root@node01 ORCL]$ chattr +i ewallet.p12
[root@node01 ORCL]$ chattr +i cwallet.sso


7. Copy Wallet and sqlnet.ora to all the nodes of the RAC maintaining same directory structure and permissions.

Once TDE is enabled on the first instance, the wallet and the local sqlnet.ora file need to be copied to all other instances and manually opened for the master key to be loaded into each instance’s memory. Use a tool like "scp" to copy wallet files and sqlnet.ora to all nodes



8. Open wallet in all nodes

Wallet should be manually opened in all nodes so that master key gets loaded in to each of the instances' memory.  

SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "<WalletPwd>";

System altered.

The TDE is now configured and ready to use.

Note:


Wallets must be reopened after an instance restart and can be closed again to prevent access to encrypted columns.

ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "<WalletPwd>";
ALTER SYSTEM SET ENCRYPTION WALLET CLOSE;

To reverse immutability use -i option


chattr -i ewallet.p12
chattr -i cwallet.sso

SOA Cluster Coherence Error: Detected another cluster senior, running on an incompatible protocol

Issue:

Platform: OEL 5
SOA Version: 11.1.1.5.0 for AIA

Had set up SOA cluster with two managed servers running on same server and managed as part of a cluster.

On starting up the second managed server, it always fail throwing following error stack.


<Oct 10, 2013 7:54:48 PM GMT> <Error> <Coherence> <BEA-000000> <2013-10-10 19:54:48.830/1032.427 Oracle Coherence GE 3.7.1.1 <Error> (thread=Cluster, member=2): Detected another cluster senior, running on an incompatible protocol at null manual intervention may be required>

Reason:

By default the coherence.clusterport is set to 9778 and it seems to have an issue with this version. Change it to any other valid/available port number and restart the service.

Solution:

Move to $DOMAIN_HOME/bin directory

Take a backup of setDomainEnv.sh file.

Open setDomainEnv.sh and search for clusterport and come to the following line

EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Dsoa.archives.dir=${SOA_ORACLE_HOME}/soa -Dsoa.oracle.home=${SOA_ORACLE_HOME} -Dsoa.instance.home=${DOMAIN_HOME} -Dtangosol.coherence.clusteraddress=227.7.7.9 -Dtangosol.coherence.clusterport=9777 -Dtangosol.coherence.log=jdk -Djavax.xml.soap.MessageFactory=oracle.j2ee.ws.saaj.soap.MessageFactoryImpl -Dweblogic.transaction.blocking.commit=true -Dweblogic.transaction.blocking.rollback=true -Djavax.net.ssl.trustStore=${WL_HOME}/server/lib/DemoTrust.jks"

Change the port number as shown above. By default it would be 9778. Change it to any other valid port number. In above example I changed it to 9777.

Restart the SOA services.

AS10g Forms: The patch directory doesn't match the patch id

Scenario:

Applying a Forms Patch 17459191
Version: 10.1.2.3.0
Platform: Windows 32 Bit

During Patch Application the opatch errored out

Error:

The patch directory 17459191 doesn't match the patch id. 
ERROR: OPatch failed during pre-reqs check. 
OPatch returns with error code = 150 


Reason:

Opatch error code = 150 is generic. When ever the patching operation has not met all the pre-requisites then this error is thrown.

In this case two pre-requisites were mentioned under NOTES heading in the readme.txt

Solution:

Go through the readme.txt carefully and complete all the steps mentioned as pre reqs.

In my case, two pre reqs were there

1. Another patch which was of older version had to be applied - Patch 9593176 
2. OUI to be upgraded after 9593176 patch. 
If OUI is not upgraded, then another error OPATCH_JAVA_ERROR=CHECKCONFLICT: OPATCH CANNOT PROCESS OVERLAY PATCHES BECAUSE OF NO OUI SUPPORT. PLEASE    TAKE LATEST OUI 10.1 PATCHSET FROM "MY ORACLE SUPPORT" AND TRY AGAIN. 
Follow Support Doc 1301320.1 for the proper upgrade.

Once both conditions were satisfied, I was able to apply the patch.

OBIEE startup error: Your Java heap size might be set too high.

Scenario:

Trying to startup OBIEE 11.1.1.5.0 in a Windows 2007 server which had low physical memory allocated.

Error:

Could find the following error message in the startup prompt

Caused By: com.bea.xml.XmlException: class allocation, 106505772 loaded, 102M footprint in check_alloc (src/jvm/model/classload/classalloc.c:213) 21547 bytes requested.
Java heap 1024M reserved, 512M committed
Paged memory=1455520K/2147352575.
Your Java heap size might be set too high.

Reason:

The server's physical memory was exhausted as other applications were also running. 

Reduced the heap size memory values in setOBIDomainEnv.cmd file. But that too did not help.

Solution:

Increased the Virtual Memory of the machine. Set it to higher range in D: Drive manually

Restarted the OBIEE service.

OBIEE 11.1.1.5.0: Could not create the Java virtual machine in Windows 2007

Scenario:

Starting up of OBIEE 11.1.1.5.0.
Server: Windows 2007 32 Bit

Received following error on startup

[ERROR][memory ] Could not commit 1048576KB heap memory at 0x10040000.
Could not create the Java virtual machine.

This means the system was unable to allocate 1024MB of memory for the JVM. 

Solution:

The windows server had 4GB physical memory and about 90% of that was used by other processes. So the system was unable to allocate the guranteed memory for JVM

I reduced the current heap memory settings in the env file. So the heap settings was reduced to 512-1024M in setDomainEnv.cmd file.

Restarted the services and this brought up weblogic.

Discgroup is not compatible for database usage while using 11g dbca with Custom Database template.

Scenario:

DB creation using DBCA in exadata machine. An 8 node RAC DB is being created.

DB Version: 11.2.0.3.0

Error:

Discgroup "+DATA_SLCC24" is not compatible for
database usage. Database compatible attribute of
diskgroup should be the same or lower than the database
compatible initialization parameter value.
Database compatible parameter is set to "11.2.0.0.0"
and the diskgroup database compatibility attribute is set
 to "11.2.0.2". 

Reason: 


The error denotes that the compatible parameter set in the database initialization parameter is lower than the compatible.rdbms set for the diskgroup in ASM. In this case the database compatible parameter was set to 11.2.0.0.0 and the diskgroup compatible.rdbms is set to 11.2.0.2.0.

We can verify the ASM compatible settings by issuing following query after connecting to the ASM instance.

select group_number, name, compatibility, database_compatibility from v$asm_diskgroup;

ASM instances with a compatible value set to equal or greater than compatible.asm can mount the diskgroup. So in this case we have to change the setting in DB level.

DBCA uses in built templates to create the DB. The templates are by default stored in $ORACLE_HOME/assistants/dbca/templates folder.

We need to find out and edit the attribute in the right template and reinvoke dbca.

Solution:

Move to $ORACLE_HOME/assistants/dbca/templates location. Find the template that is used by you. I have used "Custom Database" template. The template file for "Custom Database" option is New_Database.dbt. So take  a backup of that template for safety and open the "New_Database.dbt" file using "vi" editor.

Search for the string compatible. Change its value to be equal to (or greater than) the corresponding ASM value. For example as shown below


   <initParam name="compatible" value="11.2.0.0.0"/>    => This was my original setting

I changed it to 11.2.0.2.0 and saved the file and quit


Exit from the dbca session if you have not already, and restart dbca. It should go through now.