weblogic多池与oracle集群RAC

http://www.techpaste.com/2013/04/soa-infra-start-fails-weblogic-common-resourceexception-good-connections-error-weblogic/

After installing SOA 11g, but the soa-infra component fails to start.

The following error message shows up in the soa diagnostics.log file:

oracle.mds.lcm.exception.MDSLCMException: MDS-00922: The ConnectionManager "oracle.mds.internal.persistence.db.JNDIConnectionManagerImpl" cannot be instantiated.
weblogic.common.ResourceException: No good connections available.

This exception means that the application is using a MultiPool DataSource to get JDBC connections, and all the pools defined for that MultiPool are currently unable to deliver a connection for the application to use.

Here the SOA server is unable to establish a connection to the database.

It might show that the existing data sources status will be fine.
However, they do not have the SOA server as a target. Usually the issue
will be the mds-soa data source.

The list of data sources used by applications deployed to WebLogic
Server can be viewed by either connecting to the Weblogic console and
navigating to Services -> JDBC -> Data Sources or in the
$MW_HOME/user_projects/domains/soa_domain/config/config.xml file.

Weblogic soa mds datasource

For each data source there is a separate configuration file located
in the $MW_HOME/user_projects/domains/soa_domain/config/jdbc folder.

Add the SOA server as a target to existing data sources using the WebLogic console and do a bounce to solve the issue.

###############################################################

　　　　　　　　http://www.blogjava.net/jhx800/archive/2011/03/23/261052.html

转自 兔八哥，配置ORACLE的RAC的数据源，WEBLOGIC的多池MULTI-POOL

WebLogic里面有多池的概念,其中High
availability的含义是这样的,假设有PoolA和PoolB,正常的情况下,只有一个PoolA起作用,其poolB是stand-by,当起作用的那个poolA出现故障,则会被WLS标记为disable,并将请求转发到另外一个poolB上,并且定时测试被标记为disable的poolA,如果重新连接成功后,则将请求再切换回PoolA上,PoolB继续stand-by.

而上周和一个客户讨论这个问题,客户的做法是这样的:

后台是Oracle的RAC数据库,他配置了一个多池,有2个Pool,PoolA主要连RAC的A实例,PoolB主要连RAC的B实例.其实他的PoolA和PoolB都是用了RAC格式的JDBC的写法,后面是一个主机列表,PoolA将A实例的IP写在了前面,PoolB将B实例的IP写在了前面,JDBC的算法是failover=yes

load_banlance=no,这样每一个Pool将请求都发送到自己的第一个host的Oracle的实例上,在第一个host的Oracle实例出现故障时候切换到另外一个host的Oracle实例上.

PoolA和PoolB的JDBC的写法如下,注意failover=yes和load_banlance=yes,这样写的作用是当请求来的时候都转发给第一个host,只有出现第一个host有问题,才会将请求发送到第二个host:

WLS JDBC URL 的配置如下：

jdbc:oracle:thin:@(description=(address_list=
(address=(host=172.18.137.231)
(protocol=tcp)(port=1521))(address=(host=172.18.137.230)(protocol=tcp)
(port=1521))
(load_balance=yes)(failover=yes))(connect_data=(service_name=
slrac.bea.com)))

配置的多池的算法如果是High Availability的话,那么压力将始终压到一个Pool上面,另外一个Pool处于stand-by的状态,除非处理请求的Pool出现故障.客户的监控情况也是如此,发现压力都压在了一个Oracle的实例上.

如果多池的算法是Load Banlance的话,那么压力将平均分配到2个Pool上面.如果想使用多池的high availability的算法,则不要设置test的重试次数,如果设置了,则会出错抛出异常.

为了能使被标记为disable的PoolA能够恢复正常的连接,则需要设置HealthCheckFrequencySeconds的值在config.xml里面,该值在console上面没有.

另外还要能够使用TestConnectionsOnReserve.

多池就是在JDBC的连接池上层又加了一层请求分流的算法层.

关于Orale的RAC的JDBC的配置请参见我的另一篇笔记:

http://rabbit8.bokee.com/4962735.html

