客户有一套部署在Window 2008 R2 sp环境下的12.1.0.2 RAC环境，该RAC基于策略管理。因为业务需要，现在需要更换部分设备——踢出两台2路的服务器（节点名称分别为racnode2,racnode3），然后新加两台4路的服务器（节点名称分别为racnode4,racnode6）。
删除节点，按照官方文档上的步骤很顺利地完成。
但在增加节点时，在做增加节点前的一致性检查时，总是通不过，报错如下：
图 1
根据报错信息，在百度上搜索解决办法。大多数网友给出的解决办法是对C:盘符设置共享。Windows 2008出于管理目的，会默认以C$的共享名称共享C:盘符，既然C:已经共享了，莫非是共享的权限出了问题？在对该共享目录设置了everyone拥有读写权限之后，问题仍然没能得到解决。
在找不到解决办法之后，我打算忽略掉这个错误。尝试在racnode1上使用
Addnode "CLUSTER_NEW_NODES={ racnode4}" "CLUSTER_NEW_VIRTUAL_HOSTNAMES={ racnode4-vip}"命令来强制增加cluster节点，然而不行，直接就弹出了错误提示，而且不支持跳过该错误。根据弹出的错误提示，出错的原因可能有3个，分别是
-
Racnode4不可访问
-
节点之间不具备对等用户
-
无法访问所有节点的临时目录
而结合上图1的信息，可知前两个可能的原因都是通过了检查的，那么出错的原因应该是出在第3项上。
在windows中，访问其它节点的目录（临时目录也是目录），肯定是通过共享目录的方式。查看了%TEMP%与%TMP%两个环境变量的值，都指向C:盘上的一个路径。另外，直接使用\racnode4c$ emp的方式是可以直接访问到临时目录的，所以，应该也不存在无法访问其它节点临时目录的情况，那导致错误的根因到底是什么呢？
让我们再回到错误信息上，"无法从节点racnode4检索exectask的版本"，这句话有一个名词——"exectask"我不知道是什么所在。在百度搜索引擎中输入exectask根本查询不到有价值的信息，它既然有版本属性，很可能是一个工具或应用程序。
与临时目录有关，也与exectask工具或程序有关。我突然想到：会不会这个程序就在临时目录中呢？打开racnode4的临时目录一搜，果然在CVU_12.1.0.2.0_Administrator目录中有一个名称为exectask的可执行程序，试着双击该可执行程序，报错了：
图 2
Racnode4缺少msvcr100.dll，那已经部署了cluster+RAC的racnode1有没有呢？通过查看racnode1的临时目录下的CVU_12.1.0.2.0_Administrator，发现与racnode4相比，多了msvcp100.dll和msvcr100.dll两个动态链接库。
接着，我以msvcr100为搜索内容对racnode1和racnode4的C:盘范围进行了全盘搜索，结果发现racnode1的c:windowssystem32目录下存在msvcr100.dll，而racnode4不存在。抱着试一试的心态，将racnode1节点c:windowssystem32目录下的msvcr100.dll、msvcp100.dll拷贝到racnode4同路径下，再次执行Addnode命令，竟然通过了，如下图：
问题的根因竟然是racnode4节点缺少msvcr100.dll、msvcp100.dll等动态链接库造成的。那么我不禁要问了，相同的操作系统，为什么racnode4上没有这些动态链接库？这些dll文件的主要作用是什么呢？
msvcp、msvcr、vcomp100.dll属于VC++2010版运行库，它在微软的任何原版系统是默认不会安装的，当然被人修改过的系统镜像可能包含该运行库。所以对于原版系统来说，当缺少该类dll时，重装并不能解决问题，需要下载相应的dll或直接安装Visual Studio 2010即可。可能是由于racnode4等节点在安装操作系统时，与racnode1所使用的系统镜像不一样，导致了它在操作系统层面缺失了相关dll。而exectask应用程序又恰好需要用到这些dll，这导致了在执行addnode时的报错。