还有一个来自MCM的SharePoint问题昨天。
您为SharePointsearch数据库提供什么样的HA？ 我从一个非常非常大的SharePoint服务器场的pipe理员那里听说，他们没有search数据库的冗余副本，并且在丢失时重新填充它。 问题是要重新抓取他们的4300万件需要8 周 。
我不是一个SharePoint专家，但我猜测，没有一个function齐全的search数据库，function将会降级。 8个星期是否适合这个？ 这似乎天文学上很慢。 你有什么经验？
谢谢！
我使用一个大约1.12亿个文件的系统。 完整的爬行需要大约3周的时间。
我想说这取决于你如何为农场设置抓取工具。 多台索引服务器最适合用来帮助传播负载。
我最好的build议是将所有数据库放在同一个HA群集上，如果这对你很重要的话。 但是，search数据库在devise上意味着要重新生成。
function是否会降级？ 只search您的查询只会返回已被抓取的数据。 内容还可以。
MOSSsearch数据库的问题在于，它与物理上驻留在服务器场的索引服务器的文件系统中的索引文件紧密结合; 我相信交易同步到毫秒。 因此，如果您失去了search数据库，唯一的select（除非您有一个专门的SharePoint DR工具）是重build您的索引，并重新开始一个新的search数据库，因为您的索引文件将与恢复的数据库不同步，并损坏。
最新版本的Microsoft Data Protection Manager 2007能够备份search索引和数据库，但必须运行特殊的脚本才能启用该function。 我不确定其他厂商的工具是否能够做到这一点，我认为有几个是但不记得我的头顶。 如果您使用SQL备份或SharePoint的开箱即用备份/恢复工具，恢复索引的唯一方法是从头开始重build。
以前的答案是关于pipe理具有多个索引的search语料库的大小，尽pipe它增加了农场的一些额外开销和复杂性。 需要构build额外的索引服务器，有效pipe理用户查询以便它们能够find正确的索引和/或合并结果可能是一个挑战。
与承载BDC，search，用户configuration文件的SSP DB的恢复故事是非常糟糕的，因为它的一部分在SQL Server中，一部分在服务器上的文件中。 这是一个非常糟糕的build筑。 如果一切都在SQL Server中，那么恢复是可行的。 但是由于部分search索引在文件系统恢复上变成了一场噩梦。
我们实际上已经恢复了SSP了。 为此，我们将内容数据库附加到新的服务器场，并提取用户configuration文件的信息（我们不使用BDC）。
然后我们通过重新search内容来重buildsearch索引。 这是一个痛苦，意味着search恢复的SLA很差，但是我们觉得这是最可靠的解决scheme。