以上是我的理解,如有错误,请指正,因为你的指正将会让我理解更深刻,谢谢!

本文参考了http://www.bea.com.cn/support_pattern/Investigating_JDBC_MultiPool_Issues_Pattern.html

当安装完了Oracle的RAC后，我的Oracle就是一个双机的集群了，支持load banlance 和failover，但是数据源里面的JDBC的URL需要一种不同的格式：

1)BEA的例子：http://www.bea.com.cn/support_pattern/Oracle_RAC_Pattern.html

WLS JDBC URL 的配置如下：

jdbc:oracle:thin:@(description=(address_list=
(address=(host=172.18.137.231)
(protocol=tcp)(port=1521))(address=(host=172.18.137.230)(protocol=tcp)
(port=1521))
(load_balance=yes)(failover=yes))(connect_data=(service_name=
slrac.bea.com)))

2)IBM 的例子：http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp?topic=/com.ibm.wp.ent.doc/wpf/plan_oracle_rac.html

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=PRIMARY_NODE_HOSTNAME)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=SECONDARY_NODE_HOSTNAME)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=DATABASE_SERVICENAME)))

我的试验的配置：

jdbc:oracle:thin:@(description=(address_list= (address=(host=p570_b)
(protocol=tcp)(port=1521))(address=(host=p570_a)(protocol=tcp)
(port=1521))
(load_balance=yes)(failover=yes))(connect_data=(service_name= orcl)))

我一开始使用的是IP地址，但发现使用IP后，第一下测试连接成功，第二下失败，第三下成功，第四下失败，就是这个规律，原因是RAC自己就有负载均衡的功能(load

banlance)，它会自动的分配负载(workload)，而第二次的请求据说返回的不是IP，所以在我的IP的列表里面没有，自然找不到(这是另一个工程师解释给我的，不过我不太相信，因为BEA的文档中使用的就是IP，但我又不知道为什么)。

后来听从那个工程师建议改成主机名后，一切OK，但如果改主机名需要更改Windows下的WINNT/system32/drivers/etc/hosts文件，将主机名和IP对应起来。

我的RAC的数据源的配置就OK了，51后还要做DB2的双机互备的集群，还不知道该怎么做，DataSource的JDBC的URL怎么配置呢，不知道是不是和这个一样呢？

TNS的配置：

你的TNS的名字=
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = p570a)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = p570b)(PORT = 1521))
    )
    (load_blance=yes)
    (CONNECT_DATA =
      (SERVICE_NAME = orcl)
      (failover_mode=
              (type=select)
              (method=basic))
    )
  )

明天上午验收安装的AIX的HA和RAC，如果顺利的话，下午就可以回北京了，这次安装AIX和RAC都不顺利，那个安装RAC的工程师这2天被蹂躏够戗，不断的出现新的问题，一开始AIX的版本的补丁不对，结果IBM的那个工程师早早的跑了，后来找到了原因，后来又是安装Oracle的Cluster层的软件有一个NODE没有启动，后来知道了那个NODE是否正常启动没有关系，今天又是建立RAW和导入数据出现了些问题，还好都搞定了，晚上我又测试了一下集群的数据源，明天希望上午可以正式的测试完毕。

http://allenwbl.wordpress.com/2009/12/14/%E5%85%B3%E4%BA%8Eoracle-rac%E5%92%8Cweblogic-multi-data-source%E4%BD%BF%E7%94%A8%E7%9A%84%E9%97%AE%E9%A2%98%E8%AF%B4%E6%98%8E/

今天的Presentation遇到的问题，我查了下，分享下结果。

一.  Oracle RAC Load Balancing with WebLogic Server

 

1. 在Weblogic上配置了一个多池，利用Weblogic提供的负载均衡策略，将并发均衡的分别到两个节点上.

方法：就是在Weblogic里面配置两个Data Source，每个Data Source分别配置一个Connection
Pool, 并将对应的Connection Pool的JDBC URL指向RAC的对应节点，然后这两个Data
Source进一步组成Multi Data Sources.  如下图：

 

