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 12.1.0.2 and later.   (Before 12.1.0.2, 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

Command

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

or

$ 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
dbms_service.disconnect_session(
  '<service_name>', DBMS_SERVICE.POST_TRANSACTION);

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.

Wednesday Apr 30, 2014

NEC Touts Oracle WebLogic Active GridLink for RAC Benefits

Japanese multinational, NEC corporation, plans on offering the unique Active GridLink for RAC, providing intelligent integration between Oracle WebLogic Server and Oracle Real Application Clusters (RAC), to customers for its higher performance, availability, and simplified operations. Check out Naoto Kashiwagi, Assistant Manager, NEC discuss Active GridLink benefits in great detail.

Friday Aug 09, 2013

Oracle and NEC Joint White Paper: WebLogic Server Active GridLink for Oracle RAC Testing Scenarios and Results

Oracle and NEC have been jointly invested on verifying and testing the Active GridLink for RAC solution implemented within Oracle WebLogic Server which gives the rich functionality for  Oracle Database Real Application Clusters integration.
The combination of Oracle WebLogic Server Data Source and Connection Pooling solutions and Oracle RAC provides a high-end mission-critical environment offering performance, high scalability and availability features. Load-balancing and Affinity capabilities offersignificant performance improvement for online transaction processing scenarios, as well as improving throughput and total response time. Failover solution gives end-to-end rapid failure detection supporting graceful shutdown for planned and unplanned Oracle RAC node outages.
In this paper, we start with a brief introduction to Oracle RAC and an overview of the Oracle RAC features supported in Oracle WebLogic Server 11g and 12c. We then focus on details of the effort that have been jointly done with Oracle and NEC with all the detailed testing scenarios and testing results, along with the analysis. The background and overview of NEC’s test of Active GridLink for RAC will be covered in details. The technical details about Runtime Connection Load Balancing, Web Session Affinity, Fast Connection Failover, and how to remove and add the additional RAC node with zero-downtime will be discussed with different use cases.


Download the white paper! And please share your comments
http://www.oracle.com/technetwork/middleware/weblogic/overview/activegridlinkwhitepaperoraclenec-1987937.pdf


Enjoy!

Wednesday Jul 17, 2013

WebLogic Active GridLink - An Oracle and NEC Joint White Paper

Oracle and NEC have been jointly invested on verifying and testing the Active GridLink for RAC solution implemented within Oracle WebLogic Server which gives the rich functionality for Oracle Database Real Application Clusters integration.

To learn about additional enhancements for Oracle WebLogic - Oracle Database integration, please join the Online Launch Event on July 31st.

In this published white paper, we started with a brief introduction to Oracle RAC and an overview of the Oracle RAC features supported in Oracle WebLogic Server 12c. We then focused on details of the effort that have been jointly done with Oracle and NEC with all the detailed testing scenarios and testing results, along with the analysis. The background and overview of NEC’s test of Active GridLink for RAC will be covered in details. The technical details about Runtime Connection Load Balancing, Web Session Affinity, Fast Connection Failover, and how to remove and add the additional RAC node with zero-downtime will be discussed with different use cases.

Check out this Japanese version paper:

http://www.nec.co.jp/middle/oracle/files/gc_wp-gridlink-gridcenter-nec.pdf

English version is coming soon, please check back later!

Friday Apr 19, 2013

Migrating from Multi Data Source to Active GridLink

Multi data source (MDS) for RAC connectivity has been supported in WebLogic Server since 2005.  As the popularity of Oracle RAC has grown, so has the use of MDS.  Now with the introduction of Active GridLink (AGL) in early 2011, users of MDS want to migrate to AGL.  There is not an automated mechanism to do so but it’s not the difficult.

First, no changes should be required to your applications.  A standard application looks up the MDS in JNDI and uses it to get connections.  By giving the AGL the same JNDI name as the MDS, the process is exactly the same in the application to use a data source name from JNDI.

The only changes necessary should be to your configuration.   AGL is composed of information from the MDS and the member generic data sources, combined into a single AGL descriptor.  The only additional information that is needed is the configuration of Oracle Notification Service (ONS) on the RAC cluster.  In many cases, the ONS information will consist of the same host names as used in the MDS and the only additional information is the port number, and that can be simplified by the use of a SCAN address.

The MDS descriptor doesn’t have much information in it.  It has a list of the member generic datasources, which will help you figure out where to get the remaining information that you need.  It has a JNDI name, which must become the name of your new AGL to keep things transparent to the application.  If you want to run the MDS in parallel with the AGL, then you will need to give the AGL a new name but the application must also be changed to use a new JNDI name.  You don’t need to worry about the algorithm type.

Each of the member generic datasources will have its own URL.  As described in Appendix B Using Multi Data Sources with Oracle RAC , it will look like the following.

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host1-vip)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=dbservice)(INSTANCE_NAME=inst1)))

Each member should have its own host and port pair.  They will likely have the same service and often have the same port on different hosts.  The URL for the AGL is a combination of the host and port pairs.

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=host1-vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=host2-vip)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=dbservice))

It is preferable to use an Oracle Single Client Access Name (SCAN) address instead of multiple host or Virtual IP (VIP) addresses.  Then the URL would look something like this.

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=scanaddress)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=dbservice))

