虽然在Oracle的立场上，总是建议客户能够更好地规划自己的应用，在有其它负载平衡方法的时候，尽量不要依赖于Oracle的Load Balance方法，但是往往在给客户配置完Oracle RAC数据库以后，客户都会要求要测试负载平衡（Load Balance）和TAF（Transparent Application Failover），并且将这两个测试作为RAC是否安装成功的标准。 这是一件很无奈的事情，像把旁枝末节看作了主要功能，甚至有些买椟还珠的感觉，但是毕竟这是客户，更了解Oracle Load Balance（后文用LB表示），才可以更好满足客户需求。 本文不牵涉TAF（可以参看老熊关于TAF的系列文章PartI，PartII，PartIII），如何在Oracle10g之后版本中在服务器端service层面设置TAF，可以参看Metalink Note: 404644.1。 对于LB，在Oracle10g之前有Client端和Server端两种，在Oracle10g之后又推出了Server端Service层面的LB配置，本文也不涉及Service层面的LB。 在Oracle9i,10g,11g版本中都适用的LB配置分为以下两种。 (1) Client Side Connect Time Load Balance (2) Server Side Listener Connection Load Balance （此处的Listener用以跟10g之后的Server Side Service Load Balance区分开） 1. Client Side Connect Time Load Balance 既然是Client端的LB，那么也就是不需要在数据库服务器端配置任何参数，完全由客户端机器上的tnsnames.ora文件中对于TNS的配置来决定，实际上也就是LOAD_BALANCE参数。 看一个例子，下面这样的TNS配置就是启用了客户端的LB。 CLIENT_LOADBALANCE = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = node1-vip)(PORT…
Tag: network
RAC10gR2 on HP-UX IA64
这几天经历了有史以来最痛苦的Oracle 10gR2 RAC的安装体验。 操作系统是HP-UX IA64，原本是两台已经安装过Oracle10gR2 CRS+RAC的系统，在安装完之后做了安全控制，取消了很多服务，然后机器从北京搬到上海，存储换了（意味着OCR和Voting Disk没有了），主机名称换了，网卡ID换了，IP地址换了（意味着重新构建OCR Disk很麻烦），在这样的一台机器上要重新安装RAC。 多次的失败之后，要求HP工程师重新安装了操作系统，从上周五白天一直到今天晚上才完全搞定，在今天晚上22：00才最后发现原来一切一切不可思议的问题都是源自于一个小小的环节，以往几天甚至对CRS在HP-UX上的稳定性都产生了极大的怀疑。 现象是，css/crs/evm这些后台进程用ps看全部都是正常的，但是crs_stat命令始终报无法连接CRS Daemon；重新启动机器之后有时候一个节点正常了，但是另外一个节点不正常，再次重启，不正常的节点可能又正常了；好不容易两个节点都正常了，数据库软件也安装完毕了，数据库也创建了，最后再重启一下两台机器，CRS又不正常了。。。几乎抓狂！ 最后，焦点聚集到网卡的全双工和半双工设置上，网络集成商在屡次确认网络配置确实没有问题之后，在客户的强烈要求下，最后又再次检查了一下交换机，发现交换机上有两个端口设置成了半双工+自适应，而主机上的网卡全部都是全双工+非自适应，而这两个端口恰恰是连接某台数据库服务器上的Public网卡。就是这个网络设置上全双工和半双工的不匹配，让CRS发生了各种古怪的现象。 一切问题都在把交换机端口也设置为全双工+非自适应之后荡然无存。 这篇文章的意思是：CRS不是想象中那么不稳定，如果在安装过程中或者安装完毕有奇怪的现象，那么第一个要找的不是CRS软件本身，而是操作系统以及网络设置。