Showing posts with label ORACLE WEBLOGIC SERVER. Show all posts
Showing posts with label ORACLE WEBLOGIC SERVER. Show all posts

How to Create Credential Mappings for a WebLogic Server Datasource Using WLST

This article describes how to create Credential Mappings for an existing WebLogic Server Datasource using WLST.


You can use a WLST Python script to create Credential Mappings for an existing WebLogic Server Datasource. Create the filename with a .py extention with the following content: for example, In the script make modifications according to your environment and requirement specifying the DataSource Name (), Domain Name (), remoteUsername (), remotePassword
(<remotePassword>) and WLST domain connect parameters specifying domain username, password and listen address.

resourceId = 'type=<jdbc>, application=, module=, resourceType=ConnectionPool, resource=<DataSource Name>, action=reserve'
wlsUsername = '<wlsUsername>'
remoteUsername = '<remoteUsername>'
remotePassword = '<remotePassword>'
domainName = ''
rlm = cmo.getSecurityConfiguration().getDefaultRealm()
credMapProv = rlm.lookupCredentialMapper("DefaultCredentialMapper")
credMapProv.setUserPasswordCredential(resourceId, remoteUsername, remotePassword)
credMapProv.setUserPasswordCredentialMapping(resourceId, wlsUsername, remoteUsername)
Set the WebLogic Server environment variables by running setDomainEnv.cmd/sh script inside the ${DOMAIN_HOME}/bin folder and run the WLST python script as below. In this example. we assume the python script name
java weblogic.WLST
Once the python script is executed in WLST, log in to the WLS console, navigate to Datasource -> Security -> Credential Mappings. You can see the specified WLS User and Remote User credentials created.

Which Weblogic Version Should be Used With Oracle Rapid Planning ?

When installing Weblogic Server (WLS) in order to deploy Oracle Rapid Planning, which version of Weblogic should be used along with Application Developer Framework (ADF)?


