我在完整恢复模型上有一个SQL Sever数据库（版本2012）。我开始将我的职责扩展到“管理员”方面（到目前为止我一直是一名查询撰稿人）。
我了解到.ldf文件与MDF（1.5 GB）相比非常大（80 GB）。
我使用非常简单的术语在线搜索（“为什么我的LDF文件如此之大？”并看到一个常见的响应：我需要运行频繁的事务备份。我试着这样做（在首次运行完整和差异备份之后）并且“没有足够的驱动器空间”错误。
现在使用此数据库运行事务备份是否为时已晚？我在考虑创建一个相同的数据库，将数据复制到第二个数据库，然后启动备份例程。然后，我必须在依赖当前数据库名称的许多查询和.net页面中进行大量的名称更改。
我读错了吗？有没有办法我现在可以开始运行事务备份，或者它是有问题的数据库的原因？
由于
答案 0 :(得分：1)
您已经完成了，但这是一个更好的答案：
一般来说，您不想缩小日志文件。但是，这里几乎肯定存在错误，因为日志文件可能不应该是数据库大小的50倍。
首先，您需要了解数据库文件的工作原理。数据库文件从文件系统中分配，除非告知缩小，否则SQL Server永远不会将其返回。它几乎就像一个磁盘分区。如果系统需要磁盘空间，则保留磁盘空间。在适当的管理下，DBA知道他的数据库需要多少空间并相应地设置大小。他还知道他的事务日志需要多少，并相应地设置它们的大小。随着数据的添加，更新和删除，数据量发生了变化，但服务器永远不必向操作系统询问更多空间，因为它都是为了计划的！因此，重要的一步是了解数据库的利用方式以及数据的增长速度。监视DB文件和事务日志文件的用法，并相应地进行规划。一旦您处于定期清除旧数据的位置，增长事件应该是罕见的，并且事务日志增长事件应该是最小的，除非您对数据库进行了重大的更改操作。
接下来，您需要了解Full recovery model的工作原理。在完全恢复模式下，您必须执行常规定期数据库备份以及定期事务日志备份。在完全恢复下，无论您在数据库上执行何种备份，单独备份数据库都不会刷新事务日志。刷新事务日志（即标记空间可供使用）的唯一方法是备份事务日志。在我们的环境中，我们每晚运行一次完整数据库备份，并在设置为完全恢复的数据库上每天15分钟进行一次事务日志备份。
＆＃34;但这对屁股来说是一个巨大的痛苦！＆＃34;你说。 ＆＃34;我也不想备份交易日志。我没有备份空间，如果我们丢失了返回上一次数据库备份的数据，我们也不在乎。＆＃34;
啊，那么你需要问一下你是否真的需要完全恢复模式。完全恢复模式唯一真正的好处是时间点恢复。让我们说，会计中的爱丽丝刚刚在午餐前的周三早上完成了财务系统的工资单。然后，在午餐后的星期三，Bob CXO意外删除了系统中的工资核算。哎呀。通过时间点恢复，您可以说，＆＃34;在Bob取消我的薪水之前将数据库恢复到正确的状态，＆＃34;并且Alice不需要重做所有工资单。
使用简单恢复，您仍然可以进行数据库备份，但您不必担心事务日志。他们仍然需要系统如何回滚交易等，但他们在数据库恢复期间无法帮助您。系统本身将管理日志空间，根据需要定期截断日志。但是，仅可以根据您备份数据库文件的时间来访问恢复。您无法重播日志以达到某个时间点。如果每8小时进行一次数据库备份，那么只能恢复到备份数据库的时间。它全有或全无。
第三种方法Bulk Logged是两者之间的分歧。您可以使用事务日志进行恢复，并且需要备份事务日志，但只能以块的形式进行恢复。它主要用于完全恢复数据库的异常维护任务，例如年终翻转和清除系统脱机的情况。它会导致日志使用更少的空间，但它缺乏很多功能。如果我是你，我不会担心这个。
如果我是你，我会做的是以下内容：
在业务领导的帮助下确定他们对灾难恢复的期望。主要问题是，＆＃34;如果出现数据库问题，我们愿意花多少时间丢失？＆＃34; ＆＃34;数据库问题＆＃34;可能意味着磁盘发生故障或者Bob CXO再次返回系统并删除另一个工资核算运行。如果您确定需要完全恢复，那么您将拥有更复杂的备份和恢复过程。您需要备份数据库，并备份日志。如果您使用简单恢复，请记住您唯一的保护是您运行的数据库备份。
根据需要设置备份，DB仅适用于Simple，DB适用于Full适用。
监控您的交易日志使用情况。 SQL Server Management Studio 2008+中有一个内置报告，可以显示数据文件的利用率。在每次数据库备份和每个日志备份之前检查一下。简单将更难捕获，因为它可以在它决定的任何点截断（刷新），但跟踪它。
测试您的备份！熟悉如何恢复数据库！您可以将数据库还原到同一服务器上的其他服务器或不同的数据库。如果选择完全恢复，请使用时间点恢复。你想知道在之前它是如何工作的。它并不难，但像所有的RDBMS一样，它很挑剔。
当您对交易日志所需的日志使用量感到满意时，现在可以缩小您的交易日志。不要将它们缩小到1 MB。将它们缩小到您知道系统所需的空间量。给自己额外的空间来解决错误。我认为您希望至少比监控建议多20％，但请记住，大量的插入，更新，删除，索引重建，表创建，统计更新等都会导致事务日志成长。基本上数据和元数据中的每个更改都会记录在那里。
还有一件事。收缩事务日志时，第一次执行时，它通常不会完全收缩。事务日志在内部分解为页面或块。它不会移动到文件的开头只是因为开头标记为空闲。它将使用接下来的任何内容，直到它到达文件的末尾，然后移动到开头。第一次告诉它缩小时，您很可能会缩小到系统当前使用的页面。你做的是继续使用数据库，并在几个小时内再次尝试。很可能服务器已经移动到该页面的末尾并返回到事务日志文件的开头。您可以将日志文件缩小到所需的大小。
答案 1 :(得分：0)
您只需从SSMS运行收缩日志，并将LDF文件剪切为小尺寸。还可以选择将日志切换为简单模型，它始终是小文件。缺点是您无法对最近的操作进行回滚 - 但在某些情况下没有必要。