If your application requires load balancing across RAC
nodes, WebLogic Server supports this capability through use of JDBC
multi data sources with Oracle RAC nodes. The data sources that form a
multi data source are accessed using a round-robin scheme. When
switching connections, WebLogic Server selects a connection from the
next data source in the order listed.

 

缺点：测试发现，一旦运行了一段时间，所有的压力都会“粘到”一个节点上，而另一个节点上机会没有任何的压力。

 

2. 直接使用了RAC的负载均衡策略.

这种方式实际上绕过了Weblogic的负载均衡机制，而直接使用了RAC的负载均衡策略
 

在Oracle RAC中找到tnsnames.ora这个文件。

在配置Weblogic的Data Source(不是多池)时，将其JDBC的URL修改为如下： 

jdbc:oracle:thin:@(description=(ADDRESS_LIST =(ADDRESS =
(PROTOCOL = TCP)(HOST = VIP1)(PORT = 1521))(ADDRESS = (PROTOCOL =
TCP)(HOST = VIP2)(PORT =
1521))(load_balance=on)(failover=on))(connect_data=(service_name=
racdb)(instance_name=racdb1)(instance_name=racdb2)))

文字为红色的部分很重要。在没有加入之前，测试连接有时成功有时失败。原因不明。

 

优点：两个节点的负载差别很小， 不会产生所有的压力都会“粘到”一个节点上，而另一个节点上机会没有任何的压力这样的情况。

 

 

 

二。同一个transaction在load blanance的时候是会跨RAC节点运行的，而不是今天说的不能跨节点。

In a configuration without a multi data source, WebLogic
Server relies on the connect-time failover feature provided by the
Oracle Thin driver to work with Oracle RAC. As described in
Oracle’s Technical Note 235118.1, the Oracle Thin driver cannot
guarantee that a transaction is initiated and concluded on the same
Oracle RAC instance when the driver is configured for load balancing.

 

参考资料：

http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jdbc_admin/oracle_rac.html#wp1080305

http://www.oracle.com/technology/products/weblogic/howto/rac/index.html

#####################################

http://blog.csdn.net/steelren/article/details/8453501

介绍

为了使用户的应用系统符合成本效益，高可用性和可扩展性通常是各类不同的系统所关心的问题。在包括Java
EE中间层和后台数据库的异构复杂环境汇总，有很多已知的问题。比如，一个应用请求可能会在数据库节点当机的时候被阻塞很长的时间。通常不会有什么简单的方法来判断在捕获到一个SQLException的时候，是否需要获取一个新的数据库连接。中间层应用不会知道有一个新的数据库节点或者数据库节点重新启动或者数据库节点运行的缓慢、挂起甚至已经当机，通常它们只会等待TCP/IP通讯的超时。

Oracle WebLogic Server 11g为Oracle Database 11g的RAC(Real
Application
Cluster)特性提供强大的支持，最大限度的减少数据库的访问时间，同时允许对丰富的连接池管理功能的透明访问，最大限度的提高数据库连接池的性能和有效性。

Oracle WebLogic Server 11g
RAC集成解决方案已经由Oracle融合中间件和数据库团队联合设计实施，并完成测试。它不仅是市场上最好的高可用性解决方案，而且WebLogic
Server也是唯一一个通过Oracle Database RAC 11g认证的应用服务器，通过WebLogic
Server能够进行完整集成而不损失任何Java EE功能,包括安全，事务，连接池等等的管理。

在Oracle WebLogic
Server中有两种数据源能够支持Oracle RAC：多路数据源是从WebLogic Server 8.1
SP5发布后就在用户的生产部署环境中成功应用的解决方案；Oracle WebLogic 11gR1(10.3.4)开始增加的被称作Oracle
WebLogic Active GridLind for RAC的新的解决方案，该解决方案是业内领先的中间层集成解决方案，充分利用了Oracle
RAC的优势。Oracle WebLogic Server Active GridLink for
RAC是由Oracle推荐的支持Oracle RAC的战略性解决方案。它能够提供其他供应商产品所不具备的最佳的中间件与数据库集成的特性。

