-----dbms_service与dba_services的学习------
dbms_service
根据是否启用load balancing advisory
参数可配置为:
goal_none --禁用lba(lba为load balancing advisory的缩写)
goal_service_time --lba根据服务所花的时间及服务可用的带宽
goal_throughput --lba根据服务已完成的rate及服务可用的带宽
如果启用了lba,分为short及long
clb_goal_short ---connection load balancing使用lba,当lba启用时(可以是goal_service_name或goal_throughput)。当goal=none(禁用lba),connection load balancing使用一个已弃用的根据cpu利用情况的一种建议
clb_goal_long ---对于每个服务,均摊分布每个rac instance所分配的连接数。对于像一些forms的应用(long)推存用这种配置。这种配置用于连接池很固定(不会添加或减少连接池中的连接)
---如何量定何为short及long的连接类型呢??
用于taf failover属性一些参数
failover_method_none ---服务不启用服务器端的taf
failover_method_basic ---服务器端的taf 方法为basic,目前仅支持这种类型的failover method(for taf).也就是说在failover时,会建立一个新的连接,而不是重用预先建立的备用连接(所以不支持preconnect)
引申:两种类型的配置,对于sid的产生有何影响呢?
failover_type_none ---服务器端taf类型为none
failover_type_session ---服务器端taf类型为session。在failover时,taf会重新连接到正常或者存活的实例上,重新连接这个session(失败的).但是像alter session比如重建执行
failover_type_select ---服务器端taf类型为select
引申select与session有何区别?
failover_retries ----在failover时,taf重试多少次,最大值为ub4maval
failover_delay ----可以理解为两次failover动作间的时间间隔,或者讲taf尝试failover之前的时间间隔(时间以秒为单位哟)
使用备注:
1,taf callback已注册情况下,failover retries 及failover delay被忽略。如果发生一个error,taf继续重新尝试连接和认证,前提是只要callback返回oci_fo_retry的值就成。任何delay应该以代码方式写入到callback的逻辑之中
(callback就是服务提供者在请求服务方发出连接请求后给于反馈《呼叫请求方通讯网络》的一种动作)
2,服务器端taf配置会覆盖客户端tnsmames.ora中对应的配置。但是如果在客户端没有配置taf,此时failover type必须配置为启用taf。如果failover type在服务器端配置了的话,那么failover method默认就是basic.delay和retries是可选的,你也可能单独进行配置。
根据以上小结如下:
从是否启用load balancing 及taf的各种组合
a,对于failover,可以启用或者不启用
b,failover可以分为server及client的配置
c,failover基于taf的配置从优先级来讲:server方要高于client方(未测试??)
d,failover method与failover type可以理解为主次关系;failover method分为:none,basic,preconnect;failover type分为:none,session,select
e,goal根据是否启用load balancing advisory及goal的类型,分为:none,service_time,throughput;
f,如果启用了lba,又可以进一步细分为:short及long
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9240380/viewspace-659601/,如需转载,请注明出处,否则将追究法律责任。