如何从 SQL Server 2008 中删除 .ldf 文件？

Question

如果我停止 SQL-server 然后删除数据库中的 .LDF 文件（事务日志文件），会发生什么？数据库会被标记为可疑还是 SQL 服务器会自动创建一个新数据库？ SQL Server 2008 R2 我的 .LDF 文件太大，那么如何管理它，是否可以缩小或删除它 请在查询表中提出建议。

Answer 1

您不应该删除任何数据库文件，因为它会严重损坏您的数据库！

如果磁盘空间不足，您可能需要将数据库拆分为多个部分。这可以在数据库的属性中完成。因此，您可以将数据库的每个部分放入不同的存储卷。

如果您使用以下命令将恢复模式从完整更改为简单，您还可以收缩事务日志文件：

ALTER DATABASE myDatabase SET RECOVERY SIMPLE
DBCC SHRINKDATABASE (myDatabase , 5)

也可以切换回完全恢复：

ALTER DATABASE myDatabase SET RECOVERY FULL

有关 SHRINKDATABASE 的更新 - 或者我不知道的内容在回答这个问题时：

虽然上面的方法摆脱了一些未使用的空间，但它对数据库文件（MDF）有一些严重的缺点 - 它会通过碎片化索引来损害你的索引，从而恶化数据库的性能。因此，您需要随后重建索引以消除收缩命令造成的碎片。

如果您只想缩小日志文件，可能需要使用 SHRINKFILE反而。我从 MSDN 复制了这个例子：

USE AdventureWorks2012;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2012
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2012_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2012
SET RECOVERY FULL;
GO

Answer 2

不要冒险手动删除 LDF 文件！如果您不需要交易文件或希望将其缩小到您选择的任何大小，请按照以下步骤操作：
（请注意，这将影响您的备份，因此在执行此操作之前请确保）

1. 右键单击数据库
2. 选择属性
3. 单击“选项”选项卡。
4. 将恢复模式设置为“简单”
5. 接下来，选择“文件”选项卡
6. 现在确保选择“日志”文件并向右滚动。在“自动增长”标题下单击点...
7. 然后禁用自动增长（这是可选的，将限制额外的增长）
8. 然后单击“确定”并将“初始大小”设置为您希望的大小（我将我的设置为 20MB）
9. 单击“确定”保存更改
10. 然后再次右键单击数据库，然后选择“任务 > 收缩 > 数据库”，然后按“确定”。
11. 现在比较您的文件大小！:)

Answer 3

我通过

• 分离数据库（包括删除连接）
• 删除*.ldf文件
• 附加数据库，但删除预期的*.ldf文件

在SQL 2012中对4个不同的数据库执行此操作，对于SQL 2008我应该是相同的

Answer 4

正如您可以阅读评论一样，删除日志并不是一个好的解决方案。但是，如果您确定没有丢失任何内容，则可以将数据库恢复模式更改为简单，然后使用

DBCC Shrinkdatabase（'这里是您的数据库名称'）

来清除日志。

最糟糕的事情就是从磁盘删除日志文件。如果您的服务器在服务器停止时有未完成的事务，这些事务在重新启动后将不会回滚，并且您将获得损坏的数据。

Answer 5

您应该备份事务日志，然后就有可用空间来缩小它。更改为简单模式然后收缩意味着您将丢失在恢复时有用的所有事务数据。

Answer 6

清除 MS SQL Server 中所有数据库中的所有 ldf 文件（事务日志文件）的最佳方法，如果所有数据库都已提前备份的话：

USE MASTER
print '*****************************************'
print '************ Czyścik LDF ****************'
print '*****************************************'

declare
   @isql varchar(2000),
   @dbname varchar(64),
   @logfile varchar(128),
   @recovery_model varchar(64)

   declare c1 cursor for 
   SELECT  d.name, mf.name as logfile, d.recovery_model_desc  --, physical_name AS current_file_location, size
   FROM sys.master_files mf
      inner join sys.databases d
      on mf.database_id = d.database_id
   --where recovery_model_desc <> 'SIMPLE'
   and d.name not in ('master','model','msdb','tempdb') 
   and mf.type_desc = 'LOG'
   and d.state_desc = 'online'   
   open c1
   fetch next from c1 into @dbname, @logfile, @recovery_model
   While @@fetch_status <> -1
      begin

      print '----- OPERATIONS FOR: ' + @dbname + ' ------'

      print 'CURRENT MODEL IS: ' + @recovery_model

      select @isql = 'ALTER DATABASE ' + @dbname + ' SET RECOVERY SIMPLE'
      print @isql
      exec(@isql)
      select @isql='USE ' + @dbname + ' checkpoint'
      print @isql
      exec(@isql)
      select @isql='USE ' + @dbname + ' DBCC SHRINKFILE (' + @logfile + ', 1)'
      print @isql
      exec(@isql)
      select @isql = 'ALTER DATABASE ' + @dbname + ' SET RECOVERY ' + @recovery_model
      print @isql
      exec(@isql)

      fetch next from c1 into @dbname, @logfile, @recovery_model
      end
   close c1
   deallocate c1

这是一个改进的代码，基于： https://www.sqlservercentral.com/Forums/Topic1163961-357-1.aspx

我建议阅读这篇文章： https://learn .microsoft.com/en-us/sql/relational-databases/backup-restore/recovery-models-sql-server

有时，在某些数据库上永久启用 RECOVERY MODEL = SIMPLE 是值得的，因此一劳永逸摆脱日志问题。特别是当我们每天备份数据（或服务器）时，从安全角度来看，白天的更改并不重要。