在Oracle10gR2的RAC环境中，数据库自然是使用RMAN来备份，那么CRS和ASM实例如何备份呢？

Oracle会自动对CRS的配置信息OCR盘进行备份，Oracle会自动选择将备份文件存储在哪个节点上，通过ocrconfig命令我们可以知道最近的ocr备份信息的存储情况，然后定期使用操作系统的tar或者带库的文件系统备份功能将相应目录备份进磁带，就完成了ocr的备份。

$ /oracle/crs/cdata>ocrconfig -showbackup

server1 2007/04/17 12:23:56 /oracle/crs/cdata/crs
server1 2007/04/17 08:23:55 /oracle/crs/cdata/crs
server1 2007/04/17 04:23:54 /oracle/crs/cdata/crs
server1 2007/04/16 08:23:50 /oracle/crs/cdata/crs
server2 2007/04/04 02:14:51 /oracle/crs/cdata/crs

对于仲裁盘votingdisk，可以使用dd命令将其copy到文件系统，然后同样使用带库的文件系统备份功能备份到磁带上。crsctl query命令可以得到当前使用的votingdisk的设备名称。

$ /oracle/crs/cdata>crsctl query css votedisk
0. 0 /dev/vote_disk

$ /oracle/crs/cdata>dd if=/dev/vote_disk of=/orabackup/vote_disk
501760+0 records in.
501760+0 records out.

最后是ASM实例的备份，因为ASM没有任何数据文件，所以只需要在文件系统级别备份ASM的$ORACLE_HOME目录即可。

Powered by ScribeFire.

ASM backup CRS Oracle

新系统上线，下午忽然几近崩溃，数据库服务器IDLE只有5%-10%，大量latch: library cache和cursor: pin S wait on X等待，旁边客户技术经理的手机短信不断，全部是在各个省市的技术人员报告应用终端报错的短信，现场一片凝重。

AWR报告显示数据库90%以上的时间都花在了Parse过程上，而且是软解析。

session_cached_cursors只有20。

另外AWR报告中“SQL ordered by Elapsed Time”和“SQL ordered by CPU Time”部分，也显示同样的一句SQL（一个新加入的应用功能）占据所有SQL的消耗时间和CPU时间90%以上。

采取措施：
1. 增加session_cached_cursors到50
2. 在应用端屏蔽那个SQL

重新启动数据库，应用恢复正常，服务器IDLE升高到80%以上。

因为同时修改了数据库参数和应用才解决了问题，所以下午的争用是不是确实由于session_cached_cursors设置过小引起的？如果此时再次加回那个SQL应用还会不会出问题？

Oracle 10gR2 数据库在启动的时候报ORA-600错误：

ORA-00600: internal error code, arguments: [keltnfy-ldmInit], [46], [1], [], [], [], [], []

原因：
服务器hostname没有正确配置，通过hostname命令得到的主机名无法ping通，Oracle10g认为主机无法达到所以启动数据库报错。

解决方法：
将hostname添加到/etc/hosts文件中，重新启动数据库。

ora 600 Oracle

1. TSM（Tivoli Storage Manager）在产品易用性方面真是不如Veritas的NBU，甚至也不如HP的Omni DP。

2. 高端带库的I/O速度不弱于盘阵，跟I/O通道个数以及驱动器个数关系很大。

3. 使用2个channel往84块单盘300G的底层作了0+1 RAID的21个物理卷组成的ASM磁盘组中（好拗口 …）restore 2T大小的数据库耗时6小时。

4. 目前看来，所有的ASM磁盘组信息都没有存在任何配置文件中，无论是进入asmcmd还是选择v$asm相关视图，都是实时从PV头部读取的信息。所以在ASM使用外部冗余的磁盘组中一块PV坏掉以后，可以直接用dd来清除该磁盘组中所有其他disk的头部信息，然后重新创建磁盘组，然后用RMAN恢复数据库，这也是当ASM磁盘组崩溃以后唯一的修复方法。

5. 条带并不是越多越好。在这个环境中，112块disk在硬件级别做了RAID 0+1的条带和镜像，操作系统中对这112/2*300G=16T的存储做了56个PV，如果在创建LV的时候又选择了条带选项（二次条带化），那么读性能将会严重下降，每秒只能达到60M的读，而如果去除二次条带化，则读性能可以上升到每秒200M。
原因：在将数据写入做了二次条带化的存储上时，首先数据在操作系统级别被打散为56个stripe，然后每个stripe在硬件级别又再次被打散为56个stripe，这样并行写的性能是没有问题的，但是在读取的时候，由于请求的数据在硬件级别是被打散在56块disk中的，而硬件级别的缓存机制在读取一块disk上的数据时将会缓存相邻的大量数据，而这些缓存对于此次读取来说都是无用的，当从另外一个disk中再读取需要的数据时，缓存又需要被腾空再容纳这个disk上的数据，但是这次缓存中又只有很小一部分数据是有用的，因此当PV越多的时候，二次条带将导致越大的性能下降。

6. 10g的新功能change tacking貌似有些bug，在头天晚上启动了change tacking，然后做了level 0备份，2.1T的数据文件总共备份出200G的备份集，第二天做了level 1备份，居然备份出2.1T的备份集，也就是change tracking告诉RMAN在这一天里面所有的data block都发生了变化，所以RMAN备出了数据库中所有block，但是实际上这很明显是不可能的，因为当天的归档日志备份只有500多M，第三天仍旧是level 1备份，就比较正常了，当天产生60多G的归档日志，但是level 1备份只花费了3分钟，这是change tracking真正的威力显示了。

AIX ASM Oracle TSM