如何在多个生产服务器上维护一个文件（Windows和Linux）

这不是Oracle的问题。 这是puppet，puppet，bcfg2，cfengine，chef等configurationpipe理工具的一个典型用例（其中至less傀儡对pipe理windows机器和unix有一定的支持）

从你的angular度来看，这个具体案件的几个要求是：

1. 每台机器都有自己的本地文件副本，这意味着如果configurationpipe理服务器（或其networkingpath）消失，机器仍然有文件; 它只是不会得到任何更新，直到与母舰的连接恢复
2. 更改将自动从configurationpipe理服务器推送到每个oracle盒子
3. 每个客户端（oracle）机器上额外的一点复杂性
4. 变化发生在一个地方。

不利的一面是，这意味着您需要了解如何运行/configurationconfigurationpipe理系统。 当然，在这样做的时候，你可能会发现更多的用途，使你的环境和pipe理更有效率。

由于TNSNames不是在服务器正在使用时被locking的，因此请在每个X分钟/小时更新文件的每台服务器上尝试一个cron作业或计划任务。

编辑：更新源应该是从所有Oracle服务器可访问的文件服务器（CIFS，NFS等）。 如果文件无法更新，您也可以设置脚本来通知您，尽pipe故障仅仅意味着您的数据库服务器上没有更新而不是丢失关键文件。

将文件的单个副本存储在每个服务器上（缺点：更改文件内容涉及在多个不同的服务器上进行更改）

不过，我会去这个。 编写一个脚本，读取要访问的服务器列表，可能使用根据字段而不同的OS /login控制方法。 另外， Puppet可以用类似的方式将configuration文件推送到Linux或Windows。 木偶还将版本和日志文件的变化。

集中式文件服务器（缺点：如果文件服务器或文件服务器的networking连接中断，则服务器无法访问关键文件）

您可以使用IP故障转移放置冗余服务器，但这不会解决networking问题。 我不认为这是一个强大的解决scheme，为您的单一目的的任务。

每个服务器上的Subversion客户端（缺点：在生产中使用源代码控制工具，增加了复杂性）

您仍然需要编写脚本或向每个服务器发送拉取请求。 但是，我并没有看到“生产中的源代码pipe理工具”的内在缺陷。

对于Windows系统，从共享中复制文件的GPO应该可以工作。 如果你正在使用Centrify，那么也可以做Linux的工作。

对于Linux，您是否正在使用某种configuration系统？ （例如Spacewalk，RHSS）这将是集中pipe理configuration文件的最佳select。

您也可以使用DFS来解决这个问题 – 只要DFS根目录中有多个文件服务器，就可以解决缺less冗余的问题。 您需要支持DFS的Linux机器上的SMB客户端; 我不知道这是否容易/免费/不可能/越野车。