Paul Randal问了一些有关SharePoint SQL数据库最佳实践的非常好的问题。 今天，在帮助客户维护SharePoint安装的同时，他问我一个关于SharePoint数据库的最佳SQL恢复模型的问题。 这是我的做法（我不是DBpipe理员:)）））使用简单的恢复模式。 如果定期备份SharePoint数据库，并且在项目级别还有第三方工具备份，则实际上不需要保留整个日志。 我在这里错过了什么？ 这是正确的方法吗？ 你有没有使用SharePoint数据库日志来恢复您的数据？
我们正在寻找一个替代品。 我们正在寻找一个运行在apache2上的开源应用程序。 它应该基本上是一个文件存储与评论。 与AD集成来pipe理权限。 我们一直在寻找几天，但多个人的谷歌失败了。 我们已经尝试过Alfresco，但是对于我们来说（tomcat）运行得非常慢。 我们正在研究Django的CMS，但它似乎是错误的事情（build立了不同的东西）
我负责使用Joomla创build一个Web服务器和Intranet站点，以创build一个微软Sharepoint的替代scheme，并且希望得到一些关于如何开始的步骤以及如何开始的build议。 有一点背景是，我们使用了我们的SBS服务器附带的Sharepoint，并已迁移到Server 2003，并希望有一个解决scheme可以免费或成本的一小部分可以Sharepoint的。 理想情况下，我们希望它成为员工使用内部新闻的最新时间，有一个日历，并链接到存储的文件，如SOP（标准操作程序）。 我希望这个解释好一点，对于我的第一篇文章中如此不清楚，感到抱歉！
SharePoint 2007带有一个内置的备份工具，但是我已经听到了坏消息。 也就是说，你可以备份但不能恢复configuration数据库，一般来说恢复总是一个信念的考验。 我想知道是否有一些“最佳实践”或强大的备份（和还原）解决scheme？
这不是一个我该怎么做的问题，只是为了设置舞台。 这是你有什么经验？ 在快速回复之前，请仔细阅读整个问题。 我昨天花了一天的时间教导SharePoint MCM（微软authentication大师 – 请看这里 ）的学生所有关于SQL Server中的高可用性技术，以及SQL日志/恢复/备份/恢复如何工作。 这是非常重要的，因为每个企业级的MOSS安装都是隐藏起来的Entreprise级SQL Server，通常没有DBA。 Kimberly在星期五教他们一天的数据库维护（一种SQL MCM第一周缩减版）。 我们正在讨论使用数据库镜像为SharePoint数据库提供高可用性的可能性，以及相对的优缺点。 现在，我知道数据库镜像的内部深度最低，因为我曾经在微软拥有它，所以不需要在回复中指出行为和特质。 我也知道来自SharePoint人员的白皮书中的各种警告和指导原则，是的，他们只是通用的指导方针而不是硬性规定。 我的问题是这样的：我希望听到任何实施SharePoint的数据库镜像的人，以及是否发现它适用于您，或者您崩溃和烧毁。 特别是，您是如何find故障转移行为为您工作的？ 你是否在一台服务器上有一些数据库负责人，另一些人是否有效地分割了你的服务器，并使其无法使用，直到手动干预将所有事情都转移到一台服务器上？ 你使用它为本地或远程HA？ 等等。 任何回复都将受到感谢，并将有助于拓宽与这两种技术结合的知识库，并将故事情节回馈到SharePoint产品组以及我所教授的未来MCM轮换。 谢谢！ [编辑：PS我会在这个周末也把关于经验和指导方针的博客文章放在一起]
在Microsoft平台中，大多数企业级程序（SharePoint，任何System Center应用程序，任何Dyamics应用程序等）都运行在SQL Server之上。 对于这些程序的pipe理员来说，SQL Server通常是一个黑匣子，作为其主要关注的任何程序的先决条件。 因此，安装的SQL方面的计划很less（如果有的话），导致出现在更上游的问题。 事务日志填充驱动器 没有维护计划（或者不知情的维护计划，比如重组和重build索引的计划） 不受pipe理的自动增长 数据库和日志在相同的主轴上 select的RAID级别不佳 没有备份（或恢复计划） 那么……“意外的数据库pipe理员”往往会遇到哪些types的问题，哪些资源最能帮助意外的DBA加快SQL计划，pipe理和性能调优基础？