Oracle RAC客户端连接不稳定的解决方法
Oracle RAC安装完毕后，监听、a按照Oracle默认配置好后，在服务器端用sqlplus连接没有问题，但是用客户端连接，会出现有时候连不上的错误，解决方法：
1、修改监听文件，增加SID_LIST_LISTENER，两台机器都要修改，修改完毕后如下：
LISTENER_ORCL1 =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.1)(PORT = 1521))
)
)
)
SID_LIST_LISTENER_ORCL1 =
(SID_LIST =
(SID_DESC =
(ORACLE_HOME = /u01/app/oracle/product/11.1.0)
(SID_NAME = ora1)
)
)
2、修改a，两台机器都要修改，例如第一台机器：
用Oracle的netca配置的时候，只配置了一个监听LISTENERS_ORCL，手工增加另外两个监听。
LISTENER_ORCL2 =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.2)(PORT = 1521))
)
LISTENER_ORCL1 =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.1)(PORT = 1521))
)
LISTENERS_ORCL =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.2)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.1)(PORT = 1521))
)
ORCL1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.1)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = ORCL)
)
)
ORCL2 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.2)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = ORCL)
)
)
ORCL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.1)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.2)(PORT = 1521))
(LOAD_BALANCE = yes)
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ORCL)
)
)
3、修改pfile，将两个本地监听设置上。
可以先导出一份spfile，修改完毕后再导入pfile。增加以下三行：
*.local_listener='LISTENER_ORCL'
ora1.local_listener='LISTENER_ORCL1'
ora2.local_listener='LISTENER_ORCL2'
另 外，在启动oralce时，出现ora-32006的错误，数据库倒是起来能用。到网上搜索一通，说是oracle10g以后 将*.log_archive_start=TRUE 这个参数去掉了，把这行从spfile中删除了，再启动没有报错。是否真的不需要这个参数，还需要再确认。
4、oracle驱动
经测试发现，在oracle RAC环境下，如果down掉一个实例，应用出现以下错误：
Io 异常: Software caused connection abort: socket write error
ProcessingException: error on execute servlet:login: javax.servlet.ServletException: error on execute servlet:login
cause: java.sql.SQLException: Io 异常: Software caused connection abort: socket write error
经反复测试，确定原因是oracle的驱动ojdbc14.jar
没有放到WEB-INF/lib下的原因。此启动在公共lib下，必须COPY到当前工程下，才能实现fail-over的自动切换.
5、测试jdbc连接的程序：
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.Properties;
public class RacTest {
/**
* 测试RAC
*
* @param args
* @throws ClassNotFoundException
*/
public static void main(String[] args) throws ClassNotFoundException {
String url;
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
Properties conProps = new Properties();
conProps.put("user", "sys");
conProps.put("password", "XXXX");
conProps.put("internal_logon", "sysdba");
url = "jdbc:oracle:thin:@(description= (ADDRESS_LIST =";
url += "(address=(protocol=tcp)(host=192.168.0.1)(port=1521))"; // 服务器IP
url += "(address=(protocol=tcp)(host=192.168.0.2)(port=1521))";
url += "(load_balance=yes))"; // 是否负载均衡
url += "(connect_data =";
url += "(server = dedicated)";// 专用服务器模式 可以去掉？
url += "(service_name=orcl)"; // 服务名
//url += "(failover_mode =";
//url += "(type=session)";
/
/url += "(method=preconnect)";
//url += "(retries=5)";
//url += "(delay=15))";
url += " ))";
/**
* LOAD_BALANCE = yes表示程序走sword连接的时候，将在下面的地址里面随机的选择一个，达到接点间连接均匀
* failover表示开启TAF(Transparent Application Failover)特性，其中TYPE =          * SESSION表 示当一个连接好的会话 * 的实例发生故障，系统会自动将会话切换到其他可用的实例，前台应用无须再度发起连接，但会话正在执行的SQL 需要重新执行，METHOD = * BASIC表示初始连接就连接一个接点，他还有个选项是preconnect，表示初始连接所有的 * 接点，在failover的时候可以很快就切过去，这个基本是资源浪费 RETRIES：重试次数 DELAY：重试间的延迟(以秒为单位)
* 如果指定了RETRIES，DELAY默认为1 如果指定了DELAY，RETRIES默认为5
*/
// String sql = "select * from oa_sfm_fb_fwgl t where t.pk_id =
// '17233'";
String sql = "select * from v$instance";
try {
Class.forName("oracle.jdbc.driver.OracleDriver");
conn = Connection(url, conProps);
// conn = Connection(url, username, password);
stmt = ateStatement();
rs = uteQuery(sql);
if (rs.next()) {
System.out.String("INSTANCE_NAME"));
}
rs.close();
rs = null;
stmt.close();
stmt = null;
conn.close();
conn = null;
} catch (SQLException ex) {
ex.printStackTrace();
} finally {
if (rs != null) {
try {
rs.close();
rs = null;
} catch (Exception ex) {
ex.printStackTrace();
}
}
if (stmt != null) {
try {
stmt.close();
stmt = null;
} catch (Exception ex) {
ex.printStackTrace();
}
}
if (conn != null) {
try {
conn.close();
conn = null;
} catch (SQLException ex) {
ex.printStackTrace();
}
}
}
}
}
WEBLOGIC连接Oracle RAC的负载均衡测试
要进行压力测试，中间件使用WEBLOGIC 816，数据库版本为11.1.0.6 RAC，压力测试工具为LOADRUNNER 8.0。测试单实例与RAC环境各个节点的负载情况。
在WEBLOGIC上配置了一个多池，利用WEBLOGIC提供的负载均衡策略，将并发均衡的分别到两个节点上。
但是测试发现，一旦运行了一段时间，所有的压力都会加载到一个节点上，而另一个节点上机会没有任何的压力。
通过数据库中查询到的结果如下：
SQL> SELECT INST_ID, STATUS, COUNT(*)
安装oracle10g2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;
INST_ID STATUS COUNT(*)
---------- -------- ----------
1 INACTIVE 6
1 ACTIVE 1
2 ACTIVE 147
2 INACTIVE 3
WEBLOGIC的并发设置为150，而LOADRUNNER并发为200，Oracle每个实例的SESSION为600。
可以看到，基本上压力完全集中在实例2上。实例1上处于空闲状态，如果压力测试运行时间足够长，可能在短时间内实例1上的ACTIVE连接能达到二、三十左右，但是很快又全部释放。
SQL> SELECT INST_ID, STATUS, COUNT(*)
2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;
INST_ID STATUS COUNT(*)
---------- -------- ----------
1 ACTIVE 20
1 INACTIVE 54
2 ACTIVE 121
2 INACTIVE 28
测试了
多次，结果都很类似，压力几乎完全集中到一个节点上。不过不见得每次压力都是在节点2上，很有可能在WEBLOGIC服务重启之后，下次测试开始，所有的压力都集中到节点1上。这说明问题应该不是两个节点的硬件处理不平衡造成的。
这个测试的是长时间运行的查询，而对于快速相应的INSERT语句，可以看到两个节点上都有很少的ACTIVE的会话。这时因为事务处理很短暂，不可能在短时间内使得WEBLOGIC的并发跑满，因此这种情况没有问题。
SQL> SELECT INST_ID, STATUS, COUNT(*)
2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;
INST_ID STATUS COUNT(*)
---------- -------- ----------
1 INACTIVE 50
1 ACTIVE 1
2 ACTIVE 1
2 INACTIVE 98
对于长时间查询的情况，WEBLOGIC的LOAD-BALANCING策略似乎存在问题，导致两个节点压力出现倾斜。开始认为可能是由于WEBLOGIC的版本太低导致了问题的产生，于是将WEBLOGIC升级到了最新的版本10.3，可是测试结果依旧。
由于前面测试使用的都是WEBLOGIC的LOAD-BALANCING策略进行的，尝试了一下HING-AVAILABILITY策略，发现这个策略倒是和它本身的名称更相符一些，但是也存在一定的问题。这个策略会优先MULIT POOL中的第一个连接池，如果第一个连接池可以连接，就不使用第二个连接池。即使并发用户太多，导致很多连接超时的错误，WEBLOGIC也不会去尝试使用第二个连接池。当后台关闭实例1，导致连接池1的连接失败，这时WEBLOGIC开始使用第二个连接池。一旦实例1启动，WEBLOGIC检测到连接池1可用，马上所有的连接都会从连接池2上转移到连接池1，恢复到实例1关闭之前的情况。基
于上面的情况，感觉WEBLOGIC只是实现了连接池的优先级设置，而不是真正意义上的HIGH-AVAILABILITY。
扯远了，下面继续说WEBLOGIC的LOAD-BALANCING。由于升级到最新版本都无法解决这个问题，只好在网络上搜索，结果发现不少相似的案例。不过没有发现解决方案。
不过在metalink里面的一篇文章提到可以在WEBLOGIC里面的URL=”jdbc:oracle:thin@”后面直接使用Oracle的a中的配置。
比如这里配置URL=”jdbc:oracle:thin@ (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=172.0.2.58) (PORT=1521)) (ADDRESS=(PROTOCOL=TCP) (HOST=172.0.2.59) (PORT=1521)) (LOAD_BALANCE=yes)(CONNECT_DATA=(SERVER=DEDICATED) (SERVICE_NAME=acle))”
这种方式实际上绕过了WEBLOGIC的负载均衡机制，而直接使用了RAC的负载均衡策略，结果测试结果如下：
SQL> SELECT INST_ID, STATUS, COUNT(*)
2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;
INST_ID STATUS COUNT(*)
---------- -------- ----------
1 ACTIVE 75
1 INACTIVE 6
2 ACTIVE 75
2 INACTIVE 5
Oracle的负载均衡的实现还是比较好的，基本上两个节
点的负载差别很小。对于负载较小的情况也同样适用：
SQL> SELECT INST_ID, STATUS, COUNT(*)
2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;
INST_ID STATUS COUNT(*)
---------- -------- ----------
1 INACTIVE 8
1 ACTIVE 1
2 ACTIVE 2
2 INACTIVE 7
测试结果发现，要想在任何情况下都获得比较理想的负载均衡，最好使用Oracle的负载均衡策略，而不要使用WEBLOGIC的多池提供的LOAD-BALANCING策略。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。