RESTORE数据时10G+ASM遇到ORA-4031及ORA-00600 KSSRMP1错误
近期一朋友在AIX6.1+10.2.0.4 RAC==》AIX6.1+10.2.0.4单节点RAC做DATAGUARD。
在AIX6.1+10.2.0.4单节点RAC上做RESTORE还原数据时，遇到错误：
ASM实例报错有的ORA-600 [kssrmp1]以及ORA-04031错误，还有如下：
ORA-19870: error reading backup piece/full.bak
ORA-19504: failed to create file "+DATA1"
ORA-17502: ksfdcre:4 Failed to create file +DATA1
ORA-15055: unable to connect to ASM instance
介入时候，因为客户是通过加密机+TEAMVIEWER+QQ等远程过去，只留有几个截图。
时间紧急，首先对于600错误分析，查询MOS文档，是有相对应的BUG:
ORA-600 [kssrmp1] (文档 ID 139162.1)
Bug 7308941 - ORA-600 [KSSRMP1] in ASM (文档 ID 7308941.8)
不过没得到相应TRACE文件，是否完全匹配此BUG，不好进一步确认。
对于ORA-19504等在ASM的磁盘组中无法创建文件等报错，CRS集群件的相应服务均正常，ASM磁盘组也MOUNT状态；
使用ASMCMD命令去相应磁盘组中查看，控制文件已经创建在里面了，数据库也可以MOUNT；因此判断对ASM磁盘组+DATA读写是没有问题的。
对于报错的ORA-04031错误，ASM实例使用的SGA自动管理，查询V$SGAINFO，共享池大小是128M（没日志记不太清..），对此进行了增加，增大到256M；
关于ASM的共享池分配，ASM & Shared Pool (ORA-4031) (文档 ID 437924.1)里面也有较为详细的说明；
共享池大小的计算：
For disk groupsusing external redundancy, every 100 GB of space needs 1 MB of extra sharedpool plus 2 MB.
For disk groupsusing normal redundancy, every 50 GB of space needs 1 MB of extra shared poolplus 4 MB.
For disk groupsusing high redundancy, every 33 GB of space needs 1 MB of extra shared poolplus 6 MB.
对于11.2.0.3/11.2.0.4/12.1版本，建议值是：
SQL> alter systemset memory_max_target=4096m scope=spfile;
SQL> alter systemset memory_target=1536m scope=spfile;
Note: In11.2.0.3/11.2.0.4对 MEMORY_TARGET大小的计算方式：
1) If PROCESSESparameter is explicitly set:
The MEMORY_TARGETshould be set to no less than:
256M + PROCESSES * 132K (64bit) or 256M + PROCESSES * 120K (32bit)
2) If PROCESSESparameter is not set:
The MEMORY_TARGETshould be set to no less than:
256M + (available_cpu_cores * 80 + 40) *132K (64bit) or 256M +(available_cpu_cores * 80 + 40) * 120K (32bit)
之后重新进行RESTORE操作（只尝试恢复了1、2号两个数据文件），可以正确完成。
测试恢复1、2号两个数据文件后，使用全库RESTORE脚本进行了恢复，次日听说恢复了一夜，已经恢复完成了。
----------------
关于此次问题的处理，是否BUG最终也未进行进一步确认；通过判断ASM的磁盘组是正常的，之后调整了ASM共享池大小；然后能够正常RESTORE数据，协助也就结束了。
其实整个恢复过程还涉及其它的问题，如客户对数据库在磁盘组中位置的疑惑:
只指定+DATA磁盘组，会默认创建+DATA/DB_UNIQUE_NAME/file_type/filename 这样格式，file_type通常是datafile/controlfile等；
至于此RESTORE过程比较慢(备份集大小700G/是否压缩也不确定)；在恢复测试时也相应增加了LARGE_POOL；关于RMAN备份、恢复的进一步调优，此处就不多说了；可以参考文档：
Note.360443.1 RMAN Backup Performance
Note 740911.1 RMAN Restore Performance
Note 247611.1 Known RMAN Performance Problems
NOTE.579158.1 Advise On How To Improve Rman Performance
NOTE.296985.1 RMAN Performance Data Gathering
Note.463227.1 Oracle10g RMAN Recovery Catalog Known Performance Issues