Oracle WebLogic Server数据源、数据库连接池解决方案和Oracle
RAC的结合为用户提供了一个具有高性能、高可扩展性和高可用性特性的高端的任务关键型环境。负载均衡(Load-balancing)和关联(Affinity)为在线交易处理提供显著的性能提升，并提高吞吐量和总体响应时间。失效备援(Failover)为Oracle
RAC节点的计划和非计划运行中断通过端到端的快速失效监测，来支持数据库的优雅关闭(Graceful Shutdown)。

在本文中，我们首先对Oracle RAC做一个简单的介绍，并对Oracle WebLogic Server
11g所支持的Oracle RAC特性进行整体描述。然后我们将关注WebLogic Active GridLink for
RAC的详细特性和配置选项，以及样例。所有的配置步骤和应用样例将在本文中相应的“How-To”链接中进行介绍。

在每一个特性中，对于多路数据源和Active GridLink for RAC的不同支持功能都将进行清晰的解释。

ORACLE REAL APPLICATION CLUSTERS (Oracle RAC)

Oracle RAC帮助用户建立Oracle数据库集群。单实例Oracle数据库在Oracle数据库和实例之间是一对一的关系。Oracle RAC环境在数据库和实例之间是一对多的关系。

下图展示了Oracle RAC如何通过多个服务器提供的单一系统映像，访问一个Oracle数据库的。在Oracle RAC中，每一个Oracle实例通常都运行在不同的服务器之上。

Oracle RAC 11gR2的新特性

Oracle RAC 11gR2的新特性包括：

• l  Oracle RAC单节点：为单实例数据库提供增强的高可用性，在计划或者非计划关机中，对数据库实例进行保护。
• l  单一客户端访问名称(SCAN)：Oracle Database 11g数据库客户端使用SCAN连接数据库，SCAN能够解析多个IP地址，对集群中的多个监听器进行反射，处理客户端的连接。
• l  基于版本的重定义：能够使用SRVCTL为一个数据库服务设置一个版本属性，之后所有指定该服务的连接都以此版本作为会话的最初版本。
• l  在企业管理器(Enterprise Manager)中增强对Oracle RAC的监控和诊断。
• l  增强Oracle RAC Configuration Assistant的功能。
• l  增强SRVCTL对网格基础架构管理(Grid Infrastructure Management)的功能。
• l  OCI运行时连接负载均衡：支持在多个数据库实例上并行执行的流程，支持跨越分布式事务和Oracle数据库服务质量管理服务器。

Oracle WebLogic Server 11g和Oracle 11g
RAC的集成经过充分的验证，提供高可靠性，高可扩展性和高性能。Oracle
RAC服务，比如失效备援、运行时连接负载均衡、关联等特性，都能够通过Oracle WebLogic Server的JDBC数据源和连接池实现。

Oracle WebLogic Server与RAC

在Java EE应用服务器中，数据库交互通常都是由数据源实现的。用户可以配置和暴露一个数据库连接作为JDBC数据源。

在Oracle WebLogic Server中有两种数据源能够支持Oracle
RAC：多路数据源是从WebLogic Server 8.1 SP5发布后就在用户的生产部署环境中成功应用的解决方案；Oracle
WebLogic 11gR1(10.3.4)开始增加的被称作Oracle WebLogic Active GridLink for
RAC的新的解决方案，该解决方案是业内领先的中间层集成解决方案，充分利用了Oracle RAC的优势。

多路数据源

WebLogic Server JDBC子系统从WLS 8.1 SP5开始支持Oracle
RAC,最初为Oracle 9i
RAC所开发。该技术基于特殊的数据源配置类型，叫做多路数据源。该数据源是对一个或多个独立数据源的抽象。它为每一个成员数据源的JDBC连接提供一个特定的策略。一个RAC
多路数据源配置需要每一个成员数据源包含一个对特定RAC实例的连接，在下图中展示了一个三个节点的RAC集群的配置。

功能

WebLogic RAC 多路数据源配置提供了如下功能：

负载均衡、失效备援和XA关联。

负载均衡

