根据Metalink Bug 5455094的解释，在Oracle9iR2 RAC环境中，如果db_cache_size + db_keep_cache_size总共超过了50G，那么数据库实例就会在启动的时候报ORA-00064错误，无法正常启动。
00064, 00000, “object is too large to allocate on this O/S (%s,%s)”
// *Cause: An initialization parameter was set to a value that required
// allocating more contiguous space than can be allocated on this
// operating system.
Metalink上的建议是：
1. 降低cache size（这是一个很扯淡的建议，直接无视）
2. 设置_ksmg_granule_size到一个比较大的值，比如_ksmg_granule_size=67108864，实测结果当设置该参数之后，数据库性能低下，反应缓慢。
客户的这个环境，数据库SGA设置高达200G，以上两种方法都不能使用，却可以通过土办法来曲线救国。
1. 设置SGA_MAX_SIZE = 200G，这个参数不会触发Bug 5455094。
2. 设置db_cache_size为一个较小的值，以不触发Bug为标准。
3. 在每次实例启动之后，脚本自动执行用alter system命令将buffer cache扩大。
alter system set db_cache_size = 214753888696 scope=memory;
200G SGA. Rich customer.
ALTER system SET db_cache_size = 214753888696 scope=memory;
200GB db_cache_size, 打错字了？
没错。。。
不是2G也不是20G，是200G。还是RAC呢，两台64颗CPU，256G内存的IBM P595。。。
但是你的sga_max_size是200GB，这个时候，你还能设置db_cache_size to 200GB吗？
还是说，你的workaround里面说的(1)是独立的，(2)(3)是独立的？
没有做过这个大SGA的，只做过25GB SGA的 (SunFire T2000, 64GB RAM)，database大小是20GB.
这么多内存得消耗不少CPU的啊，估计是sun的机器
64CPU,已经是595的满配了。有钱的主。
遇到过这个问题。
HP superdrome主机，物理内存377G.单机
_ksmg_granule_size=67108864后解决
中国的企业买硬件从来都是最舍得花钱的
呵呵，只是一个大致的说法，自然sga_max_size的设置会容纳下之后db_cache_szie的。