The table below indicates which weblogic version and ADF runtime is required for each VCP patch level.
Rapid Planning VersionWeblogic VersionADF Runtime patchset and below10.3.2PS1 ( until ( ( ( ( ( (
12.2.310.3.6PS5 (


Admin Server Fails To Start /w SecurityInitializationException: The loading of OPSS java security policy provider failed due to exception Caused By: java.lang.NoSuchMethodError: javax/xml/transform/TransformerFactory.newInstance

The AdminServer.log shows:
#### <> <> <> The loading of OPSS java security policy provider failed due to exception, see the exception stack trace or the server log file for root cause. If still see no obvious cause, enable the debug flag to get more information. Error message: javax/xml/transform/TransformerFactory.newInstance(Ljava/lang/String;Ljava/lang/ClassLoader;)Ljavax/xml/transform/TransformerFactory;
Caused By: java.lang.NoSuchMethodError: javax/xml/transform/TransformerFactory.newInstance(Ljava/lang/String;Ljava/lang/ClassLoader;)Ljavax/xml/transform/TransformerFactory;

Error While Upgrading Weblogic Domain Version 12.1.1 To 12.1.2 with error UPGWLS-03503

The reconfigure script to upgrade a WebLogic Server domain from version 12.1.1 to version 12.1.2 exits with an error. The issue seems to be with a custom Identity Asserter, in this case "Oracle Access Manager Identity Asserter." The error message is:
2014-02-11 09:12:44,752 INFO [AWT-EventQueue-0] - Initializing help implementation....
2014-02-11 09:12:45,605 INFO [AWT-EventQueue-0] - need to initialize domainRegistrydocument object
2014-02-11 09:13:35,547 WARNING [44] weblogic.upgrade.Upgrade - /web/oracle/Middleware/oracle_common/common/lib/:10:7: error: failed to load java type corresponding to t=oam-identity-asserterType@
2014-02-11 09:13:35,550 SEVERE [Thread-4] - Reconfiguration failed
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(
  at java.lang.reflect.Method.invoke(
Caused by: weblogic.upgrade.UpgradeException: UPGWLS-03503: The domain configuration file {0} is not valid.
  at weblogic.upgrade.Upgrade.parseConfig(
  at weblogic.upgrade.Upgrade.upgradeDomain(
  ... 7 more
2014-02-11 09:13:35,551 SEVERE [Thread-4] - Reconfiguration Failed!


Problem Installing Oracle Commerce 11.1 On Weblogic 12.1.3

Problem Installing Oracle Commerce 11.1 On Weblogic 12.1.3

Commerce 11.1 was not installing via CIM with Weblogic 12.1.3 even though it is supported.


CIM fails as it is expecting Weblogic 12.1.2 as the OOTB Weblogic Application Server version.


You need to make a change as detailed below to the following file to allow CIM to progress with installation and configuration:

for example:



The properties file can be found  in:
Take a look at the Commerce Installation anc Configuration Guide and specifically the section on Application Server Configuration.

How to Migrate a WebLogic Domain from a 32 to a 64 bit JVM/Architecture?

Currently on 32 bit OS which presents a physical constraint when trying to allocate memory.

By limit, a 32 bit OS, will not be able to allocate more than 3 GB on a Linux environment, or 2 GB for Windows environment (not considering Physical Address Extension (PAE) implementation, which can increase the maximum allocatable memory).

When this limit is reached, a migration to a 64 bit architecture is recommended.

Below are the steps on how to install a 64 WebLogic Server version, along with a 64 Bit JVM and then how to migrate the domain to this new environment.


The versions that were used on this test case are the following:

Weblogic Server Version: WebLogic Server Version:
OS: Linux 2.6.18-194.el5 #1 SMP Mon Mar 29 22:10:29 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
JVM:java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Oracle JRockit(R) (build R28.1.1-13-139783-1.6.0_22-20101206-0136-linux-x86_64, compiled mode)

Setting Up, Using and troubleshooting a Weblogic 12c Cluster

In this post reader can easily understand the weblogic clustering concept. Topics Covered in this post are :

  1. What is a WebLogic Cluster?
  2. Set up & configuration
  3. Best practices
  4. Troubleshooting
  5. Dynamic Clustering (WLS 12.1.2 and up)
  6. Cluster Targeted JMS Servers (WLS 12.1.2 and up)

1. What is a WebLogic Cluster?

Multiple server instances running simultaneously and working together to transparently provide clients with increased scalability and reliability for servers, WebApp, WS, EJB apps, JDBC resources, JMS and more A cluster appears to clients to be a single server instance All clustered servers must run the same WLS version and belong to the same domain

Benefits of clustering

Failover : Objects copied to a secondary server that will finish the task in case the primary server is unavailable for any reason
Migration:  Relocation of a full server in the event of a failure
Load balancing :  Uninterrupted availability and even distribution of tasks  among instances

Load Balancing for HTTP clusters

Proxy Servers can be used to provide load balancing (round-robin by default) and failover for a cluster . Example: OHS, IIS, iPlanet

External Hardware LB .  Example: F5 Networks Big-IP

Basic Cluster Proxy Architecture

Basic Cluster Proxy Architecture

2. Setup and Configuration

Domain Configuration wizard

Domain Configuration wizard

assign server to cluster

WebLogic Administration Console

WebLogic Administration Console

WebLogic Administration Console

Weblogic Scripting Tool (WLST)

connect('weblogic','weblogic', 't3://localhost:7001')


  • Architecture
        Basic or multi-tier architecture :  The recommended multi-tier architecture uses one cluster to serve static HTTP content and clustered servlets, and one cluster to serve clustered EJBs

  • Proxy Plug-Ins or physical LB  
           – HttpClusterServlet, iPlanet, OHS or IIS

  • Messaging Mode
             Multicast or Unicast, to broadcast availability of services and heartbeats  IP sockets for peer-to-peer communications between instances
  • Replication Groups
             Preferred list of clustered instances to be used for storing session state  replicas
  • HTTP Sessions replication
              In-memory, file-based, JDBC-based persistence, Coherence*Web

3. Clustering Best Practices



  • Admin server should not be part of a cluster  
            -->  Main purpose of this server is to perform the bulk of the processing for the domain
            -->  Administrative objects are not clusterable
  •  Http Session States need to persist in memory to enable automatic failover of servlets and JSPs
  • Deploy clusterable objects to the cluster, rather than to individual Managed Servers in the cluster

HTTP State Management Best Practices

  •  Create WLS machines if you are replicating the state across servers on different physical machines
  • Use replication groups to define the failover strategy
  • Choose the most appropriate replication strategy depending on the application needs and architecture
  • Use the ServerDebugConfig MBean to track session replication problems
  • Ensure that objects placed in replicated sessions are serializable

Managing HTTP Sessions in a Cluster

Multicast vs Unicast

  • Unicast is better suited for small clusters (less than 20 instances)
  • With over 50 members, ensure that the network allows multicast
  • With 100 members, try to break up the domain into multiple separate domains and individual clusters for better administration and management even though Multicast option can handle such large domains

WebLogic Server Cluster Messaging Protocols

DataSource on Clusters

  • Targeting a data source to a cluster will not enable failover of connections - it will ease the process of reconnecting when a connection fails
  • Multi Data Source to guaranty data source failover  
  • JDBC is a highly stateful client-DBMS protocol, in which the DBMS connection and transactional state are tied directly to the socket between the DBMS process and the client (driver). For this reason, failover of a connection while it is in use is not supported


Troubleshooting Replication Issues

  • Enabling Replication Debugs to Track Session Replication Failures, often overwhelming and filing up logs rapidly with complex data
  • Set the flags from the command line during server startup by adding the following options:
-Dweblogic.debug.<DebugName>=true in addition to

– DebugClusterAnnouncements
  • Debug each Announcement, StateDump, and Attributes msg sent or received by multicast
– DebugFailOver
  • Debug stub -level fail-over processing
– DebugReplication
  • Debug high-level cluster replication information
– DebugReplicationDetails
  • Debug low-level cluster replication information
– DebugCluster

Troubleshooting Multicast Issues

  • utils.MulticastTest
  • Set these flags from the command line during server startup by adding the following options:

HTTP Load Balancing Problems in Cluster Using Proxy Plug-in

  • Configure the proxy plug-in to produce additional diagnostic data
– Enable proxy debug by setting Debug="ALL" in the proxy configuration file
– Enable proxy bridge by setting DebugConfigInfo="ON" in the proxy configuration file
  • Analyze the Proxy Log File and the Proxy Bridge Page
– http://webserver_host:port/path/xyz.jsp?__WebLogicBridgeConfig

  • Search for X-WebLogic-Cluster-List in proxy log to find when a truncated list has been returned from backend cluster node. Determine which backend cluster node has returned the truncated X-WebLogic-Cluster-List by following the preceding log entries for the same request
  • Look for "Exception objects created" under "Runtime statistics" on the proxy bridge page. If the count is greater than 0, then exceptions have occurred (logged in the proxy log)

    5. Dynamic Clustering (WLS 12.1.2 and up)

    • Introduced feature in WebLogic Server 12.1.2
    • Scale up dynamically the number of server instances in your domain
    • A dynamic cluster is any cluster that contains one or more dynamic servers

    Server template

    • Dynamic clusters are based on a single shared server template used to specify the configuration of dynamic servers
    • A dynamic cluster can be created via WLST 

    Creating Dynamic Clusters

    • Specify how many servers are needed at peak load and define a template to use as the base configuration those servers 
    • When additional server capacity is needed, you can then start a server instance without having to first manually configure it and add it to the cluster


    • Individual targeting is not supported
    • Server-specific configuration attributes (e.g. replication groups, user preferred server, hosting server etc)

    6. Cluster Targeted JMS Servers (WLS 12.1.2 and up)

    JMS Server and Cluster before 12.1.2

    • To leverage clustering capabilities of Weblogic JMS such as load balancing and high availability, you need to configure Distributed Destinations
    • Connection factories (resources that enable JMS clients to create JMS connections) can be deployed on multiple WebLogic Server instances
    • Connection factories are bound to the JNDI tree for multiple server instances

    Cluster Targeted JMS Servers

    • Targeting JMS Servers and optionally persistent stores directly to a cluster
    • Enable dynamic scaling of JMS resources in a dynamic cluster or the dynamic members of a mixed cluster (individually configured servers along with dynamic servers)


    • Consider known limitations before developing  applications using dynamic clusters and cluster targeted JMS Servers, example:
                   --No support for Automatic Server Migration (ASM)
                   --Store-and-Forward agents cannot be targeted to a dynamic or mixed server
                   --No support for Replicated distributed topics (RDTs) when any member destination is                           hosted on a cluster targeted JMS server

    Upgrading WebLogic 10.3.x (for PeopleTools 8.51-8.53) to a Newer Maintenance Pack (MP), Patch Level, and/or a Newer Java/JRockit Patch Level

    This document answers frequently asked questions regarding:
      1) Steps to Upgrading WebLogic to a newer maintenance pack and patch level
      2) Questions about Upgrading Java patch level for your WebLogic Install.
      3) Details on how to locate/download/install newer WebLogic Maintenance Packs, Patches and Java Patches

    This document is specifically for PeopleTools 8.51, 8.52 and 8.53 environments which are using WebLogic 10.3.x.

    Give me an overview of the steps to get updated to the latest WebLogic version and patch level. And explain the difference between Maintenance Packs and Patches
    If you are planning on upgrading WebLogic in your PeopleSoft environment, you need to keep in mind that there are actually three separate parts to the upgrade:
        Part #1: Upgrade the WebLogic Maintenance Pack (aka MP).
        Part #2: Upgrade the WebLogic Patch Level
        Part #3: Upgrade the Java (or JRockit) Patch Level

    Note that you do not have to complete each of the above parts. However, we do recommend that you complete each part, as this will get you fully up-to-date on all bug fixes and patches for security vulnerabilities.

    Below are additional details regarding WebLogic Maintenance Packs, WebLogic Patches and Java Patches, that are referenced in Part#1, 2 and 3 above.

    How to Find out if the Proxy Plugin is Outdated for WebLogic

    Often times, customers using a proxy server in front of WebLogic experience performance issues that turn out to be fixed by replacing the older plugin with the most current one provided by Oracle Middleware (Oracle WebLogic Server).

    To find out if your plugin is old, the best way to check the build date is by accessing the WebLogic Bridge page as follows:

    Set DebugConfigInfo="ON" in the proxy configuration file.
    - The proxy bridge page can be viewed with an URL like, http://webserver_host:port/path/xyz.jsp?__WebLogicBridgeConfig
    where path should be something that invokes the plug-in.
    For example,

    You will be able to see the build date and the change number at the end of this proxy bridge page.

    If you are experiencing performance issues via the proxy server and find out that the plugin is old, contact Oracle Customer Support to request a newer one.

    How to extract the root CA from a server certificate?

    Your vendor should send you the root CA along with the public key, or have their root CA's posted on their websites. In any case, it's very simple to extract it from the public key. Just follow these steps.

    1. Rename the public key file from .pem to .cer
    2. On Windows, double click on the file with .cer extension. If your OS is Unix, you will have to transfer the file to a Windows workstation in ASCII mode.
    3. You will see 3 tabs: General, Details and Certification Path. Go to Certification Path.
    4. In this tab, you will see a list in the form of a tree. The first file in the tree is the root CA, the last one is the server certificate or public key. Click on the root CA (first one). Then click on the "View Certificate" button.
    5. The root CA will open up on a separate Window. Go to the "Details" tab.
    6. Click on "Copy to File" button.
    7. Click on "Next", then select "Base 64" from the list of format options and click "Next" again.
    8. Enter a name for your root CA file, anything meaningful to you, like i.e.: VerisignRootCA. The file will be saved with .cer extension.
    9. Now you can import this file into your keystore. Cer format works as well as .pem.

    Setting Up Apache as a Reverse Proxy Server (RPS) on WebLogic 10.3.x

    This postprovides information for installing, configuring, testing and troubleshooting when using Apache Reverse Proxy Server with WebLogic 10.3.x
    The instructions also include steps for  installing and configuring the 'Apache HTTP Server Plug-In'. Note that we recommend you use the Apache HTTP Server Plug-In as it enhances an Apache installation by enabling WebLogic server to handle load balancing or requests that require the dynamic functionality of the WebLogic server.

    OVERVIEW of Apache and Examples of how Apache can be Configured in a PeopleSoft Environment.

    Apache can be used as a Reverse Proxy Server (RPS) to one or more WebLogic PIA's.   When using Apache, the end user enters a browser URL containing a host name/port# that points to the RPS, not the WebLogic server.  Below is the sequence of events that occur in a PeopleSoft environment using an Apache RPS:
      1.  User accesses the PeopleSoft application, from browser, by using a URL containing the hostname and port# of the RPS. 
           Example:  http://ApacheHost:8080/ps/signon.html
      2. The user request is routed through the Apache RPS and then forwarded to the WebLogic plug-in.
          The plug-in then evaluates the request and forwards it to the WebLogic PIA.
      3. The WebLogic PIA then processes the request and returns a response via the plug-in to the Apache RPS.

    Dead Connection Detection (DCD) Explained


    Dead Connection Detection (DCD) is a feature of SQL*Net 2.1 and later, includingOracle Net8 and Oracle NET. DCD detects when a partner in a SQL*Net V2 client/serveror server/server connection has terminated unexpectedly, and flags the dead sessionso PMON can release the resources associated with it. DCD is intended primarily for environments in which clients power down their
    systems without disconnecting from their Oracle sessions, a problemcharacteristic of networks with PC clients.

    DCD is initiated on the server when a connection is established. At this time SQL*Net reads the SQL*Net parameter files and sets a timer to generate an alarm. The timer interval is set by providing a non-zero value in minutes for the SQLNET.EXPIRE_TIME parameter in the sqlnet.ora file.

    When the timer expires, SQL*Net on the server sends a "probe" packet to the client. (In the case of a database link, the destination of the linkconstitutes the server side of the connection.) The probe is essentially an empty SQL*Net packet and does not represent any form of SQL*Net level data,

    but it creates data traffic on the underlying protocol. If the client end of the connection is still active, the probe is discarded, and the timer mechanism is reset. If the client has terminated abnormally,

    the server will receive an error from the send call issued for the probe, and SQL*Net on the server will signal the operating system to release the connection's resources.

    On Unix servers, the sqlnet.ora file must be in either $TNS_ADMIN  or  $ORACLE_HOME/network/admin. Neither /etc nor /var/opt/oracle alone is valid. It should be also be noted that in SQL*Net 2.1.x, an active orphan process (one processing a query, for example) will not be killed until the query completes. In SQL*Net 2.2, orphaned resources will be released regardless of activity. This is a server feature only. The client may be running any supported SQL *Net V2 release. 

    Understanding Inactive Sessions From JDBC Connection Pool in Oracle Weblogic Server

    JDBC connections are established with the database server when there is an application connection request coming from the client. The JDBC connection pool is intended to have a farm of open JDBC connections to the database which can be borrowed by the application. Performance-wise, this is more efficient, since it saves opening and closing a JDBC connection each time. However, this means that a connection can be idle for quite a long time when there is little activity in the system. Most connections will spend most of their time either sitting in the connection pool waiting for a Java thread to open them, or waiting on the Java thread to do something with the data, or waiting on the network to transfer data between the machines. That means that there will be a reasonable number of connections to the database where the STATUS in V$SESSION is "INACTIVE" at any given point in time. That is perfectly normal.
    However, it is important to verify that there is no steady increase in the number of open connections, pointing to a leak of connections that prevent these from being reused and cause the maximum number of connections to be reached. To avoid this:

    • Connections used from the JDBC pool need to be closed after usage by the application code. If close() is not called, connections are not freed and not available for reuse. Please refer to: How To Ensure No ResultSet/Connection/Statement Leaks Exist in Your JDBC Code
    • Connection pools should be configured with timeout properties. Depending on the connection pool, there are particular properties for this. For example, for Oracle Universal Connection Pool (UCP), you can refer to: Controlling Stale Connections
    • There is no mechanism in the Connection pool to determine whether the JDBC connection to the database has been dropped. So the JDBC connection in the pool still seems to be valid until the application borrows it, and then finds out that the connection is invalid as it has been dropped.
    • For this, the connection pool has an option to validate the connection before passing it to the application. On this, for example for UCP, please refer to: Validating connections

    Oracle Weblogic JDBC General Issue Topics

    Troubleshooting JDBC problems by debugging or tracing JDBC

    JDBC debugging and tracing sometimes is key in order to find out what is going on and analyze the SQL statements that actually are sent to the database. However JDBC is a multi-layered subsystem, of which only parts are inside WebLogic Server. Debugging and tracing of the JDBC driver layer is highly driver-dependent. Information regarding debug and trace flags for the drivers are available from the driver vendors.
    Once you have narrowed the problem down to a specific area, you can activate WebLogic Server’s debugging features to track down the specific problem within the application. Debugging can be activated by setting the appropriate ServerDebug configuration attribute to true. See Debugging JDBC Data Sources

    • DebugJDBCConn (scope weblogic.jdbc.connection) will enable tracing of all connection reserve and release operations in data sources as well as all application requests to get or close connections.
    • DebugJDBCSQL (scope weblogic.jdbc.sql) will print information about all JDBC methods invoked, including their arguments and return values, and thrown exceptions.
    • DebugJDBCDriverLogging (scope weblogic.jdbc.driverlogging) will enable JDBC driver level logging. Note that to get driver level tracing for Oracle, you need to use ojdbc14_g.jar instead of ojdbc14.jar. Note that for this debug scope, it can be turned on once via the command line or configuration when the server is booted but cannot be turned on or off dynamically (due to the DriverManager interface).
    These debug flags and tracing can be very verbose, so consider very carefully where you turn on those flags. They will create a lot of output and also possibly have a slight performance impact on your system. They should not be turned on in production systems.

    How to tune JDBC connection pools for production environments?

    Configuration of JDBC connection pools for production systems is a critical and important task to ensure stability and performance. Some general recommendations may help as a starting point for administrators:

    • Set InitialCapacity = MaxCapacity: This will ensure that all connections are opened during WebLogic Server startup. As creation of a physical database connection is very expensive, all needed connections should be opened immediately and kept open.  Before doing so, first insure that the physical memory of the database can handle all connections as they could easily add up in memory and lead to swaps.
    • Disable shrinking by setting ShrinkingEnabledto false: As mentioned above, creation of physical database connections is expensive, so connections should be established once and kept during the complete lifetime of the WebLogic Server instance.
    • Turn off refresh functionality if it is not needed: 
    • Set TestConnectionsOnReserveto true. This will ensure that connections are tested before they go to the application and are reopened if needed.
    • Set the number of connections in the JDBC pool equal to the number of execute threads that use the connections. This helps to avoid ResourceExceptions.

    WebLogic Server : Binary Core File Analysis

    Problem Description

    An application gets a binary core file produced when the WebLogic Server process terminates due to some invalid native core (machine specific code). A server crash, JVM crash, machine crash, or HotSpot error may also be associated with this occurrence. This article will describe what steps are needed to gather information from a core file on various platforms.

    Problem Troubleshooting

    Please note that not all of the following items would need to be done. Some issues can be solved by only following a few of the items.

    Troubleshooting Steps

    Why does the problem occur?

    In order to determine the cause of such an error you need to determine all potential sources of native code used by the WebLogic Server process. The places to focus on are:
    1. The WebLogic Server performance pack. The WebLogic Server performance pack is native code and when enabled could potentially produce such an error. Disable this feature to determine if that is the cause. You can do this via the console or via the command line. Using the console look under the Server tab by setting NativeIOEnabled to false. See the documentation section Enabling Performance Packs to get the exact sequence of steps under the Server tab in the console. The steps are:
      1. Start the Administration Server if it is not already running.
      2. Access the Administration Console for the domain.
      3. Expand the Servers node in the left pane to display the servers configured in your domain.
      4. Click the name of the server instance that you want to configure.
      5. Select the Configuration --> Tuning tab.
      6. If the Enable Native IO check box is selected, please deselect it in the check box so it is now *not* enabled.
      7. Click Apply.
      8. Restart the server.

    Investigating ORA-01000: maximum open cursors exceeded WebLogic Server

    Problem Description

    Oracle uses the OPEN_CURSORS parameter to specify the maximum number of open cursors a session can have at once. When this number is exceeded, Oracle reports an ORA-01000 error. When this error is propagated to WebLogic Server, a SQLException is thrown.
    java.sql.SQLException: ORA-01000: maximum open cursors exceeded
    This pattern discusses possible causes and solutions of this error when using WebLogic Server.

    Problem Troubleshooting

    Please note that not all of the following items would need to be done. Some issues can be solved by only following a few of the items.

    Weblogic JDBC issue : Too Many Open Cursors in the Oracle database

    If the configured amount of allowed open cursors in an Oracle database is exceeded, the following error message will be thrown:

    java.sql.SQLException: ORA-01000: maximum open cursors exceeded
    This can be due to the following possible causes:

    • Incorrect configuration of the JDBC pool regarding the prepared statement cache. Every prepared statement will use one open cursor in the Oracle database. The statement cache holds prepared statements on a connection basis. This means that the Oracle database will use up to (StatementCacheSize)x(MaxCapacity)open cursors for every configured pool. As open cursors will be used for other objects also (e.g., stored procedures or result sets), the number of open cursors needs to be configured high enough to hold all the statements in the statement cache. The setting for OPEN_CURSORS is per session/connection.

      For additional information on statement cache configuration, please see Monitoring JDBC Resources

    getVendorConnection()is called and physical connection is automatically refreshed after each usage by the application (when RemoveInfectedConnections="true")

    As this means that connection pooling loses its effect, i.e., every connection is closed and reopened after each usage, please consider carefully if the application code changes or destroys something on the physical connection that makes such a reopen necessary. If and only if this is not the case, set the property RemoveInfectedConnectionsto false.

    More more details :

    Investigating Weblogic JDBC Issues : Datasource/Pooling

    ResourceException during JDBCDataSource.getConnection() (weblogic.common.ResourceException: No resources available)

    ResourceExceptionsare thrown when a getConnection()request via a DataSourceto a JDBC connection pool cannot be satisfied because either no connection in the pool or no thread is available to handle the connection request. Cause of the missing resource could be either one of:

    • Connection leak in the application.
      Connections used from the JDBC pool need to be closed after usage by the application code. If close() is not called, connections are not freed and not available for reuse. A possible symptom for a connection leak for Oracle JDBC connection pools can be an error message:
      ORA-00020 - maximum number of processes (%s) exceeded
      Enabling WLS JDBC trace logging is a good way to identify potential leaks. Messages such as the following get logged when the WebLogic pool has been watching its connections in use, and this connection is currently reserved, but has not been used at all for the inactive-connection-timeout period.
      <Warning><Common><BEA-000620><Forcibly releasing inactive resource "weblogic.jdbc.common.internal.ConnectionEnv" back in the pool "mypool"
      This typically means the application leaked the connection by losing the reference to the connection without/before closing it. The WebLogic logging will include a full stacktrace of where the connection was reserved. This information should help in reviewing how this connection was managed (lost, missed or unused) without closing.

    WebLogic Server : Investigating JDBC Issues

    The following topics will be covered in this blog.

    • JDBC Datasource/Pooling Issues
      Weblogic Server obtains JDBC connections from a Datasource. Each configured datasource contains a pool of database connections. Configuring it correctly ensures performance and stability of applications and the server itself. Some misconfiguration could lead to many problems such as, but not limited to:
      • weblogic.jdbc.extensions.PoolLimitSQLException
      • weblogic.common.resourcepool.ResourceLimitException: No resources currently available in pool
      • Leaks caused by incorrect management of connections in application code
      • Poor performance of the DBMS or the network, so that connection requests to the underlying database lead to very long startup or communication times for the WebLogic Server
      • Errors or java exceptions during JDBC connectivity setup
      • Connection refresh/reconnect problems after the database was down

    WebLogic Server JDBC Profiling Options

    Connection Usage

                Collect information about threads currently using connections from the pool
                 Data Collected:
                * PoolName - name of the data source to which this connection belongs
                * ID - connection ID
                * User - stack trace of the thread using the connection
                * Timestamp - time stamp showing when the connection was given to the thread


      ####<DemoDataSource1 > <WEBLOGIC.JDBC.CONN.USAGE> <Wed Apr 23 07:39:02 EST 2014> <java.lang.Exception
                at weblogic.jdbc.common.internal.ConnectionEnv.setup(
                at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(
                at weblogic.jdbc.common.internal.ConnectionPool.reserve(
                at weblogic.jdbc.common.internal.ConnectionPool.reserve(