当多路数据源算法被设置了负载均衡，应用连接以循环方式保存对每一个成员数据源起作用的请求。这与失效备援相比，提升了对集群资源的使用率，并且也能够支持XA数据源。

失效备援

多路数据源失效备援算法使应用连接借用一个成员数据源中的请求，直到该成员不在有效。失效备援能够在数据库连接池容量耗尽的时候发生。失效备援策略通常使用主动-被动架构。

XA关联和失效备援

当在一个全局事务中进行数据库访问时，JDBC连接中获得的成员数据源将关联到全局事务的生命周期当中。这能保证所有的数据库操作能够在从多路数据源中获得连接上进行执行，对于特定的事务，所有的执行都在相同的RAC实例上进行。XA关联能够提升性能，甚至是更旧版本RAC的需求，比如11g之前的版本。XA失效备援也能够被多路数据源和事务管理实现支持。如果关联的RAC实例出现失败，那么一个全局事务可以使用从另一个成员数据源中获得连接使用不同的RAC实例来完成。

局限性

Oracle 多路数据源是一个纯中间层实现，但是并不能支持Oracle
RAC的一些特性，比如Oracle通知服务(Oracle Notification Service, ONS)。因此，Oracle
多路数据源不能立即知道后台数据库发生的事情，并有如下一些局限性：

配置复杂性

WebLogic 多路数据源需要n+1个JDBC模块，n是RAC集群中节点的数量。对RAC服务的配置，一个单独的多路数据源需要为每一个RAC节点服务都进行数据源配置。此外，配置本身是静态的，在RAC集群的拓扑结构发生变化是，需要管理介入来增加或移除数据源。

连接池

多路数据源使用连接池机制来检测每一个JDBC连接的有效性和RAC集群拓扑结构的变化。这种机制是对后台通知服务的替代机制。虽然有效，在独立的连接上执行SQL操作时会产生额外的开销，并且在检测RAC节点失败时可能会产生延迟。此外，还存在可能的误报，导致数据源池不必要的废弃，终止正在被应用使用的有效连接。

负载均衡算法

WebLogic多路数据源采用循环式负载均衡实现跨越多个成员数据源的分布式均衡工作。在RAC实例表现出不同的性能和响应时间特征，更希望进行细粒度控制。

每个MDS的XA关联

每一个多路数据源都提供XA关联。当多个多路数据源参与到一个全局事务当中，有可能从不同的RAC实例中获取连接。这就导致相同的全局事务的分支被不同的RAC实例处理。尽管在最近的RAC版本中，从性能角度看，它并不是最佳的。

Active GridLink for RAC

Oracle WebLogic Server 10.3.4引进了一种单数据源实现来支持Oracle
RAC集群。它对FAN事件进行响应来提供快速连接故障转移(Fast Connection Failover,
FCF)，运行时连接负载均衡(RCLB)和RAC实例优雅停机。在全局事务ID级别支持XA关联。这个新的特性叫做WebLogic Active
GridLink for RAC，在WebLogic
Server中叫做GridLink数据源。GridLink数据源通过应用通用连接池(Universal Connection Pool,
UCP)的RAC集成能力来提供FCF，RCLB和关联特性。

通过关键基础来提供与Oracle RAC的深度集成，这个Oracle WebLogic
Server中的单数据源实现，对于作为数据源连接目标的数据服务支持完整且无限制的应用。对于池中按连接的动态管理基于连接池本身的动态设置和连接池从RAC通知服务中获得的实时信息，Oracle通知服务(Oracle
Notification Service，ONS)子系统能够向客户端通知RAC集群中的任何状态变换。

通用连接池的Java库集成在WebLogic Server中，并且被WebLogic GridLink数据源使用，来提供快速连接故障转移，运行时连接负载均衡和关联特性。

Oracle数据库服务是Oracle数据库中工作量管理的逻辑抽象。服务将工作量分解成逻辑独立的组，每一个服务代表一部分带有通用属性、服务级别阈值和优先级的工作量。服务在数据库中建立，提供了一个单独的工作量系统映像，工作量优先次序，真实事务的性能测量和在性能指标没有达到时的警报和行动。服务使数据库管理员能够配置一个工作量，对它进行管理，对它进行启用或者禁止，并作为一个独立的实体测量工作量。

