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.

ORA-04031 during IMPDP 11g

Scenario:

Received the following error while trying to import data using datapump.

ORA-39097: Data Pump job encountered unexpected error -4031
ORA-39065: unexpected master process exception in MAIN
ORA-04031: unable to allocate 2024 bytes of shared memory ("streams pool","unknown object","streams pool","kodpaih3 image")
Job "SYS"."SYS_IMPORT_FULL_01" stopped due to fatal error at 11:19:39

Version:

Oracle EE 11.2.0.2.0

Reason:

The ORA-4031 error message in the above error stack, indicates a problem with the Streams pool. The database, where the operation failed, was set to follow AMM and individually  STREAMS_POOL_SIZE instance parameter was set to 0. Data Pump operations utilize the Oracle Streams pool and the size of the stream role in ideal case should be increased automatically on demand. In this case that has not happened and resulted in the above error.

Solution:

Set STREAMS_POOL_SIZE>0 to guarantee a minimum size for the streams pool when using DB  that is set to use AMM (or even ASSM).

alter system set streams_pool_size=150m;

Restarted the IMPDP operation. This time the ORA-4031 errors were missing.

 

How to change the weblogic Admin server port number

Task:

To change the port number of weblogic Admin server. The port number was set to the default value of 7001.

Version:

Weblogic 12.1.2.0.0

Action:

The easiest method is to simply update the port number in the weblogic conole page and save the change. 

Connect to weblogic conole using the current port number

Eg: http:<hostname>:7001/console

Navigate to Servers => Click on the AdminServer(admin)
We would be at the configuration tab of AdminServer now. Just update the value in the Listen Port: column to new value. For eg: 7010 and then click Save button, available at the bottom of that page. That would make the trick.

We can immediately verify the change by accessing the URL through the new port number. But the page would be accessible through both new and old port numbers until we restart the AdminServer. So better to restart the AdminServer so that the console URL is accessible only through the modified port number.

Alternative Approach:

Add the port number in the config.xml file.

Stop the weblogic services. Take a backup of config.xml file. If we are using the default port number of 7001, then its entry would not be there in the file. So we have to add the tags to reflect the new port number.

Add following two lines to the config.xml under <Server> <name>AdminServer</name> tag

<listen-port>7010</listen-port>
<listen-port-enabled>true</listen-port-enabled>

Restart the AdminServer. Now it would be running in new port

Command to find weblogic version

Command:

weblogic.version

Usage:

   1. Source the environment variables

       . $WL_HOME/server/bin/setWLSEnv.sh

   2. Issue weblogic.version command

       java weblogic.version

Output:

WebLogic Server 10.3.6.0.5 PSU Patch for BUG16619891 Tue Apr 23 13:24:29 IST 2013
WebLogic Server 10.3.6.0  Tue Nov 15 08:52:36 PST 2011 1441050 

Use 'weblogic.version -verbose' to get subsystem information

Use 'weblogic.utils.Versions' to get version information for all modules


You can use "java weblogic.version -verbose" and "java weblogic.utils.Versions" to get more granule level details.
In the above example the weblogic version is 10.3.6.0.5 with Jul 2013 PSU applied.

Change GLOBAL_NAME in oracle database

Scenario:


Wanted to change the global_name of a database, which was having SID + Domain name. 

Version: 12.1.0.1.0 (Applicable to all versions)

SQL> select * from global_name;

GLOBAL_NAME
--------------------------------------------------------------------------------
ORCL.MYDOMAIN.COM

Official documents mentioned to use "ALTER DATABASE RENAME GLOBAL_NAME TO <NEW_NAME>;" which did not work in my case.

Solution:

Since global_name is a table, from where we query for the global_name, we can update it to make changes.

SQL> desc global_name
 Name                                          Null?    Type
 ----------------------------------------- -------- ----------------------------
 GLOBAL_NAME                                        VARCHAR2(4000)

SQL> update global_name set global_name='ORCL';

1 row updated.

SQL> commit;

Commit complete.

SQL> select * from global_name;

GLOBAL_NAME
--------------------------------------------------------------------------------
ORCL

Linux-x86_64 Error: 12: Cannot allocate memory on RAC conversion using rconfig in NFS mount

Scenario:

A stand alone database is getting converted to RAC/ASM using rconfig command, which internally uses RMAN for the conversion.
DB Version: 11.2.0.3.0

The DB conversion was failing every time on the redo logs addition phase of the conversion.
The source database was in an NFS shared storage. And the conversion was to an Exadata box.

Error:

ORA-00321: log 1 of thread 1, cannot update log file header
ORA-00312: online log 1 thread 1: '/redo_log_path/log3.dbf'
ORA-27072: File I/O error
Linux-x86_64 Error: 12: Cannot allocate memory


Verification:

Since there was not much beyond the above mentioned error in any of the log files, it was difficult to fix the issue. The DB folder had to be physically removed from the ASM instance each time rconfig was run, on the basis of a trial and error approach. This is because the DB instance creation was succesfull every time when rconfig is run.

Luckily we got hold of a support doc which had resemblance with the issue we had.

The Doc ID: 1532488.1 was about failure of RMAN and EXPDP in NFS mount, when Exadata11.2.3.2.1 image is used.

Solution:

Applied patch 16432033 on all compute nodes.
Restarted the RAC conversion after restoring DB from a backup

The patch helped in fixing the error and RAC/ASM conversion was successful.

Note: The patch is not persistent across reboots.  If the system is rebooted, the customer needs to reapply the patch each time