问题的背景是这样，以前学习oracle 10g rac的时候在rhel 5上安装，真是快使出吃奶的劲了，前前后后忙活了一个多星期，配网络，配共享存储，修改vmware的配置文件，结果在root.sh的部分发现认证系统是rhel 4,rhel 5中还需要手工去修改一些脚本内容才可以，要不总是在root.sh的时候出现很奇怪的报错。所以包括我还有很多的DBA朋友们，可能都在这个历程中感受到了艰辛。越是难做，越发感觉安装真是一件大活，都特别想亲自看看安装的过程。所以自己也准备了好几套虚拟机环境，安装的过程也是全程截屏，不断的分析可能哪些步骤会出现哪些错误和问题。每次看起来倒也是蛮有收获和感悟。
因为之前的配置都是使用裸设备来绑定的，所以这个思路也就慢慢延续了下来，但是发现工作中都不使用裸设备的方式，都是udev配置磁盘组，而且不同的操作系统版本配置方式也略有差异，现在的主流操作系统版本都是rhel 6了吧。到了11g后续的版本已经可以从官方文档看到裸设备已经会慢慢不再支持，究其原因，其实听了Tony的解释还是很有说服力的：很多人接触和使用过裸设备，也有很多数据库页支持裸设备，但是Oracle最近的版本将不建议使用裸设备，后面的版本就直接不支持了其原因就在于：裸设备没有繁琐的缓存机制，用户写入的数据就直接写入到介质中；同时避免了double cache;裸设备不仅不缓存用户数据，也不缓存基本的metadata;因为使用裸设备的高性能，曾经比较流行。（实际上这是不对的）,由于裸设备的性质决定了它不能提供任何缓存，也不对数据做任何保证，对数据安全权要全权由用户跟数据管理系统来保证，所以当使用裸设备发生断电的时候，最容易造成数据库崩溃，数据损坏等不可控的情况出现，所以裸设备正在遭到抛弃，同时也不建议使用裸设备，因为不安全，也不可靠。这些都是Tony兄的真知灼见。
然后说asmlib,也是一种可以配置asm磁盘组的一种选择，奇怪的是自己从最开始就直接放弃了这个解决方案，因为这个需要额外安装asmlib的安装包，同时安装包也是依赖于操作系统内核版本，当然安装好之后还是有不少实用的命令，但是在工作中还是几乎没有看到使用的场景，直到在11g的某个版本发现asmlib已然不再支持。和同事之间聊asm,如果能够把asm本身推得更普遍一些，弄成类似mkfs -t ext4这种类型的方式，可能方便使用起来就会有更多的人去接受它。
所以这些以前看起来的很多难点和坑在后续的版本都进行了改进，甚至说oracle在用一种主流的使用方式来引导我们。所以越是这样可能对于以前的那一批DBA战友们这个过程就弥足珍贵，但是也仅仅是回忆之中，我老是喜欢感慨，11g版本实在是太好了，有太多的改进和闪光点，很多功能都是在潜移默化之中使用，你可能都没有意识到需要专门去打开某些特性，它们就在那儿。active dataguard,sql monitor,rac-scan,备库的awr,ash...这些都极大的改善了我们的工作处境。同时对我们的挑战就是怎么去填补过去的坑，以前的真知灼见，攻略秘籍肯能就成了昨日黄花。对于更多的新人来说，直接入手11g,他们可能不会有那种改进的感觉，因为他们可能潜意识中就会认为就应该这样，所以我们的有些痛点不好道出。
身边有不少的DBA朋友都在感慨说10g rac着实难装，很多人可能因此留下了一些阴影：）
我在学习11g rac的时候就会有各种顾虑，所以整个环境也是配置了很久，最后好不容易搞定，明显感觉要好很多，当时其实是碰到了一个问题，就直接把grid clusterware和数据库软件都安装在了grid用户下，所以这些年一直在用这种看似奇怪的方式，然后限于自己使用vware，不想再修改更多的配置文件，索性使用了nfs这样，哪种虚拟机都可以无缝支持。这套rac环境也前前后后出了些小问题，但是最终都把它可以正常open. 很多的安装细节早都忘记了，也不知道具体什么问题，最后把所有的东西都装在了grid下，安装的挂载点自己也定义了u01,u02,u03,u04里面的目录最后我自己都几乎分不清楚到底哪些是安装文件，哪些是临时生成的。直到最近因为一些需要，觉得还是需要把这个环境得格掉了，重新来做一做。结果几年后自己来安装的过程几乎没有碰到什么问题，一路很顺利安装下来，11g中的ssh互信可以只输入用户密码就会分分钟帮你自动搞定，对于更多的细节验证也很多到位，使用nfs安装的过程中我是实在没有找出任何可以圈圈点点的问题了。最后才发现自己几年前遗留的问题，把所有东西放在一个用户下，很可能是因为目录的权限导致自己判断失误，结果就妥协了，新的安装我清理了所有的不明确的目录，不规范的目录名称，然后重新来规划，安装好之后也感觉清晰干净了很多，也算了却了一件心事。
所以很多遗留问题，这块硬骨头还是要啃;有太多的目录冗余，不明确的地方，还是要梳理清楚;自己之前迈不过去的坎，可能压根就不是什么技术难题，只是一时理解偏差。所以简单来说，安装rac已经过了那个艰苦的岁月，软件本身就已经支持的很好很强大了。对于我们来说，就要了解这些改进之处，继续向前，毕竟这些难题解决了，交给我们的应该是更有难度和技术价值的问题了。数据库软件做的越好，对于我们来说要求就会更高，一旦不思进取，就会被逐渐时代抛弃，这也是不争的事实。
自己也暗暗给自己下了一个目标和任务，需要努力学习更多的未知领域，不能跟挤牙膏一样，每天都在这种被动的推动之后，自己不努力，下决心去改进，知识范围就会牢牢被束缚。
因为之前的配置都是使用裸设备来绑定的，所以这个思路也就慢慢延续了下来，但是发现工作中都不使用裸设备的方式，都是udev配置磁盘组，而且不同的操作系统版本配置方式也略有差异，现在的主流操作系统版本都是rhel 6了吧。到了11g后续的版本已经可以从官方文档看到裸设备已经会慢慢不再支持，究其原因，其实听了Tony的解释还是很有说服力的：很多人接触和使用过裸设备，也有很多数据库页支持裸设备，但是Oracle最近的版本将不建议使用裸设备，后面的版本就直接不支持了其原因就在于：裸设备没有繁琐的缓存机制，用户写入的数据就直接写入到介质中；同时避免了double cache;裸设备不仅不缓存用户数据，也不缓存基本的metadata;因为使用裸设备的高性能，曾经比较流行。（实际上这是不对的）,由于裸设备的性质决定了它不能提供任何缓存，也不对数据做任何保证，对数据安全权要全权由用户跟数据管理系统来保证，所以当使用裸设备发生断电的时候，最容易造成数据库崩溃，数据损坏等不可控的情况出现，所以裸设备正在遭到抛弃，同时也不建议使用裸设备，因为不安全，也不可靠。这些都是Tony兄的真知灼见。
然后说asmlib,也是一种可以配置asm磁盘组的一种选择，奇怪的是自己从最开始就直接放弃了这个解决方案，因为这个需要额外安装asmlib的安装包，同时安装包也是依赖于操作系统内核版本，当然安装好之后还是有不少实用的命令，但是在工作中还是几乎没有看到使用的场景，直到在11g的某个版本发现asmlib已然不再支持。和同事之间聊asm,如果能够把asm本身推得更普遍一些，弄成类似mkfs -t ext4这种类型的方式，可能方便使用起来就会有更多的人去接受它。
所以这些以前看起来的很多难点和坑在后续的版本都进行了改进，甚至说oracle在用一种主流的使用方式来引导我们。所以越是这样可能对于以前的那一批DBA战友们这个过程就弥足珍贵，但是也仅仅是回忆之中，我老是喜欢感慨，11g版本实在是太好了，有太多的改进和闪光点，很多功能都是在潜移默化之中使用，你可能都没有意识到需要专门去打开某些特性，它们就在那儿。active dataguard,sql monitor,rac-scan,备库的awr,ash...这些都极大的改善了我们的工作处境。同时对我们的挑战就是怎么去填补过去的坑，以前的真知灼见，攻略秘籍肯能就成了昨日黄花。对于更多的新人来说，直接入手11g,他们可能不会有那种改进的感觉，因为他们可能潜意识中就会认为就应该这样，所以我们的有些痛点不好道出。
身边有不少的DBA朋友都在感慨说10g rac着实难装，很多人可能因此留下了一些阴影：）
我在学习11g rac的时候就会有各种顾虑，所以整个环境也是配置了很久，最后好不容易搞定，明显感觉要好很多，当时其实是碰到了一个问题，就直接把grid clusterware和数据库软件都安装在了grid用户下，所以这些年一直在用这种看似奇怪的方式，然后限于自己使用vware，不想再修改更多的配置文件，索性使用了nfs这样，哪种虚拟机都可以无缝支持。这套rac环境也前前后后出了些小问题，但是最终都把它可以正常open. 很多的安装细节早都忘记了，也不知道具体什么问题，最后把所有的东西都装在了grid下，安装的挂载点自己也定义了u01,u02,u03,u04里面的目录最后我自己都几乎分不清楚到底哪些是安装文件，哪些是临时生成的。直到最近因为一些需要，觉得还是需要把这个环境得格掉了，重新来做一做。结果几年后自己来安装的过程几乎没有碰到什么问题，一路很顺利安装下来，11g中的ssh互信可以只输入用户密码就会分分钟帮你自动搞定，对于更多的细节验证也很多到位，使用nfs安装的过程中我是实在没有找出任何可以圈圈点点的问题了。最后才发现自己几年前遗留的问题，把所有东西放在一个用户下，很可能是因为目录的权限导致自己判断失误，结果就妥协了，新的安装我清理了所有的不明确的目录，不规范的目录名称，然后重新来规划，安装好之后也感觉清晰干净了很多，也算了却了一件心事。
所以很多遗留问题，这块硬骨头还是要啃;有太多的目录冗余，不明确的地方，还是要梳理清楚;自己之前迈不过去的坎，可能压根就不是什么技术难题，只是一时理解偏差。所以简单来说，安装rac已经过了那个艰苦的岁月，软件本身就已经支持的很好很强大了。对于我们来说，就要了解这些改进之处，继续向前，毕竟这些难题解决了，交给我们的应该是更有难度和技术价值的问题了。数据库软件做的越好，对于我们来说要求就会更高，一旦不思进取，就会被逐渐时代抛弃，这也是不争的事实。
自己也暗暗给自己下了一个目标和任务，需要努力学习更多的未知领域，不能跟挤牙膏一样，每天都在这种被动的推动之后，自己不努力，下决心去改进，知识范围就会牢牢被束缚。
