-----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