在镜像生产数据库上收缩事务日志文件最简单的方法是什么？ 我必须，因为我的磁盘空间不足了。 在执行此操作之前，我会做一个完整的数据库备份，所以我不需要保留事务日志中的任何东西（对吗？我每天都有完整的数据库备份，可能永远不需要时间点恢复，尽pipe我会保留如果可以的话，这个选项是打开的 – 这就是所有的.ldf是真的，对吗？）。 解决了： OK， 通过SSMS （而不是TSQL）对日志进行2次备份 ，创build一个全新的备份集 ，SSMS中的Shrink-Files-Log对话框最终实际工作，释放了一些磁盘空间。 不知道为什么需要2个备份，或为什么TSQL不起作用，收缩对话框中报告的“可回收空间”没有差别（第一次备份之后的所有收缩尝试都是99％但是，仍然没有释放任何空间），但现在解决了问题。 谢谢大家。
我正在评估SQL Server 2008镜像（asynchronous），以提供更好的可用性。 我想知道，根据你的经验，如果SQL Server镜像是一个可靠和成熟的技术。 自动故障转移不是强制性的，但是很好。 因此，我正在分别评估镜像机制和自动故障转移机制。 镜像机制是否可靠？ 是否需要连续configuration和调整？ 自动故障切换选项是否可靠？ 是否需要连续configuration和调整？ 问候，
我需要用新的生产数据库副本replacetesting环境中的旧数据库。 testing环境实际上由两个不同服务器上的testing数据库实例组成，它们是镜像configuration（由于镜像是镜像，客户端希望testing环境就像生产一样）。 我认为这将是一个简单的问题： 获取生产数据库的备份（.bak文件） 暂时禁用testingDB的镜像 从（prod）备份覆盖（即：恢复）它们 重新激活镜像 但显然这还远远不够。 经过一天的摔跤（权限问题，神秘的错误，如果你重新启动SSMS（严重），我会留给你全部清单…）我终于得到了新的数据库恢复原理和testing数据库的镜像实例。 但是，在SQL Server的某处放弃了镜像configuration设置，所以我右键单击原理，select镜像，然后通过安全向导。 当我在安全向导的最后点击“完成”时，它做了这件事情，我得到了报告成功设置所有内容的屏幕（“configuration端点” – “成功”）。 紧接着是另一个窗口询问是否希望开始镜像，但是，单击该窗口上的开始，我得到以下SQL Server错误： 开始镜像时发生错误。 数据库“3DSS_TEST”未configuration为数据库镜像。 （Microsoft SQL Server，错误：1416） 所以我得到“镜像configuration成功！” 然后，作为同一过程的一部分，“镜像无法启动，因为您没有configuration！” 🙁 有任何想法吗？ 任何人之前看过这个，或知道如何挑出更有用的错误信息或其他信息？ 更新：解决 正如Brian在下面所说，我已经用错误的恢复选项恢复了镜像数据库，正确的方法是： RESTORE DATABASE [MyDb] FROM disk = 'C:\TEmp\MyDb_LIVE_Prod_backup_2010-06-18_for_test_server.bak' WITH REPLACE, NOrecovery /* This should be 'norecovery', my problem was I used 'recovery' */ 谢谢！
在sql server 2005 sp2中运行数据库镜像。 有需要发生SAN维护，我想知道，如果我停止故障转移合作伙伴（镜像）上的SQL Server和主体不断做日志备份，我需要重新初始化数据库镜像（完整备份）如果镜像离线了几天？ 我有一种感觉，我曾遇到过一些内在的限制。 我在网上找不到任何引用这个的东西，而且我没有时间去testing这个，因为SAN的人（不要和沙人混淆）想要现在这样做！ 我不打破镜子，并把合作伙伴联机，所以在交易日志链中没有任何中断。
我们刚从SQL Server 2000迁移到SQL Server 2008。 我们在2000年使用自己的日志传送进行故障转移。 对于2008年，我们需要决定使用我们自己的日志传送，内置日志传送或复制。 我们的服务器上有很多数据库（400+）; 有的小，有的大。 数据库服务器故障应该很less，我们可以接受15-30分钟的数据丢失。 更重要的是快速获得第二台数据库服务器。 根据上面的标准，我更喜欢日志传送还是复制？ 如果日志传送，有没有一种简单的方法来确保它移动到所有数据库？
我们公司的一位架构师在两个地理位置远的数据中心，devise了一个基于64位SQL2005标准版同步镜像的解决scheme，在物理（4个四核，32GB RAM）服务器和虚拟DR服务器（4个16GB RAM的虚拟CPU）见证服务器（1个虚拟CPU）。 存储是两个数据中心中的企业级SAN。 前端应用程序面向Web，具有混合的读/写使用。 作为一名DBA（在devise阶段没有咨询过），我很担心这个configuration的devise是以冗余度最小化为主要标准，而不是作为真实世界的解决scheme – networking延迟和虚拟性能盒子会造成不可接受的响应时间？ 如果调用故障切换，则性能更差。 有没有人有类似的设置经验？
我正在寻求将数据库“移动”到不同的服务器，而对数据和服务的影响最小。 这些数据库大小从5GB到140 GB不等。 我已经看到，甚至使用了SQL Server的各种数据传输工具，但我不确定最佳做法是什么（分离/重新附件，从备份还原，交易日志，镜像…）。 我最担心的是这些数据库有很多存储过程，用户权限和各种索引，我不想丢失它们，最终中断服务。 我最新的想法是build立一个镜像，然后启动手动故障转移 。 但是，在继续我以前从未做过的事情之前，我宁愿问一下。 TL; DR移动SQL Server数据库的最佳实践方式是什么，可以最大限度地减less服务中断的威胁。
这不是一个我该怎么做的问题，只是为了设置舞台。 这是你有什么经验？ 在快速回复之前，请仔细阅读整个问题。 我昨天花了一天的时间教导SharePoint MCM（微软authentication大师 – 请看这里 ）的学生所有关于SQL Server中的高可用性技术，以及SQL日志/恢复/备份/恢复如何工作。 这是非常重要的，因为每个企业级的MOSS安装都是隐藏起来的Entreprise级SQL Server，通常没有DBA。 Kimberly在星期五教他们一天的数据库维护（一种SQL MCM第一周缩减版）。 我们正在讨论使用数据库镜像为SharePoint数据库提供高可用性的可能性，以及相对的优缺点。 现在，我知道数据库镜像的内部深度最低，因为我曾经在微软拥有它，所以不需要在回复中指出行为和特质。 我也知道来自SharePoint人员的白皮书中的各种警告和指导原则，是的，他们只是通用的指导方针而不是硬性规定。 我的问题是这样的：我希望听到任何实施SharePoint的数据库镜像的人，以及是否发现它适用于您，或者您崩溃和烧毁。 特别是，您是如何find故障转移行为为您工作的？ 你是否在一台服务器上有一些数据库负责人，另一些人是否有效地分割了你的服务器，并使其无法使用，直到手动干预将所有事情都转移到一台服务器上？ 你使用它为本地或远程HA？ 等等。 任何回复都将受到感谢，并将有助于拓宽与这两种技术结合的知识库，并将故事情节回馈到SharePoint产品组以及我所教授的未来MCM轮换。 谢谢！ [编辑：PS我会在这个周末也把关于经验和指导方针的博客文章放在一起]