MySQL InnoDB存储引擎的一些参数
InnoDB做为MySQL目前最广泛的事务存储引擎，很多地方的设计和Oracle都是共通的。对于Oracle DBA来说，学习的时候可以多和Oracle的一些特性进行类比，当然也要明白二者之间的区别。
innodb_additional_mem_pool_size
用于缓存InnoDB数据字典及其他内部结构的内存池大小，类似于Oracle的library cache。这不是一个强制参数，可以被突破。
innodb_buffer_pool_size
内存缓冲池大小，用于缓存表和索引数据等。类似于Oracle的buffer cache，如果可能，尽可能的设置大一点。
innodb_log_buffer_size
日志缓冲区大小，类似于Oracle的log buffer
innodb_log_file_size
日志文件大小。默认会创建2个5M大小的名为ib_logfile0和ib_logfile1的文件。日志文件的数目由参数innodb_log_files_in_group指定。存放位置由innodb_log_group_home_dir指定。
innodb_data_file_path
指定InnoDB表空间数据文件名，大小以及其他属性。所有文件的加起来不能少于10M。多个数据文件之间以逗号分割，属性之间以冒号分割。默认创建一个大小10MB名为ibdata1的可自动扩展的数据文件，一般在生产环境中都需要根据实际情况指定，由于往表空间中添加数据文件需要停机，尽量在规划的时候做好准备，如果可以的话最好开启最后一个数据文件的自动增长属性。数据文件的个数在规划的时候还需要考虑另外一个innodb_open_files参数。
innodb_file_per_table
取值为ON或者OFF。是否为每个table使用单独的数据文件保存。如果系统中表的个数不多，并且没有超大表，使用该参数可以使得各个表之间的维护相对独立，有一定的好处。
innodb_autoextend_increment
当自动扩展表空间被填满之时，每次扩展空间的大小，默认值是8(单位MB)。该参数可以动态修改：
Query OK, 0 rows affected (0.01 sec)
innodb_status_file
定期将show inndb status的结果输出保存到文件中，建议开启以便分析性能。
安装Oracle10g Clusterware遇到的一点问题
在vmware上安装一个双节点的Redhat Linux + Oracle10g RAC + ASM的测试环境，按照Oracle官方网站的安装指南，基本都很顺利，只是在clusterware的安装过程中碰到一点小问题。在执行root.sh脚本时，一直卡在Startup will be queued to init within 90 seconds.过不去，手动执行/etc/init.d/init.cssd start也是同样的问题，两个节点都是同样的情况。重装了三次后终于发现问题所在，就是在前面指定ocr和voting disk的location的时候，我填入的是soft link而不是raw设备的路径，改成类似/dev/raw/raw1的字符设备路径就ok了，本来想建个link比较易于识别的，郁闷。
通过NFS执行RMAN恢复遭遇ORA-27054
下午同时做两个备库，一个9.2.0.6，一个10.2.0.3的，都是通过NFS直接将主库的RMAN备份挂到备库相同路径。然后通过rman来restore。
9206的一切正常，10203报错：
ORA-19505: failed to identify file "/bak/rmanbak/NinGoo/0ija94hs_1_1_18.bak"
ORA-27054: NFS file system where the file is created or resides is not mounted with correct options
Additional information: 6
Metalink上一查，又碰到bug了。10g的bug真的不是一般的多，随便做个什么操作都可能碰到，晕死。昨天晚上RAC又出了点小毛病，一个节点down掉后无法mount，在其他节点测试，发现控制文件和某些数据文件都无法读取，trace出来一直在做gc domain validation等待，估计由于节点异常宕掉导致某些资源锁无法释放了，没办法只有重启所有节点，而且由于控制文件无法读写，还只能shutdown abort，剩最后一个节点的时候shutdown immediate成功。
10gR2通过NFS执行rman备份恢复都可能碰到这个Bug 5146667，描述详见Note:424785.1，临时解决方法，可以修改nfs的mount参数(不同的平台参数可能不一样)，或者设置10298事件，或者打相关patch。查了下patch好像只有Solaris平台的…
Oracle11g ASM强大的新工具AMDU
在上次ASM故障恢复的案例中，强烈的感觉到ASM过于封装的特性，虽然极大的减轻了DBA的管理负担，但同时也使得灾难发生的时候处理的难度更高。
刚刚在著名的Pythian上看到一篇不错文章，提到Oracle11g的ASM提供了一个新的工具amdu，这个名字貌似就是ASM+DUL的简写，很好很强大。目前还没有实际使用过，看了看帮助，其功能真的非常厉害，对于磁盘头损坏之类的故障处理起来非常的方便，也可以直接从diskgroup里抽取出数据文件。有了这个东东，d.c.b.a开发基于ASM的AUL的想法基本可以放弃了，哈哈。有时间可以好好的研究下。
文章中还提到两个rac和asm方面非常值得一看的网站：
http://canali.web.cern.ch/canali/
http://blogs.oracle.com/AlejandroVargas/
