Tuesday Sep 29, 2015

Multi Data Source Configuration for Database Outages

Planned Database Maintenance with WebLogic Multi Data Source (MDS)

This article discusses how to handle planned maintenance on the database server when it is accessed by WebLogic Multi Data Source (MDS) in a fashion that no service interruption occurs.

To ensure there is no service interruption there must be multiple database instances available so the database can be updated in a rolling fashion.  Oracle technologies to accomplish this include RAC cluster  and GoldenGate or a combination of these products (note that DataGuard cannot be used for planned maintenance without service interruption).  Each database instance is configured as a member generic data source, as described in the product documentation.  This approach assumes that the application is returning connections to the pool on a regular basis.

Process Overview

1. On mid-tier systems - Shutdown all member data sources associated with the RAC instance that will be shut down for maintenance. It's important that not all data sources in each MDS list be shutdown so that connections can be reserved on the other member(s). Wait for data source shutdown to complete. See http://docs.oracle.com/cd/E13222_01/wls/docs100/wlsmbeanref/mbeans/JDBCDataSourceRuntimeMBean.html?skipReload=true#shutdown.

2. At this point, it may be desirable to do some work on the database side to reduce remaining connections not associated with WLS data source. For the Oracle database server, this might include stopping (or relocating) the application services at the instances that will be shut down for maintenance, stopping the listener, and/or issue a transactional disconnect for the services on the database instance.  See https://blogs.oracle.com/WebLogicServer/entry/agl_database_outages for more information that is included in the Active GridLink description.

3. Shutdown the instance immediate using your preferred tools

4. Do the planned maintenance.

5. Start up the database instance using your preferred tools

6. Startup the services when the database instances are ready for application use.

7. On midtier systems -Start the member data sources. See See http://docs.oracle.com/cd/E13222_01/wls/docs100/wlsmbeanref/mbeans/JDBCDataSourceRuntimeMBean.html?skipReload=true#start.

Shutting down the data source

Shutting down the data source involves first suspending the data source and then releasing the associated resources including the connections. When a member data source in a MDS is marked as suspended, the MDS will not try to get connections from the suspended pool but will go to the next member data source in the MDS to reserve connections. It's important not all data sources in each MDS list be shut down at the same time. If all members are shut down or fail, then access to the MDS will fail and the application will see failures.

When you gracefully suspend a data source, which happens as the first step of shut down:

- the data source is immediately marked as suspended at the beginning of the operation so that no further connections will be created on the data source

- idle (not reserved) connections are not closed but are marked as disabled.

- after a timeout period for the suspend operation, all remaining connections in the pool will be marked as suspended and “java.sql.SQLRecoverableException: Connection has been administratively disabled. Try later.” will be thrown for any operations on the connection, indicating that the data source is suspended. These connections remain in the pool and are not closed. We won't know until the data source is resumed if they are good or not. In this case, we know that the database will be shut down and the connections in the pool will not be good if the data source is resumed. Instead, we are doing a data source shutdown which will close all of the disabled connections.

The timeout period is 60 seconds by default. This can be changed by configuring or dynamically setting Inactive Connection Timeout Seconds to a non-zero value (note that this value is overloaded with another feature when connection leak profiling is enabled). There is no upper limit on the inactive timeout. Note that the processing actually checks for in-use (reserved) resources every tenth of a second so if the timeout value is set to 2 hours and it's done a second later, it will complete a second later.

Note that this operation runs synchronously; there is no asynchronous version of the mbean operation available. It was designed to run in a short amount of time but testing shows that there is no problem setting it for much longer. It should be possible to use threads in jython if you want to run multiple operations in one script as opposed to lots of script (a jython programmer is needed).

This procedure works for MDS configured with either Load-Balancing or Failover.

This is what a WLST script looks like to edit the configuration to increase the suspend timeout and then use the runtime MBean to shutdown a data source. It would need to be integrated into the existing framework for all WLS servers/data sources.

java weblogic.WLST myscript2.py
import sys, socket, os
hostname = socket.gethostname()
# Edit the configuration to set the suspend timeout

cd('/JDBCSystemResources/' + datasource + '/JDBCResource/' + datasource + '/JDBCConnectionPoolParams/' + datasource )

cmo.setInactiveConnectionTimeoutSeconds(21600) # set the suspend timeout


# Shutdown the data source

cd('/JDBCServiceRuntime/' + svr + '/JDBCDataSourceRuntimeMBeans/' + datasource )