It’s a lot simpler and makes changes to the nodes in the cluster transparent.  This section isn’t intended to be a complete guide to writing Oracle URL’s – see the Oracle RAC Administration Guide.

Assuming that you will replace the MDS with the AGL, you will need to delete the MDS and the generic data sources from the configuration using the administration console and add a single AGL data source.  The process is described earlier in this chapter.  Give it the same JNDI name as your MDS had.  Select whether your generic data sources used an XA or non-XA driver. You can enter the complete URL as described above.  The user and password should be the same as what you had on one (hopefully all) of the MDS members.  When you get to the “Test GridLink Datasource Connection” page, click on the “Test All Listeners” button to see that you specified the new URL correctly.  The next page is where you need the new information for the ONS connections.  Specify one or more host:port pairs. For example, “host1-vip:6200” or “scanaddress:6200”.  If possible, use a single SCAN address and port.  Make sure that FAN enabled is checked.  On the next page, test the ONS connections.  Finally, you are ready to deploy the data source.

There are many data source parameters that you can’t configure on the creation flow.  You need to go back and edit the AGL data source configuration.  The parameters that you set should generally be based on the parameters that you were using in the MDS member data sources.  Hopefully they were all the same; if not, you need to decide what the right values are.

Tuesday Feb 12, 2013

5 Reasons to Upgrade to WebLogic Webcast: Your Questions Answered

Do you need to optimize your middleware performance and manageability? Are you looking to consolidate your application infrastructure to a modern shared-services or cloud infrastructure? To answer these questions and more we hosted a live webcast with Mike Lehmann, Senior Director of Product Management for Oracle WebLogic Server and Oracle iAS recently.


The live webcast was a major success thanks to all of you who attended and participated. It generated great enthusiasm and many questions most of which we answered during the live session. However, by popular demand, we have enclosed a link below to the all of the questions and answers from the webcast.

Q&A from 5 Reasons to Upgrade to Oracle WebLogic Server

It’s not too late

If you missed the live webcast, don’t worry. You can view it on demand at:

5 Reasons to Upgrade to Oracle WebLogic Server on demand

Listen to Mike discuss iAS to WebLogic upgrade paths, tools, and best practices for various data center configurations and highlight the benefits of upgrading to WebLogic and describes some of its rich capabilities including:

  • Lightweight, Modern Development Experience
  • High Density, High Performance Virtualization
  • Complete Visibility, Diagnosibility and Management of WebLogic and iAS


For more information, follow WebLogic on:
Twitter: @OracleWebLogic
LinkedIn: http://www.linkd.in/oracle_weblogic
Facebook: https://www.facebook.com/oracleweblogic
YouTube: www.youtube.com/oracleweblogic


Friday Feb 08, 2013

Deltek Highlights Smooth Upgrade to WebLogic, Plus Cool New Features

Listen to Dmitri Tyles, Senior Director of Development at Deltek -- a global provider of enterprise software and information solutions for project-oriented businesses -- discuss their reasons for upgrading to WebLogic 12c and their experience with the upgrade process. Deltek has about 14,000-plus customers and 1.8 million users Dmitri Tyles, Senior Director of Development at Deltek -- a global provider of enterprise software and information solutions for project-oriented businesses -- discuss their reasons for upgrading to WebLogic 12c and their experience with the upgrade process. Deltek has about 14,000-plus customers and 1.8 million users around the world in 80 countries. Needless to say the stakes are high. They were able to upgrade "Costpoint" with 1,500 applications to WebLogic 12c in about six weeks. They did run into a couple defects along the way which were reported to Oracle and fixes received pretty quickly. The rest of the upgrade was pretty smooth, Dmitri says. He goes on to talk about a particular feature which was really key for Deltek -- the support Oracle RAC. WebLogic always supported Oracle RAC, Dmitri claims, but the previous solution required a fair amount of manual maintenance from a WebLogic administrator. So for example, if a RAC administrator on a database side would add another node to the cluster, a WebLogic administrator would have to go in and manually update the same settings on WebLogic Server and add this node and register it. With the Active GridLink solution that Oracle has included in WebLogic, this is no longer necessary. So WebLogic is completely aware of all the changes happening to the RAC and, as such, all this ongoing maintenance is completely eliminated. 

Friday Feb 06, 2009

Oracle WebLogic Server 10.3 and Oracle RAC

In last few months, more and more questions have come up about how to configure Oracle WebLogic Server to work with Oracle RAC. Oracle RAC 11 was released with enhanced features and some new support. Of interest, the release addresses the known XA limitations associated with the previous releases. Some of you have asked if it’s possible to make Oracle WegLogic Server 10.3 to work with Oracle RAC 11g.

We have created a sample and included all the detailed configuration and testing steps in a How-To here:

http://www.oracle.com/technetwork/middleware/weblogic/index-086651.html

Hopefully this will give you a good start and you will be able to do this your own following the configuration samples provided here.

Also, check out the white paper, which gives an overview of Oracle RAC, Oracle WebLogic Server and the details of Oracle RAC support configuration options in Oracle WebLogic Server JDBC multi data sources:

http://www.oracle.com/technetwork/middleware/weblogic/oraclewls-rac-1-131306.pdf

[Read More]
About

The official blog for Oracle WebLogic Server fans and followers!

Stay Connected

Search

Archives
« June 2016
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
22
23
24
25
26
27
30
  
       
Today