GridLink数据源与连接池关联，连接池包含一组隐藏在数据服务后面的，连接到RAC实例的异构连接。当一个应用从数据源中请求一个连接，根据连接池收到的负载均衡信息和池中连接使用的分布情况，一个合适的连接从池中借用并且提供给应用。

通过GridLink数据源方式，简化了Oracle RAC数据库与WLS的结合应用，降低了使用Oracle
RAC的配置与管理复杂度。要注意的是，对于RAC环境的多路数据源将会被继续支持。将RAC多路数据源升级到GridLink数据源能够迅速实现，只需创建一个单独的与多路数据源的JNDI名称相同的GridLink数据源，这样能够减少人工维护的配置数量。

快速连接故障转移

快速连接故障转移特性是通过通用连接池实现的快速应用通知(Fast Application
Notification, FAN)的客户端实现。该特性需要使用到一个Oracle JDBC驱动和Oracle
RAC数据库或者使用一个单实例的Oracle数据库重启。

WebLogic GridLink数据源已经在通用连接池与FCF进行了集成，并将FCF用于：

• l  提供快速的失败检测
• l  快速从连接池中终止和移除无效的连接
• l  对计划或者非计划的Oracle RAC节点中断进行优雅停机
• l  适配拓扑结构的变化，比如节点的增加与移除
• l  将运行时工作请求分布到所有活动的Oracle RAC实例，包括哪些重新加入的集群

Oracle
RAC数据库使用ONS广播状态变化的事件。GridLink数据源能够从注册来接收从ONS发送的通知，因此能够快速感觉到RAC数据库中的任何状态变化。使用这些状态变化通知，GridLink数据源能够对连接池进行智能适配，以此在RAC数据库发生变化时，还能够提供持续，可靠和高效访问。

对RAC集群状态变化适合的响应允许WebLogic
Server通过立即撤销、关闭和丢弃与因为非计划中断被停止或者去掉Oracle实例的连接来处理中断，而不需要定期的轮询连接来确保他们有效，或者影响到让然存在节点的无关连接。这种评估需要对连接进行测试，来保证没有将死连接提供给应用并且快速将RAC节点失败的死链接移除，在一些失败的情况下，这些失败可能会挂起几分钟。

更进一步，它允许WebLogic
Server在新的RAC实例被增加或者在中断后重启时，主动对连接进行重新分配。这就使WLS能够对RAC数据库中的资源进行完全的利用。此外，使用数据库服务模型能够使数据库管理员对RAC服务/实例的配置进行变更，通过影响WLS连接池，无需改变连接池的配置，就能够进行平滑的应用。它也不需要像多路数据源那样创建复杂的准备，来表示RAC数据库的专用实例。

WebLogic
GridLink数据源提供快速连接故障转移功能和对RAC数据库服务与节点事件(启，停)的响应来确保连接池中保存的物理连接都指向有效的数据库节点，并确保这些保存的物理连接都很好的分布在这些有效的数据库节点上。快速连接故障转移行为是作为GridLink数据源的一个配置。

快速连接故障转移功能启用，能够支持如下场景：

• l  计划内停机事件——计划内中断作为数据库维护或者其他的活动，需要在一个已经确定的时间点执行。当Oracle

  RAC服务能够进行优雅停机，那对于这些事件的支持就是有效的。在这类场景中，任何借用或者正在使用的连接都不会被中断或者关闭，直到工作完成，对连接的控制返回给连接池为止。这为大型的异构客户环境进行计划中断管理提供了一种非常有效的方式。

• l  计划外停机事件——对计划外中断的支持通过检测和移除对Oracle
  RAC集群的陈旧连接来实现。陈旧连接包括一位服务停机或者节点停机造成的对Oracle
  RAC集群的任何节点都不在有效的连接服务。陈旧的借用的连接和有效的连接是能够探测的，他们的网络连接在从连接池移除之前是能够提供服务的。这些移除的连接并不会被连接池取代。相反，应用必须在使用连接执行工作之前进行重试连接。
