如何從SQL Server 2008中刪除.ldf文件？

Question

在此先感謝

如果我停止SQL Server，然後將.LDF文件（transactionlog文件）刪除到數據庫，會發生什麼情況？數據庫會被標記爲可疑還是SQL Server會自動創建一個新的？ SQL Server 2008 R2的 和我的.LDF文件尺寸太大，因此，如何管理它，我是否能縮小或刪除 PLZ在查詢表

推薦

感謝

Answer 1

正如你可以閱讀評論，刪除日誌並不是一個好的解決方案。但是，如果你確信你不會失去任何東西，你可以改變你的數據庫恢復模式簡單，然後使用

DBCC shrinkdatabase ('here your database name')

清除日誌。

你可以做的最糟糕的事情就是從磁盤上刪除日誌文件。如果您的服務器在服務器停止時有未完成的事務，那麼在重新啓動後這些事務將不會回滾，並且您將收到損壞的數據。

Answer 2

您不應該刪除任何數據庫文件，因爲它會嚴重損壞您的數據庫！

如果磁盤空間不足，則可能需要將數據庫拆分爲多個部分。這可以在數據庫的屬性中完成。因此，您可以將數據庫的每個部分放到不同的存儲卷中。

您還可以收縮事務日誌文件，如果你從完全更改恢復模式簡單，使用下面的命令：

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

切換回完全恢復是可能的：

ALTER DATABASE myDatabase SET RECOVERY FULL 

更新有關SHRINKDATABASE - 或者是什麼我不知道回答這個問題時：

ALTH儘管上面的方法擺脫了一些未使用的空間，但它對數據庫文件（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 3

您應該備份您的事務日誌，然後將有可用空間來收縮它。更改爲簡單模式然後縮小意味着您將丟失所有事務數據，這些事務數據在恢復時很有用。

Answer 4

我做到了由

• 分離數據庫（包括刪除連接）
• 刪除* .LDF文件
• 附加數據庫，但除去預期的*。LDF文件

這樣做是爲了4個不同的數據庫，在2012年的SQL，我應該是相同的SQL 2008

Answer 5

不要冒險手動刪除您的LDF文件！如果您不需要事務文件或希望減少他們選擇的任何大小，請按照下列步驟操作： （注意：這會影響你的備份才這樣做的，所以一定）

1. 右擊數據庫
2. 選擇屬性
3. 點擊'選項'標籤。
4. 一套恢復模型SIMPLE
5. 下一步，選擇文件選項卡
6. 現在確保你選擇的日誌文件，並向右滾動。在「自動增長」的標題點擊點....
7. 然後禁用自動增長（這是可選的，將限制額外增長）
8. 然後單擊確定，將「初始大小」，以您希望的大小（我設置爲20MB）
9. 單擊確定保存更改
10. 然後再次右鍵單擊數據庫，然後選擇「任務>收縮>數據庫」，然後按確定。
11. 現在比較您的文件大小:)

Answer 6

的最佳方式在MS SQL服務器的所有數據庫清除所有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://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/recovery-models-sql-server

有時值得在某些數據庫上永久啓用RECOVERY MODEL = SIMPLE，從而一勞永逸地擺脫日誌問題。特別是當我們每天備份數據（或服務器）時，從安全的角度來看，白天的變化並不重要。