Note that if MDS is using a database service, you cannot stop or relocate the service before suspending or shutting down the MDS. If you do,. MDS may attempt to create a connection to the now missing service and it will react as though the database is down and kill all connections, not allowing for a graceful shutdown. Since MDS suspend ensures that no new connections are created at the associated instance (and the MDS only creates connections on this instance, never another instance even if relocated), stopping the service is not necessary for MDS graceful shutdown. Also, since MDS suspend causes all connections to no longer do any operations, no further progress will be made on any sessions (the transactions won't complete) that remain in the MDS pool.

There is one known problem with this approach related to XA affinity that is enforced by the MDS algorithms. When an XA branch is created on a RAC instance, all additional branches are created on the same instance. While RAC supports XA across instances, there are some significant limitations that applications run into before the prepare so MDS enforces that all operations be on the same instance. As soon as the graceful suspend operation starts, the member data source is marked as suspended so no further connections are allocated there. If an application using global transactions tries to start another branch on the suspending data source, it will fail to get a connection and the transaction will fail. In this case of an XA transaction spanning multiple WLS servers, the suspend is not graceful. This is not a problem for Emulate 1PC or 2pc, which uses a single connection for all work, and LLR.

If there is a reason to separate the suspending of the data source, at which point all connections are disabled, from the releasing of the resources, it is possible to run suspend followed by forceShutdown. A forced shutdown must be used to avoid going through the waiting period a second time. This separation is not recommended.

To get a graceful shutdown of the data source when shutting down the database, the data source must be involved. This process of shutting down the data source followed by shutdown of the database requires coordination between the mid-tier and the database server processing. Processing is simplified by using Active GridLink instead of MDS; see the AGL blog included above.

When using the Oracle database, it is recommended that an application service be configured for each database so that it can be configured to have HA features. By using an application service, it is possible to start up the database without data source starting to use it until the administrator is ready to make it available and the application service is explicitly started.

Thursday Sep 10, 2015

Active GridLink Configuration for Database Outages

This article discusses designing and deploying an Active GridLink (AGL) data source to handle database down times with an Oracle Database RAC environment. 

AGL Configuration for Database Outages

It is assumed that an Active GridLink data source is configured as described "Using Active GridLink Data Sources" http://docs.oracle.com/middleware/1213/wls/JDBCA/gridlink_datasources.htm#JDBCA373   with the following.

- FAN enabled.  FAN provides rapid notification about state changes for database services, instances, the databases themselves, and the nodes that form the cluster.  It allows for draining of work during planned maintenance with no errors whatsoever returned to applications.

- Either auto-ONS or an explicit ONS configuration.

- A dynamic database service.  Do not connect using the database service or PDB service – these are for administration only and are not supported for FAN.

- Testing connections.  Depending on the outage, applications may receive stale connections when connections are borrowed before a down event is processed.  This can occur, for example, on a clean instance down when sockets are closed coincident with incoming connection requests. To prevent the application from receiving any errors, connection checks should be enabled at the connection pool.  This requires setting test-connections-on-reserve to true and setting the test-table (the recommended value for Oracle is “SQL ISVALID”).

- Optimize SCAN usage.  As an optimization to force re-ordering of the SCAN IP addresses returned from DNS for a SCAN address, set the URL setting LOAD_BALANCE=TRUE for the ADDRESSLIST in database driver and later.   (Before, use the connection property oracle.jdbc.thinForceDNSLoadBalancing=true.)

Planned Outage Operations

For a planned downtime, the goals are to achieve:

- Transparent scheduled maintenance: Make the scheduled maintenance process at the database servers transparent to applications.

- Session Draining: When an instance is brought down for maintenance at the database server draining ensures that all work using instances at that node completes and that idle sessions are removed. Sessions are drained without impacting in-flight work.  

The goal is to manage scheduled maintenance with no application interruption while maintenance is underway at the database server.  For maintenance purposes (e.g., software and hardware upgrades, repairs, changes, migrations within and across systems), the services used are shutdown gracefully one or several at a time without disrupting the operations and availability of the WLS applications. Upon FAN DOWN event, AGL drains sessions away from the instance(s) targeted for maintenance. It is necessary to stop non-singleton services running on the target database instance (assuming that they are still available on the remaining running instances) or relocate singleton services from the target instance to another instance.  Once the services have drained, the instance is stopped with no errors whatsoever to applications.

 The following is a high level overview of how planned maintenance occurs.

–Detect “DOWN” event triggered by DBA on instances targeted for maintenance

–Drain sessions away from that (those) instance(s)

–Perform scheduled maintenance at the database servers

–Resume operations on the upgraded node(s)

Unlike Multi Data Source where operations need to be coordinated on both the database server and the mid tier, Active GridLink co-operates with the database so that all of these operations are managed from the database server, simplifying the process.  The following table lists the steps that are executed on the database server and the corresponding reactions at the mid tier.

Database   Server Steps


Mid Tier Reaction

Stop the   non-singleton service without   ‘-force’ or relocate the singleton service.  

Omitting the –server option operates on all   services on the instance.

$ srvctl   stop service –db <db_name>
-service <service_name>
-instance   <instance_name


$ srvctl   relocate service –db <db_name>
-service <service_name> -oldinst   <oldins> -newinst <newinst>

The FAN Planned   Down (reason=USER) event for the service informs the connection pool that a service   is no longer available for use and connections should be drained.  Idle   connections on the stopped service are released immediately.  In-use connections are released when returned   (logically closed) by the application.    New connections are reserved on other  instance(s) and databases offering the   services.  This FAN action invokes draining the sessions from the   instance without disrupting the application.

Disable   the stopped service to ensure it is   not automatically started again. Disabling the service is optional. This step   is recommended for maintenance actions where the service must not restart   automatically until the action has completed. . 

$ srvctl   disable service –db <db_name> -service <service_name> -instance   <instance_name>

No new   connections are associated with the stopped/disabled service at the mid-tier.

Allow   sessions to drain.

The   amount of time depends on the application.    There may be long-running queries.    Batch programs may not be written to periodically return connections   and get new ones. It is recommended that batch be drained in advance of the   maintenance.

Check   for long-running sessions. Terminate   these using a transactional disconnect.    Wait for the sessions to drain.    You can run the query again to check if any sessions remain.

SQL>   select count(*) from ( select 1 from v$sessionwhere service_name in   upper('<service_name>') union all
select 1 from v$transaction where   status = 'ACTIVE' )
  SQL> exec

The   connection on the mid-tier will get an error.    If using application continuity, it’s possible to hide the error from   the application by automatically replaying the operations on a new connection   on another instance.  Otherwise, the   application will get a SQLException.

Repeat   the steps above.

Repeat   for all services targeted for planned maintenance

Stop the   database instance using the immediate option.

$ srvctl   stop instance –db <db_name>
-instance <instance_name> -stopoption   immediate

No   impact on the mid-tier until the database and service are re-started.

Optionally   disable the instance so that it will not automatically start again during   maintenance.

This   step is for maintenance operations where the services cannot resume during   the maintenance.

$ srvctl   disable instance –db <db_name> -instance <instance_name>

Perform   the scheduled maintenance work.

Perform   the scheduled maintenance
work – patches, repairs and changes.

Enable   and start the instance.

$ srvctl   enable instance –db <db_name> -instance <instance_name>
  $ srvctl start instance –db <db_name>
-instance <instance_name>

Enable   and start the service back.  Check that   the service is up and running.

$ srvctl   enable service –db <db_name>
-service <service_name>
-instance   <instance_name>

$ srvctl   start service –db <db_name>
-service <service_name>
-instance   <instance_name>

The FAN   UP event for the service informs the connection pool that a new instance is   available for use, allowing sessions to be created on this instance at the   next request submission.  Automatic   rebalancing of sessions starts.

The following figure shows the distribution of connections for a service across two RAC instances before and after Planned Downtime.  Notice that the connection workload moves from fifty-fifty across both instances to hundred-zero.  In other words, RAC_INST_1 can be taken down for maintenance without any impact on the business operation.

Unplanned Outages

The configuration is the same for planned and unplanned outages.

There are several differences when an unplanned outage occurs.

  • A component at the database server may fail making all services unavailable on the instances running at that node.  There is not stop or disable on the services because they have failed.
  • The FAN unplanned DOWN event (reason=FAILURE) is delivered to the mid-tier.
  • For an unplanned event, all sessions are closed immediately preventing the application from hanging on TCP/IP timeouts.  Existing connections on other instances remain usable, and new connections are opened to these instances as needed.
  • There is no graceful draining of connections.  For those applications using services that are configured to use Application Continuity, active sessions are restored on a surviving instance and recovered by replaying the operations, masking the outage from applications.  If not protected by Application Continuity, any sessions in active communication with the instance will receive a SQLException.

Tuesday Sep 01, 2015

Active GridLink URLs

Active GridLink (AGL) is the data source type that provides connectivity between WebLogic Server and an Oracle Database service, which may include one or more Oracle RAC clusters or DataGuard sites.  As the supported topologies grow to include additional features like Global Database Services (GDS) and new features are added to the Oracle networking and database support, the complexity of the URL to access this has also gotten more complex. There are lots of examples in the documentation.  This is a short article that summarizes patterns for defining the URL string for use with AGL.

It should be obvious but let me start by saying AGL only works with the Oracle Thin Driver.

AGL data sources only support long format JDBC URLs. The supported long format pattern is basically the following (there are lots of additional properties, some of which are described below).


If not using SCAN, then the ADDRESS_LIST would have one or more ADDRESS attributes with HOST/PORT pairs. It's recommended to use SCAN if possible and it's recommended to use VIP addresses to avoid TCP/IP hangs.

Easy Connect (short) format URLs are not supported for AGL data sources. The following is an example of a Easy Connect URL pattern that is not supported for use with AGL data sources:


General recommendations for the URL are as follows.

- Use a single DESCRIPTION.  Avoid a DESCRIPTION_LIST to avoid connection delays.

- Use one ADDRESS_LIST per RAC cluster or DataGuard database.

- Put RETRY_COUNT, RETRY_DELAY, CONNECT_TIMEOUT at the DESCRIPTION level so that all ADDRESS_LIST entries use the same value. 

- RETRY_DELAY specifies the delay, in seconds, between the connection retries.  It is new in the release.

- RETRY_COUNT is used to specify the number of times an ADDRESS list is traversed before the connection attempt is terminated. The default value is 0.  When using SCAN listeners with FAILOVER = on, setting the RETRY_COUNT parameter to 2 means the three SCAN IP addresses are traversed three times each, such that there are nine connect attempts (3 * 3).

- CONNECT_TIMEOUT is used to specify the overall time used to complete the Oracle Net connect.  Set CONNECT_TIMEOUT=90 or higher to prevent logon storms.   Through the JDBC driver, CONNECT_TIMEOUT is also used for the TCP/IP connection timeout for each address in the URL.  This second usage is preferred to be shorter and eventually a separate TRANSPORT_CONNECT_TIMEOUT will be introduced.  Do not set the oracle.net.CONNECT_TIMEOUT driver property on the datasource because it is overridden by the URL property.

- The service name should be a configured application service, not a PDB or administration service.

- Specify LOAD_BALANCE=on per address list to balance the SCAN addresses.

Using Orachk to Clean Up Concrete Classes for Application Continuity

As I described in the blog Part 2 - 12c Database and WLS - Application continuity, Application Continuity (AC) is a great feature for avoiding errors to the user with minimal changes to the application and configuration. Getting rid of any references to Oracle concrete classes is the first step.

Oracle has a utility program that you can download from MOS to validate various hardware, operating system, and software attributes associated with the Oracle database and more (it’s growing). The program name is orachk. The latest version is and starting in this version, there are some checks available for applications running with AC.

There is enough documentation about getting started with orachk so I’ll just say to download and unzip the file. The AC checking is part of a larger framework that will have additional analysis in future versions. This article focuses on the analysis for Oracle concrete classes in the application code.

AC is unable to replay transactions that use oracle.sql deprecated concrete classes of the form ARRAY, BFILE, BLOB, CLOB, NCLOB, OPAQUE, REF, or STRUCT as a variable type, a cast, the return type of a method, or calling a constructor. See New Jdbc Interfaces for Oracle types (Doc ID 1364193.1) for further information about concrete classes. They must be modified for AC to work with the application. See Using API Extensions for Oracle JDBC Types for many examples of using the newer Oracle JDBC types in place of the older Oracle concrete types.

There are three values that control the AC checking (called acchk in orachk) for Oracle concrete classes. They can be set either on the command line or via shell environment variable (or mixed). They are the following.

Command Line Argument

Shell Environment Variable


–asmhome jarfilename  


This must point to a version of asm-all-5.0.3.jar that you download from http://asm.ow2.org/.

-javahome JDK8dirname


This must point to the JAVA_HOME directory for a JDK8 installation.

-appjar dirname


To analyze the application code for references to Oracle concrete classes like oracle.sql.BLOB, this must point to the parent directory name for the code. The program will analyze .class files, and recursively .jar files and directories. If you have J2EE .ear or .war files, you must recursively explode these into a directory structure with .class files exposed.

This test works with software classes compiled for Oracle JDBC 11 or 12.

When you run the AC checking, the additional checking about database server, etc. is turned off. It would be common to run the concrete class checking on the mid-tier to analyze software that accesses the Oracle driver.

I chose some old QA test classes that I knew had some bad usage of concrete classes and ran the test on a small subset for illustration purposes. The command line was the following.

$ ./orachk -asmhome /tmp/asm-all-5.0.3.jar -javahome /tmp/jdk1.8.0_40 -appjar /tmp/appdir

This is a screen shot of the report details. There is additional information reported about the machine, OS, database, timings, etc.

From this test run, I can see that my one test class has five references to STRUCT that need to be changed to java.sql.Struct or oracle.jdbc.OracleStruct.

Note that WLS programmers have been using the weblogic.jdbc.vendor.oracle.* interfaces for over a decade to allow for wrapping Oracle concrete classes and this AC analysis doesn’t pick that up (there are five weblogic.jdbc.vendor.oracle.* interfaces that correspond to concrete classes). These should be removed as well. For example, trying to run with this ORACLE extension API and the WLS wrapper

import weblogic.jdbc.vendor.oracle.OracleThinBlob;

OracleThinBlob blob = (OracleThinBlob)rs.getBlob(2);
java.io.OutputStream os = blob.getBinaryOutputStream();

on a Blob column using the normal driver works but using the replay driver yields

java.lang.ClassCastException: weblogic.jdbc.wrapper.Blob_oracle_jdbc_proxy_oracle
$1OracleBlob$$$Proxy cannot be cast to weblogic.jdbc.vendor.oracle.OracleThinBlob

It must be changed to use the standard JDBC API

java.sql.Blob blob = rs.getBlob(2);
java.io.OutputStream os = blob.setBinaryStream(1);

So it’s time to remove references to the deprecated Oracle and WebLogic classes and preferably migrate to the standard JDBC API’s or at least the new Oracle interfaces. This will clean up the code and get it ready to take advantage of Application Continuity in the Oracle database.

Thursday Aug 13, 2015

WebLogic Server 12.1.3 Developer Zip Update 3

WebLogic Server 12.1.3 Developer Zip Update 3 has just been posted to OTN for download. 

Update 3 contains the same set of bugs fixes in the WebLogic Server Patch Set Update, providing developers who use the developer zip distribution with a version that corresponds to the latest version of WebLogic Server 12.1.3 used for production.

Download page:


The README file for Update 3 provides details of the updates:


Tuesday Jun 30, 2015

Oracle Cloud Application Foundation Innovation Awards Now Open for Nominations!

Is your organization using Oracle Cloud Application Foundation that includes Oracle WebLogic Server, Oracle Coherence and Oracle Tuxedo to deliver unique business value? The Innovation Awards awards honor our customers and partners for their cutting-edge solutions. Winners are selected based on the uniqueness of their business case, business benefits, level of impact relative to the size of the organization, complexity and magnitude of implementation, and the originality of architecture.

The 2015 awards will be presented during Oracle OpenWorld 2015, October 26-29, in San Francisco.

Submit your nomination for WebLogic/Coherence/Tuxedo by July 31!

Award winners receive:

  • Oracle Fusion Middleware Innovation Award for WebLogic trophy
  • One free pass to Oracle OpenWorld 2015
  • Priority consideration for placement in Profit magazine, Oracle Magazine, or other Oracle publications and press releases
  • Oracle Fusion Middleware Innovation logo for inclusion on your own website and/or press release   

All nominees receive consideration for:

  • Participating in OpenWorld panels and speaking opportunities
  • Featured Customer Success Story on Oracle.com
  • Placement in Profit magazine and/or Oracle Magazine
  • Placement in an Oracle press release or Oracle Fusion Middleware podcast
Nomination deadline: 5:00 p.m. PT July 31, 2015
All nominated solutions should be in production or in active pilot phase

For additional information, please email Innovation-Middleware_us@oracle.com

Monday Mar 16, 2015

OpenWorld 2014: WebLogic Cloud Approaches

By Ancy Dow, Oracle Tech Cloud Account Strategist [Another OpenWorld session that Ancy found relevant and wanted to share with all of us.]

According to a recent ComputerWorld Survey, nearly 90% of IT executives now want to implement cloud solutions. But what is the best cloud strategy for your organization—private, public, or hybrid? Senior Product Marketing Director Ayalla Goldschmidt and Product Management Vice President Mike Lehman share best practices on choosing a pragmatic cloud approach for your organization’s implementation of WebLogic Server, as customers leveraging WebLogic Server now have unprecedented options when architecting an enterprise cloud strategy.

WebLogic in the Cloud – Oracle’s Investment Strategy

Typically, we see three types of customers really interested in moving to the cloud. First are developers who look to move to the cloud for faster provisioning and working with Java in a very lightweight fashion. Secondly, many customers are IT operations-oriented individuals who seek to shift their capital expenditures, and instead pay a far lower subscription cost for a cloud provider to take care of everything. Finally, lines-of-businesses individuals building seasonal or non-mission critical applications don’t want to go through the long development cycle of building out an infrastructure and supporting environments.

To meet all these needs, Oracle’s Cloud strategy is to deliver a flexibility of deployment choices, with unparalleled ease of use. The on-premise private cloud is the most straightforward path to cloud and Oracle has currently invested significantly in this area to bring cloud capabilities into the WebLogic platform. The second investment area is bringing WebLogic to the public cloud through the Java Cloud Service (JCS), with options such as automated patching and tooling. The third and final investment area is partnerships we’ve established with Microsoft Azure, Amazon, Verizon Terremark, and even more vendors coming in the future. 

A Hybrid Cloud Model

Given all these options, should you mix your workloads between private and public? Very sensitive customer or employee data that needs to meet geopolitical boundaries should be kept in an on-premise private cloud. On the opposite end, customers who pursue public cloud entrust security in the hands of the cloud vendors, prioritizing faster response times and extreme agility within competitive environments. With a hybrid approach, customers host mission-critical applications in-house, but also look opportunistically for places in which public cloud could make more sense. With this strategy, customers meet compliance and security requirements where needed, but can also learn and seek to expand their public cloud footprint over time for better resource utilization, cost savings, and flexibility. 

Why Choose Oracle Cloud?

Oracle is uniquely positioned as a cloud provider because of its ease of portability from one cloud solution to the other. From a private cloud perspective, investments center around WebLogic Server, Coherence with in-memory caching, and Enterprise Manager as a set of high availability technology for provisioning and managing customers’ environment lifecycle. Customers can take the latest versions of these tools—WebLogic Server 12c—to get a cloud environment up and running from an operational and developer-friendly perspective. This same exact set of products is available through a self-service, self-managing, public cloud portal with Java Cloud Service. 
The full 45-minute session offers further insights on criteria that can help you create a framework for decision making around private versus public cloud. More information is also available in the Computerworld cloud survey. Download the survey report from http://www.oracle.com/goto/computerworld. Our early adopters have already been able to reduce their implementation time for new applications from months to weeks, and we look forward to making that a possibility for you as well.

With this blog post, we end our series on OpenWorld Cloud Application Foundation sessions. Hope you enjoyed it. 

Monday Mar 09, 2015

WLS JDBC Driver Patching

The handling of Oracle driver jar patches is complicated but getting sorted out. This article tries to gather the information in one place with pointers to more details.  There are a few patches that are still not available, marked as TBA (To Be Available) in the tables below.  As these files become available, this page will be updated.

WLS 10.3.6, 12.1.1, and 12.1.1 shipped Database jar files.  However these are non-standard versions of the jars with additional bug fixes and enhancements to support WLS.  That means that you can't just drop in an patch or upgrade to using standard released jar files. Although support is required to provide patches as needed, it will be difficult and the recommendation is to upgrade to a special patch that contains and all of the patches and enhancements in the database jar files shipped with WLS. It's further complicated because WLS started using the Oracle Universal Installer in 12.1.2, requiring a different patch format.

WLS 10.3.6, 12.1.1, 12.1.2, and 12.1.3 also support running with Oracle Database 12c client jar files. For WLS 10.3.6 through 12.1.2, the jar files must be manually installed; there is no installer or patch to automate this upgrade. To get patches, you must be running with the Database jar files; WLS patches will not be generated for the Database jar files. WLS 12.1.3 ships with a pre-release version of Database driver jar files and a patch will be available to upgrade to the production version of these files. After this upgrade, standard database Oracle patch files will work as expected for WLS 12.1.3 (and WLS 12.1.2 with a manual upgrade to database jar files).

Patching the installed Oracle Driver

WLS Release

Oracle Driver Install

Database Jar

Patch Strategy


10.3.6 WLS patch


12.1.1 WLS patch


12.1.2 opatch

Patch Request 18557114 for bug 19477203


Pre- opatch to bring up to shipping; standard opatch for additional bug fixes

Patch 20741228: 12.1.3 WLS UPGRADE TO JDBC RELEASE

Running with the Database 12c Driver

WLS Release installation

Database Jar Patch Strategy

Documentation for Installation
Documentation for patching


Manual installation of WLS patch



Manual installation of WLS patch



Manual installation of opatch


Standard patch procedure


Pre- installed; Patch to bring up to shipping opatch


Patch 20741228: 12.1.3 WLS UPGRADE TO JDBC RELEASE

Standard patch procedure

On a related topic, updating non-Oracle driver jar files is covered by the following note.


This includes the DataDirect and MySQL drivers that are shipped in the kit. The jar file is backed up and removed, the new file installed, and the CLASSPATH adjusted if the jar name changes.

You'll notice that releases earlier than WLS 10.3.6 are not discussed.  For releases earlier than WLS 10.3.4, they depend only on the ojdbcN.jar file.  It's possible that they will work with the jar file but that hasn't been certified and they are not still in error correction support.  For WLS 10.3.4 or 10.3.5, it depends not only on a specific ojdbc jar file but also ONS/UCP jars that have the package names renamed.  They will likely not work correctly with the jar file (certainly not Active GridLink).  Since these releases ended error correction support in May 2012, you will need to upgrade to WLS 10.3.6 or 12.1.x to use later driver jar files.

Friday Mar 06, 2015

OpenWorld Session on Security Practices for WebLogic & Coherence

by Jess Brown, Oracle Tech Cloud Account Strategist [Another OpenWorld session Jess found interesting and wanted to share with all of us.]

Ensuring the security of your application server deployments is more important than it has ever been. Security for new forms of technology such as Java, Heartbleed, and Cloud computing have pushed for new levels of security awareness during this past year. Specifically, building Java Cloud Service with WebLogic heightens the need for security. Oracle Cloud offerings based on WebLogic Server and Coherence have driven new requirements for securing WebLogic/Coherence environments. This session will cover evolving security challenges, best practices for securing Oracle Cloud Systems, and practical advice for securing your own on premise WebLogic/Coherence systems. Always remember to roll out defense in depth, the more layers of defense for your systems, the better! Be sure to check out the session video here (http://bit.ly/oow14cafsessions)

Thursday Feb 26, 2015

OpenWorld Double Dose: Maximum Availability in the Cloud

Integrated, high availability IT infrastructure capabilities are critical for reducing downtime and costs, and creating ideal performance and SLA results. In this next session of the Oracle Open World 2014 series, Shari Yamaguchi and Frances Zhao from Oracle’s Product Management team share best practices on how to architect highly available multi-data center solutions. They also share what real world customers are doing to achieve maximum available architectures with WebLogic Server—so be sure to check out the video itself here (http://bit.ly/oow14cafsessions) for those highly relevant case studies and proven strategies.

What is Maximum Availability Architecture (MAA)?

Maximum availability architecture (MAA) incorporates the high availability solutions that Oracle has invested in and built out across the stack. The key focus is on ensuring customers’ businesses and applications can fully meet their end-user community’s needs and requirements. In today’s world, downtime is no longer an option, but a given—and this is why Oracle has strategically invested in end-to-end MAA solutions to ensure your systems stay up and running across the board. At the end of the day, the #1 priority is that your end users can get to the environments and applications they need to within a specified period of time.

MAA Strategy & Investment

Within IT, customers need a quick way to easily get a view of what's going on across all their data centers, environments, and applications so that in case of a sudden performance degradation or failure, alerts are immediately sent to the right administrators. Given the importance of manageability, Oracle has invested significantly in Enterprise Manager Grid Control (EMGC), building tools within EMGC for easier monitoring and management such as job systems for automated patching and backup. The Oracle Traffic Director has also been a key tool in connecting the management console to the middle-tier—it is a front-end WebLogic Server that handles web-tier requests and routes them to different clusters.

From a Database 12c perspective, features like Flashback provde significant capabilities especially for those connected to applications, because customers can bring up a test environment, read and write against that environment, validate, shut it back down, flash it back to a previous state, and continue rolling forward through a recovery. Active GridLink, Data Guard, and Site Guard are also key investment areas that allow seamless and automatic failover between different RAC instances. Finally, Coherence is another big investment area as it is a high-end caching product that provides an integrated solution with WebLogic. With session replication, Coherence can be used not only to offset your data from database, but also could be high-availability disaster recovery solution for your WebLogic Server session state.

Core Technologies and MAA Features

To support these core investments in maximum availability, there are three primary areas of technology that Oracle focuses on implementing to support MAA in its platform architecture. The first area is management configuration monitoring—with Enterprise Manager and Site Guard, we monitor your product across different data centers. The second area is in RPO (recovery point objective)—which is related to how fast you can move your data for replication and for recovery—Oracle is investing in file base data replication. And finally, for RTO (recovery time objective)—which is related to how fast you can recover your transactions—one huge new feature is XA transaction recovery, removing the need to write every transaction statement in the T-log and making transactions automatically recoverable.

In conclusion, MAA is extremely critical to your business, which is why it is a huge priority for Oracle. The complete Oracle Solution is a global-level management configuration with Enterprise Manager, RPO, and RTO runtime for the middle-tier (including WebLogic, Coherence, and Oracle Traffic Director), and an integrated back-end database. Any one-tier disaster recovery adds value but the real importance lies in connecting all the pieces together, to maximize operational efficiency and minimize risk. 

Tuesday Feb 24, 2015

Next Up: WebLogic Server Management Session from OpenWorld

by Jess Brown, Oracle Tech Cloud Account Strategist

Continuing on from the past weeks, wherein we have been promoting key OpenWorld session content, today we want to highlight the session which focuses on how the new management, monitoring, and administration features in WebLogic 12c and Enterprise Manager Cloud Control 12c can help simplify and automate the management of your WebLogic environments. The session highlights new features and best practices that apply to managing your Java platform with an emphasis on private cloud scenarios: configuring domains, enabling elasticity with Dynamic Clusters, Managed Coherence Servers, and REST Management APIs, and simplified monitoring with WLDF, along with automated patching, lifecycle management, self-service, and multi-domain management, all from a single pane of glass in Cloud Control. The session also includes a discussion of strategic directions and roadmap for WebLogic management (i.e. Multitenancy which will allow for high-density configuration).

Here is how to access it, in case you missed it at OpenWorld, or even if you attended the session but may want to review the content. Contents of many more sessions along demos are hosted at  http://bit.ly/oow14cafsessions

Monday Feb 23, 2015

Sonatype Nexus 2.11.2 supports Oracle Maven Repository

The Sonatype team have announced the release of the Nexus 2.11.2 repository manager that now works with the Oracle Maven Repository.

With the new Nexus 2.11.2 release we are supporting the authentication mechanism used for the Oracle Maven repository in both Nexus OSS and Nexus Pro. This allows you to proxy the repository in Nexus and makes the components discoverable via browsing the index as well as searching for components. You will only need to set this up once in Nexus and all your projects. Developers and CI servers get access to the components and the need for any manual work disappears. On the Nexus side, the configuration changes can be done easily as part of your upgrade to the new release.

Check out their blog @ Using the Oracle Maven Repository with Nexus

Friday Feb 13, 2015

OpenWorld 2014 Round 3…Highlighting Oracle Java Cloud

by Ancy Dow, Oracle Tech Cloud Account Strategist

[I was wondering if I was the only one getting excited about these videos. So I asked my friend Ancy. She took a peak and not only did she like the videos, she wrote up this blog herself!]

In this session, Anand Kothari, Product Manager for Oracle Java Cloud Service and Oracle JaaS, and Harshad Oak, Oracle ACE Director, demonstrate how you can transform your development experience with Oracle’s Java Cloud. The ease and flexibility of developing in Java Cloud is unmatched, as customers can quickly build and deploy applications—be they existing Java applications, simple extensions to Oracle SaaS services, or new applications on-premise or in the cloud, using tools and techniques developers already use and love.

Oracle’s differentiating factor is that it is one of the only companies that has services across the stack—with the largest breadth of SaaS products—so it is a winning choice for customers who want a single vendor to be able to give them everything they want. Because of this, Oracle can go beyond just spinning up virtual machines, but rather, offer a first-class experience on Database, Java, or any service in the stack, abstracting these services so they are extremely simple to use in the Oracle cloud. Hybrid solutions are also possible, and workloads running in your private cloud can seamlessly be brought onto public and back because the same services are offered in both. And because it is cloud, this enterprise-grade technology comes with all the cloud economics, infinite scale, and capacity.

Currently, there are two Java Cloud Services available on cloud.oracle.com. The JCS SaaS Extension is purpose-built for you to build SaaS extensions to our Oracle SaaS services. Because it is abstracted, customers don’t have access to the infrastructure, but users interact with it much like any SaaS service, which means that there is no patching or backing up required.

Java Cloud Service is a full production environment built using our best practices at all tiers. At the web tier, at the app tier, at the database tier, everything was built so that you get a complete environment with one click that has been fully integrated by Oracle and is meant for production. Java Cloud Service itself is fully customizable, and comes with the complete app container so that customers can bring their applications without any code changes to the Oracle Cloud environment. Customers have access to the underlying infrastructure so they can customize applications to fit their needs, and because there is built-in high availability, you can have a multi-cluster, multi-node cluster on it. There is also a choice of versions, and it is similarly simple to the SaaS Extension service, with automated tooling around patching, backup, restore, and scalability, to make it extremely flexible and easy to create and maintain environments in the cloud.

For test and development use cases, customers may not need rollback capacity or certain features, so Oracle also created JCS Virtual Image, a highly simple environment to get started on. Oracle gives you the same SLA’s so you can put a production application on it, and because there’s less automation, it is more affordable, In Virtual Image, Oracle starts you off with a single VM for a simple use case. Mostly you'll do functional development on the Virtual Image, and then when you test clusterability and high availability, you use Java Cloud Services. Because tooling is not there, you still have underlying infrastructure access and can create clusters yourself, but that's the whole premise: an extremely simple environment optimized for test and dev.

There are many more capabilities about the Java Cloud Service suite that I can’t sum up in one blogpost, but check out the video of the session hosted here at http://bit.ly/oow14cafsessions to see the exciting demos themselves!

Wednesday Feb 11, 2015

Is your IT private PaaS ready? Take this 10-minute Assessment to find out

By the end of 2015, end-user spending on cloud services is expected to exceed $180 billion[1]. The shift toward cloud is undeniable, as is the need for hybrid cloud. Driven by legal, political, security, control, historical, cultural [add more reasons here] needs, organizations will continue to run some of their applications inside their firewall (in addition to running many of their applications on a public cloud), which will ultimately drive the need to create a private cloud infrastructure.