• 对于非计划停机和计划内停机的主要区别是如何处理借用的连接。陈旧的连接在连接池中是空闲的(不是借用的)，在非计划关机场景中，陈旧连接以同样的方式被移除。
• l  启动事件——Oracle RAC实例重新加入和新增加实例场景——在一个Oracle
  RAC集群增加实例，提供一个新的感兴趣的服务使能够支持的。这个实例可能是集群中心的实例，或者可能是重新启动了一个已经停机的实例。在这两种场景中，WebLogic的JDBC连接池识别新的实例并对节点创建必要的连接。

运行时连接负载均衡

WebLogic GridLink数据源和JDBC连接池利用Oracle RAC数据库提供的负载均衡功能，提供更好的吞吐量和更高效的资源使用。运行时连接负载均衡需要使用Oracle JDBC驱动和Oracle RAC数据库。

Oracle性能分析显示，相对静态的轮询算法，使用运行时负载均衡有巨大的性能提升。即使RAC集群中的节点通过硬件进行了均衡，并且集群中的节点上的平均负载是复合预期的，合理而且均匀，那这种性能的提升也是很明显的。负载的瞬时差异特性通常足够使运行时连接负载均衡成为RAC集群的最佳负载均衡机制。

负载均衡公告服务发布FAN事件，向客户端通知集群的当前状态，包括建议哪里能够直接进行连接。WebLogic Server连接池接收由数据库发布的负载均衡通告事件，如下图所示将连接分布到RAC的节点之上。

使用运行时负载均衡有如下好处：

• l  针对高性能和高可扩展性的连接池管理
• l  持续的接收工作量百分比的建议，来进行数据库实例的路由
• l  根据后台节点的性能差异，比如CPU性能或者响应时间，进行工作量分布的调整
• l  对集群配置，应用负载，节点过载或者挂起的等变化进行快速的响应
• l  接收Oracle RAC负载均衡通告指标。与性能最好的实例的连接是最常用的。随着时间的推移，会逐渐的远离连接到性能不佳的实例的新的和不在使用的连接。当没有达到分布指标时，会随机选择连接。

连接关联(Affinity)

WebLogic GridLink数据源利用Oracle RAC数据库提供的关联功能。连接关联需要使用到Oracle JDBC驱动和11.1.0.6或更高版本的Oracle RAC数据库。

连接关联能够让连接池选择直接连接到一个特定Oracle RAC实例的连接，为客户端应用提供最好的性能。连接池使用运行时连接负载均衡来选择一个Oracle RAC实例，创建第一个连接，然后会在相同的实例上创建带有关联的连接。

WebLogic GridLink数据源支持基于事务的关联。

基于事务的关联

基于事务的关联是既能够被客户端应用，也能被失败事件释放的与Oracle
RAC实例的关联。典型的，当需要一个长时间使用的与Oracle RAC实例的关联，或者重定向到一个新的Oracle
RAC实例的成本(性能方面)比较高的时候，应用系统使用这种类型的关联。参与到分布式事务中的WebLogic XA连接保持与Oracle
RAC实例的关联，用于对事务进行持久化。在这种情况下，如果在分布式事务当中，一个连接重定向到不同的Oracle
RAC实例，应用系统可能会承担比较高的系能成本。

关联将基于全局事务ID建立，而不是独立的数据源，以保证连接包括不同的数据源，这些数据源被配置到相同的RAC集群，丙炔与相同的RAC实例关联。LLR两阶段提交优化会被RAC数据源所支持，并且也参与到XA关联当中。

　　　　http://wenku.baidu.com/view/f4425714866fb84ae45c8d3e.html

　　　　

　　　　

配置Oracle的RAC的数据源 
                                        
      当安装完了Oracle的RAC后，我的Oracle就是一个双机的集群了，支持load banlance 和failover，但是数据源里面的JDBC的URL需要一种不同的格式： 
