【技术开发 技术文章】
1、工作量分配的类型
在RAC环境中，在多nodes上可以配置多个listeners来响应client对相同Database Service的连接请求。
一个multiple-listener设置可影响相应的故障转移和负载均衡：
* client端的连接时间负载均衡（connect-time）
* client端的连接时间故障转移
* server端的连接时间负载均衡
这些特性可以一个个单独实施，也可进行彼此的结合。
此外，如果使用连接池，可以获得相应的运行时间的平衡（run-time balance）：首先，client的工作请求自动的通过连接池获得一定的均衡；此外，从oracle JDBC隐式的连接缓冲特性也可获得相应的收效。
2、client 端的连接时间负载均衡
client端的connect-time负载均衡特性使client可以随机的连接请求列表中的可用listeners。Oracle Net进程通过类表中的协议地址，以随机序列来均衡各个listeners上的负载。否则，Oracle Net将总是尝试对第一个协议地址建立连接。
可以在相应的client端的TNS实体设置参数LOAD_BALANCE=ON。
具体例子：
ERP =
(DESCRIPTION =
(LOAD_BALANCE=ON)
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL=TCP)(HOST=node1vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=node2vip)(PORT=1521))
)
(CONNECT_DATA=(SERVICE_NAME=ERP)))
3、client 端的connect-time failover
此特性可以使client，在初始的向第一个listener建立连接失败后，向其他listener建立连接。在连接描述符中，listener协议地址的数量决定了将会尝试连接listener的数量。如果没有此特性，Oracle Net将只尝试对一个listener的连接。具体上一个实例：
ERP =
(DESCRIPTION =
(LOAD_BALANCE=ON)
(FAILOVER=ON)
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL=TCP)(HOST=node1vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=node2vip)(PORT=1521))
)
(CONNECT_DATA=(SERVICE_NAME=ERP)))
通过设置语句FAILOVER=ON，client端TNS实体实现了connect-time failover 。
这里强烈推荐使用虚拟IP地址（VIP）具体原因在之前已经解释过了。
note：如果使用connect-time failover（故障转移）。不要在listener.ora文件中设置GLOBAL_DBNAME属性。
4、server 端的connect-time负载均衡
上图显示了在RAC cluster中，listener分配Service连接请求的过程。client应用程序连接ERP Service。在server端，Database使用的是动态Service注册特性。这使得每个Instance中的PMON进程可以在cluster中的listeners之间彼此登记交互相应的工作量信息①。随后每个listener就可以获知哪个Instance的哪个Service被started，以及得知每个Instance的绝对session数量和每个node上的运行队列长度。
该特性的具体设置主要是通过在每个Instance的SPFILE中设置初始化参数REMOTE_LISTENER来实现的。该参数的值应该为listener.ora文件中设置的一个TNS名。
根据第①步中获得的负载信息，默认情况下一个listener会重定向相应的连接请求②到负载量最小的node中的Instance对应的listener③。如果想要确保listener重定向连接请求到负载最小的Instance，需要在listener.ora文件中设置PREFER_LEAST_LOADED_NODE_[listener_name]为OFF。如果使用连接池，这种方法效果更好。
图中，首先尝试建立连接的是node2上的listener。基于由PMON进程动态更新的工作量信息，listener确定当前最好的Instance应该是在node1上。所以listener将连接请求重新定向到node1上的listener④。随后，node1上的listener建立一个专用的server进程⑤，连接建立到该进程上⑥。
5、fast Application notification
1）overview
典型的RAC安装可能产生大量cluster事件，它们被cluster中的内部组件用于管理cluster的高可用性。Fast Application notification（FAN）是这样一种特性：它过滤并发布那些被认为是意义重大的特殊目标的高可用性事件。有三种主要方法来将应用程序与FAN进程整合：
* server-side的callout，它可能用于包装脚本，或是执行安装在Database server的特定目录中。callouts可被编码用于影响本地组件。此外，如果部署了代理应用程序，callouts也可影响远程组件。代理应用程序可以包括已经存在的命令行接口server组件，例如SMTP mail servers和SNMP代理，或是客户程序。
* ONC（Oracle notification client）API，提供了通过TCP/IP协议实现的分布式发布/订阅协议。该API可被C和Java应用程序使用。使用该方法，RAC作为默认的事件发布者，所有可访问Database server的客户端C或Java应用程序简单的连接ONC API 库，并订阅FAN事件。当收到事件，应用程序可以执行相应的事件处理行为。一个ONS监听进程需要被在每个订阅了ONC的host上被start。这包括RAC环境中的每个node。
* 应用程序也可通过Oracle JDBC隐式的连接cache，直接让Oracle JDBC库对FAN事件进程处理。使用这种方法，你无须写任何客户端的Java或C代码来处理FAN事件。也不用直接调用ONC API函数。
note：EM与FAN是紧密结合的，无须再配置。
2）fast Application notification的益处
传统的环境中，client或是中间应用层连接到Database，是依赖连接超时、外带的轮询机制或是其他客户端的方法来获知系统的某个组件是否失败。而这种方式在应用程序可用性的重大影响在于它延长了宕机时间。
使用FAN，重要的高可用性时间一旦被检测到，就会被发布，这使已经存在的计算资源可以得到更有效的利用。可以使其与企业的应用程序得到更好的整合，具体包括：中间层的连接管理器、IT管理平台（故障日志记录和e-mail或分页服务器）。
FAN是一个分布的系统，在每个node上被enabled。这使得它更可靠，容错性更强，因为一个组件的失败可以被其他node监控到。所以，event notification可以被检测并pushed到任何一个node中。
FAN 事件是与Oracle data guard broker、Oracle JDBC隐式连接缓冲、EM紧密结合的。Oracle Database 10g JDBC应用程序管理连接池无需custom的代码开发。如果enabled了隐式连接缓冲和fast connections failover，它们自动的与ONS进行了结合。
3）FAN支持的事件类型
4）FAN 事件的状态
此表描述了FAN事件类型的管理资源可具体状态描述。
5）FAN事件reasons
每个管理资源的事件状态都是与相应的event reason相关联。reason进一步描述了触发的事件。上表就给出了可能的reason。
6）FAN 事件的格式
除了type、status和reason外，FAN事件中还包含其他的字段用于进一步描述唯一的cluster 资源：
* event payload的版本，目前是1.0
* primary或是shadow应用Service的name（node event不包含该name）
* RAC Database的name（也不包含在node事件中）
* RAC的Instance名称（不包含在service、database和node事件中）
* cluster主机名（不包含在service和database事件中）
* service的基数（只有service的status=up事件有此项）
* 事件被检测到时，server端的时间
7）server-side callouts的实施
每个被RAC高可用结构检测的database event会导致在标准CRS callout目录中每个相应callouts的执行。在UNIX环境中，此目录是$ORACLE_BASE/product/10.1.0/crs/racg/usrco 。除非CRShome目录是通过网络共享的，否则，必须在每个RAC node上部署新的callout。
这些callouts的执行顺序是不确定的。但RAC 确保一旦以异步模式辨识出event，相应的callouts将会被调用。因此，推荐将需要按照某些顺序执行的callouts进行合并。
可建立你所需的任意数量的callouts脚本，但前提是每个callout的操作代价不会引起导致高可用性事件的繁衍。如果有许多callouts用于基于收到的event执行不同的操作，将多个callout合并为一个callout可能会更高效。
写server-side的callouts设计到以下几步：
①为了callout可以辨识event，必须解析由RAC HA结构发送的event payload。
②当辨识出发送的event后，callout需要需要对其进行过滤，避免执行在所有event的notification上。
③随后需要执行相应的event处理操作，这要依赖event本身和当前业务对恢复进程的要求。
note：处于安全的考虑，确保callout目录和它包含的callouts的写权限只有安装CRS的系统用户有。
8）下面按照书上，上一个例子吧：
脚本第一部分先是对收到的event parameters进行解析。
上面这个接着根据辨识的参数，触发相应的trouble logging program。此处，假设trouble logging 程序logTicket.exe文件已经创建。
9）配置server-side的ONS
ONS的设置是通过$ORACLE_HOME/opmn/conf/ons.config文件来控制的。该文件在安装时被自动创建。主要有三个重要的参数需要被设置。
* localport，设置了ONS的端口号，用于与本地client的会话
* remoteport，ONS用于与其他ONS进程进行对话的端口
* nodes，是ONS进程需要进行对话的特定的列表。该列表应该包括所有所有RAC ONS 进程和所有中间层的ONS 进程。Node的值可以通过host name或是IP地址的方式给出，并跟在remotport参数后面。当然，也可以使用racgonsadd_config命令存储这些数据到Oracle cluster registry（OCR）中，同时在ons.config中设置参数useocr为on。通过将nodes信息放入OCR，无需编辑每个node的文件来改变配置，而只需在任意节点上执行一个命令即可。
上图中，假设ONS已经在每个cluster node上started。这是RAC正确被安装后的默认状态。然而，如果希望使用OCR，应该编辑每个节点的ons.config文件，并在重新载入之前，添加配置到OCR中，上图中已经显示了。随后需要在每个node上执行相应的onsctl reconfig命令。
10）配置client-side的ONS
必须在需要与FAN结合的client 应用程序的主机上安装ONS。多数情况下，这些主机扮演了中间层应用服务器的角色。
所以，在client side端，必须在ONS配置文件中配置RAC node。具体配置的例子见上图。
当配置了ONS后，用onsctl start 命令start ONS进程。必须确保ONS进程一直在运行。具体可以通过onsctl ping命令来查看ONS进程是否运行着。
11）JDBC的fast connection failover
①overview
Oracle Application Server10g 将JDBC Implicit Connection Cache（ICC）与ONC整合，从而使应用程序开发者能获得fast connection failover（FCF）。FCF与JDBC ICC联合工作，快速并自动的恢复丢失或是损坏的连接。这类自动的连接管理是通过FAN时间通过本地ONS被接收到、并由特定的event处理脚本处理来实现的。JDBC thin和JDBC OCI驱动程序都被支持。
因此，如果使用JDBC ICC和FCF，则Java 程序将自动的成为ONC的用户，而无需对FAN事件进程直接的管理。
当任何时候，一个service发起的event被中间层ONS接收到，event处理程序会重用一些未被使用的连接，并使用event service name重新建立连接。重用的连接数量是由连接缓冲自动决定的。因为listeners执行connect-time 负载均衡，所以它将通过service的preferred Instances进行自动的连接在平衡，无需等待应用连接请求或是重试。
②benefits
* 所有的database 连接的均衡是贯穿于RAC中所有支持相应service name的 Instances，而不是仅通过路由建立在类表中的第一个RAC Instance上。连接池在service、Instance或是node up events的基础上进行了再均衡。
* 当新的service在Instance上被enable，连接缓冲立即开始分配连接到特定的RAC Instance上
* 当某个Instance上的service被停止或是node宕机，连接缓冲会立即关闭过时的相应RAC Instance连接。
* Java程序自动的变为一个ONS的用户，而无需直接管理FAN event。数据源需要将setFastConnectionFAiloverEnabled属性设置为true。
4、transparent Application failover
1）overview
TAF是OCI驱动程序的运行特性。当初始连接失败，它使得应用程序可自动的重新连接service。在重建连接的过程中，尽管先前的活动的事务被回滚了，TAF可随意的重新开始执行刚才正在执行的SELECT语句。TAF支持两类故障转移方法：
* 使用BASIC方法，在故障转移期间，重新的连接被建立。如图，初始的连接②在通讯service被start到nodes①后被建立。listener建立连接③，应用程序访问database④直到连接失败⑤。应用程序接到错误信息后再次尝试访问database⑥。OCI驱动程序重建连接到相同的service⑦，则下次改应用程序访问database，它会直接使用新建的连接⑧。
* PRECONNECT方法，类似与BASIC方法，只是在初始连接时一个shadow 连接也同时被创建，用于预防故障转移。TAF确保shadow连接总是创建在service的available Instance上。这主要是通过在available Instances上自动的建立并维护shadow service来实现的。
2）配置实例（BASIC方法）
在使用TAF之前，推荐先创建并start一个service用于连接。这么做可以将TAF和service做有效的结合。当想要使用BASIC TAF时，应该用-P BASIC选项。具体如下：
$ srvctl add service -d RACDB -s AP -r I1,I2 -P BASIC
$ srvctl start service -d RACDB -s AP
随后，应用程序需要使用下面的描述符与service建立连接。参数FAILOVER_MODE必须被包含在CONNECT_DATA段中：
AP =
(DESCRIPTION =(FAILOVER=ON)(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=N1VIP)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=N2VIP)(PORT=1521))
(CONNECT_DATA =
(SERVICE_NAME = AP)
(FAILOVER_MODE =
(TYPE=SESSION)
(METHOD=BASIC)
(RETRIES=180)
(DELAY=5))))
其中：
①TYPE，显示了故障转移的类型。SESSION表示只有user session将被在server-side重新鉴别，但在OCI应用程序中打开的cursors需要被重新执行。SELECT值表示不仅user session在server-side上被重新鉴别，而且在OCI上打开的cursors可继续获取数据。这表明client-side逻辑上为每个打开的cursor维护者fetch-state。一个select语句将使用相同的snapshot重新执行，抛弃那些已经获得的rows，取出那些之前尚未获取的rows。TAF会校验那些被抛弃的rows是已经返回过的rows，否则会返回error信息。
②METHOD=BASIC，用于在故障转移时重新建立连接
③RETRIES，指明在故障转移后，尝试连接的次数
④DELAY，指明两次连接尝试间隔的时间，单位为秒。
note：如果使用TAF，不要在listener.ora文件中设置GLOBAL_DBNAME参数。
3）TAF Preconnect配置实例
在使用PRECONNECT TAF之前，也推荐先创建一个service，包含preferred和available Instances，并start这个service。为了通过CRS自动的创建和管理shadow service，必须定义service是使用-P PRECONNECT选项。相应的shadow service总是被命名为<service_name>_PRECONNECT。具体如下：
$ srvctl add service -d RACDB -s ERP -r I1 –a I2 -P PRECONNECT
$ srvctl start service -d RACDB -s ERP
随后，应用程序需要使用下面的描述符与service建立连接。
ERP =
(DESCRIPTION =(FAILOVER=ON)(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=N1VIP)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=N2VIP)(PORT=1521))
(CONNECT_DATA = (SERVICE_NAME = ERP)
(FAILOVER_MODE = (BACKUP=ERP_PRECONNECT)
(TYPE=SESSION)(METHOD=PRECONNECT))))
ERP_PRECONNECT =
(DESCRIPTION =(FAILOVER=ON)(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=N1VIP)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=N2VIP)(PORT=1521))
(CONNECT_DATA = (SERVICE_NAME = ERP_PRECONNECT)))
note：当TAF不能使用PRECONNECT方法时，TAF会自动的使用BASIC方法。
4）TAF的查证
为了确定TAF是否正确的配置、连接已经与故障转移选项相关联，可以查看V$SESSION视图。为了获得连接client的信息和TAF状态，可查看FAILOVER_TYPE、FAILOVER_METHOD、FAILED_OVER和SERVICE_NAME字段。
SELECT machine, failover_method, failover_type, failed_over, service_name, COUNT(*)
FROM v$session
GROUP BY machine, failover_method, failover_type, failed_over, service_name;
5、FAN连接池和TAF的思考
* 两种技术都是与services相结合的，并且提供了service连接的负载均衡
* 如果使用了FAN，就无需使用TAF。两者是不能结合使用的
* 使用FAN的连接池技术总是preconnected的
* TAF主要是通过OS的timeout来检测失败的，但FAN不是
6、限制session和services
这里没搞懂~~~~(>_<)~~~~
