cluster_database_instances参数

GDS

此参数在RDBMS：
根据11gR2文档http://docs.oracle.com/cd/E11882_01/rac.112/e16795/admin.htm#CBBCDFIJ
Oracle RAC uses this parameter to allocate adequate memory resources. It must be set to the same value on all instances.
    For policy-managed databases, Oracle internally sets this parameter to 16
    For administrator-managed databases, Oracle internally sets it to the number of configured Oracle RAC instances
此参数在ASM：
根据11gR2http://docs.oracle.com/cd/E11882_01/server.112/e25513/initparams028.htm#REFRN10016
If CLUSTER_DATABASE is set to true:
    If ASM, then 4
    Otherwise, the number of configured Oracle RAC instances

而在10gR2中这个值无论是在RDBMS实例还是ASM实例中都是应该等于RAC的实例数的，问题：
为什么在policy-manged数据库中这个参数要设置为16， 在ASM实例中这个参数设置为4，
为什么不等于RAC/ASM实例数， 这么设置理由是什么？这个参数是可以手工修改的，为什么不在添加节点的时候去修改？

Maclean Liu(刘相兵

ODM Data:

Administrator Managed
Specifically define where the database should run with a list of servers names (“traditional way”)
Define where services should run within the database


Policy Managed
Define resource requirements for expected workload
Enough instances are started to support expected workload
Goal: remove hard coding of a service to a specific instance


Administrator Managed is how we have traditionally done things.  Customers can continue to manage databases in this way and for small clusters, this is the way they will continue to mange their Oracle RAC databases.  
Policy Managed databases are a requirement for Quality of Service Management

Maclean Liu(刘相兵

1. policy -managed 数据库中为什么该值是16?

=》 猜测是为了 方便增加实例

2. 在ASM实例中这个参数设置为4:


SQL> show parameter instance_type

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
instance_type                        string      asm


SQL> show parameter cluster

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
cluster_database                     boolean     TRUE
cluster_database_instances           integer     4
cluster_interconnects                string

ODM Finding:

1. Abstract: ONECOMMAND SETS CLUSTER_DATABASE_INSTANCES  = 4 IN ASM ON 24 NODE CLUSTER
   
2. 
   
3. Hdr: 12329165 N/A INSTALL 11.2.1.3.1 ONECOMMAND PRODID-2546 PORTID-226
   
4. Abstract: ONECOMMAND SETS CLUSTER_DATABASE_INSTANCES  = 4 IN ASM ON 24 NODE CLUSTER
   
5. 
   
6. PROBLEM:
   
7. --------
   
8. Exadata was installed via onecommand
   
9. 
   
10. The ASM spfile parameter cluster_database_instances is set by default to 4,
    
11. yet this same parameter for our database instances is set to 24 (3 full
    
12. Exadata database machine clusters).
    
13. 
    
14. We noticed on our older Exadata full racks, that cluster_database_instances
    
15. is also set by default to 4, yet this same parameter for our database
    
16. instances is set to 8 as it should be (single full rack exadata machines)
    
17. 
    
18. DIAGNOSTIC ANALYSIS:
    
19. --------------------
    
20. 
    
21. WORKAROUND:
    
22. -----------
    
23. 
    
24. Manually set cluster_database_instances to the correct value  for ASM.

复制代码

Manually set cluster_database_instances to the correct value  for ASM;  就这个bug note 看 ASM cluster_database_instances default 4 并非 一个万全值，  仍应设置为 正确的 instance amount ，猜测是文档存在纰漏。

GDS

Thanks

猜测是为了 方便增加实例
>>admin-managed是tradational way, 所以等于实例数是理所当然的，因为为了兼容老的版本。但是policy-managed等于16仍然很费解，16节点既不是rac节点的最高限制，也不是rac最常见的节点数。因为cluster_database_instances这个参数并不是hard-coded的，属于动态参数。如果要增加节点，可以手工修改这个值。如果需要增加节点，那么完全可以在添加节点的时候去修改这个值。

ASM cluster_database_instances default 4 并非 一个万全值，  仍应设置为 正确的 instance amount ，猜测是文档存在纰漏。
>>这个bug说明default为4是有问题的，尤其对于节点数大于4的时候，还是默认为4显然不合适。但是传统的方式这个值却是等于节点数的。难道11g还退化了？这个并不像是简单的bug，因为文档中描述这个值就是4，事实上默认值也是4， 这个值是众所周知的。虽然问题解决起来不复杂，不过还是令人费解。

GDS

传统的模式是自适应的，而新的方式确实固定的，可见应该是存在某种机制的变更。

Maclean Liu(刘相兵

ODM Data:
enq: TX – contention
When this event is among the top wait events in a RAC environment, it may be because transactions are
waiting for remotely mastered TX enqueues. By default, TX enqueues should be locally allocated, but
there are some circumstances where that optimization is not enforced. Currently, when
(cluster_database_instances > _lm_tx_delta), the TX optimization is disabled. As _lm_tx_delta defaults to
16, systems with more than 16 instances or with cluster_database_instances set too high may experience
this kind of wait. Please refer to bug 6457594 for details. A possible workaround is to increase
_lm_tx_delta.

Maclean Liu(刘相兵

可能确实存在某种机制， 但是 目前：

1.缺少 描述这种机制的 文档
2. 缺少测试这个 现象 需要 环境

GDS

So instead of having to configure all applicable parameters you would have to with the Administrator-Managed database, Policy-Managed self-configures all the Instances in the Cluster for you.  So we make an assumption that there will be a maximum of 16 instances:

    You can set this parameter to a value that is greater than the current number of instances, if you are planning to add instances. For policy-managed databases, you should set this parameter to a higher value only if you intend to run a database with more than 16 instances. In this case, set the parameter to the expected maximum number of instances on which this database will run.
Oracle® Real Application Clusters Administration and Deployment Guide
        11g Release 2 (11.2)
        Part Number E16795-12

answer from Kevin Reardon
看来机制就是这样的，虽然对此答案也不是太满意。