1)BEA的例子：http://www.bea.com.cn/support_pattern/Oracle_RAC_Pattern.html WLS JDBC URL 的配置如下： 
jdbc:oracle:thin:@(description=(address_list= (address=(host=172.18.137.231) (protocol=tcp)(port=1521))(address=(host=172.18.137.230)(protocol=tcp) (port=1521)) (load_balance=yes)(failover=yes))(connect_data=(service_name= slrac.bea.com))) 
2)IBM 的例子：http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp?topic=/com.ibm.wp.ent.doc/wpf/plan_oracle_rac.html 
 jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=PRIMARY_NODE_HOSTNAME)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=SECONDARY_NODE_HOSTNAME)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=DATABASE_SERVICENAME)))  
我的试验的配置： 
jdbc:oracle:thin:@(description=(address_list= (address=(host=p570_b) (protocol=tcp)(port=1521))(address=(host=p570_a)(protocol=tcp) (port=1521)) (load_balance=yes)(failover=yes))(connect_data=(service_name= orcl))) 
      我一开始使用的是IP地址，但发现使用IP后，第一下测试连接成功，第二下失败，第三下成功，第四下失败，就是这个规律，原因是RAC自己就有负载均衡的功能(load banlance)，它会自动的分配负载(workload)，而第二次的请求据说返回的不是IP，所以在我的IP的列表里面没有，自然找不到(这是另一个工程师解释给我的，不过我不太相信，因为BEA的文档中使用的就是IP，但我又不知道为什么)。

后来听从那个工程师建议改成主机名后，一切OK，但如果改主机名需要更改Windows下的WINNT/system32/drivers/etc/hosts文件，将主机名和IP对应起来。 
      我的RAC的数据源的配置就OK了，51后还要做DB2的双机互备的集群，还不知道该怎么做，DataSource的JDBC的URL怎么配置呢，不知道是不是和这个一样呢？ 
     TNS的配置： 你的TNS的名字=   (DESCRIPTION =     (ADDRESS_LIST = 
      (ADDRESS = (PROTOCOL = TCP)(HOST = p570a)(PORT = 1521))       (ADDRESS = (PROTOCOL = TCP)(HOST = p570b)(PORT = 1521))     ) 
    (load_blance=yes)     (CONNECT_DATA =       (SERVICE_NAME = orcl)       (failover_mode=               (type=select)               (method=basic))     )   ) 
后台是Oracle的RAC数据库,他配置了一个多池,有2个Pool,PoolA主要连RAC的A实例,PoolB主要连RAC的B实例.其实他的PoolA和PoolB都是用了RAC格式的JDBC的写法,后面是一个主机列表,PoolA将A实例的IP写在了前面,PoolB将B实例的IP写在了前面,JDBC的算法是failover=yes load_banlance=no,这样每一个Pool将请求都发送到自己的第一个host的Oracle的实例上,在第一个host的Oracle实例出现故障时候切换到另外一个host的Oracle实例上. PoolA和PoolB的JDBC的写法如下,注意failover=yes和load_banlance=yes,这样写的作用是当请求来的时候都转发给第一个host,只有出现第一个host有问题,才会将请求发送到第二个host: WLS JDBC URL 的配置如下：

jdbc:oracle:thin:@(description=(address_list= (address=(host=172.18.137.231) 
(protocol=tcp)(port=1521))(address=(host=172.18.137.230)(protocol=tcp) (port=1521)) 
(load_balance=yes)(failover=yes))(connect_data=(service_name= slrac.bea.com)))  
配置的多池的算法如果是High Availability的话,那么压力将始终压到一个Pool上面,另外一个Pool处于stand-by的状态,除非处理请求的Pool出现故障.客户的监控情况也是如此,发现压力都压在了一个Oracle的实例上. 
如果多池的算法是Load Banlance的话,那么压力将平均分配到2个Pool上面.如果想使用多池的high availability的算法,则不要设置test的重试次数,如果设置了,则会出错抛出异常. 
为了能使被标记为disable的PoolA能够恢复正常的连接,则需要设置
HealthCheckFrequencySeconds的值在 config.xml里面,该值在console上面没有. 
另外还要能够使用TestConnectionsOnReserve.  多池就是在JDBC的连接池上层又加了一层请求分流的算法层.