教你如何清除SQL日志
1．打開查詢分析器，輸入命令DUMP TRANSACTION 數據庫名 WITH NO_LOG2.
再打開企業管理器--右鍵你要壓縮的數據庫--所有任務--收縮數據庫--收縮文件--選擇日志文件--在 收縮方式裡選擇收縮至XXM,
這裡會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了。
清除Log有兩種方法：
1.自動清除法
開放數據庫選項 Trunc Log on Chkpt，使數據庫系統每隔一段時間自動清除Log。
此方法的優點是無須人工干預， 由SQL Server自動執行，並且一般不會出現Log溢滿的情況；缺點是只清除Log而不做備份。
2.手動清除法
執行命令“dump transaction”來清除Log。
以下兩條命令都可以清除日志：dump transaction with truncate_onlydump transaction with no_log 通常刪除事務日志中不活躍的部分可使用“dump transaction withtrancate_only”命令，這條命令寫進事務日志時，還要做必要的並發性檢查。
SYBASE提供 “dump transaction withno_log”來處理某些非常緊迫的情況，使用這條命令有很大的危險性，SQL Server會彈出一條警告信息。
為了盡量確保數據庫的 一致性，你應將它作為“最後一招”。
以上兩種方法只??清除日志，而不做日志備份，若想備份日志，應執行“dump transaction database_name to dumpdevice”命令。
PS:附一個更好的方法先分離數據庫後，直接刪除日志以後,再在查詢分析器 裡用exec sp_attach_single_file_db '數據庫名', '.mdf文件路徑' 命令附加數據庫。
OVER.在別的 地方看到的 不錯。
數據庫日志操作先提供一種復雜的方法壓縮日志及數據庫文件如下：
1.清空日志DUMP TRANSACTION 庫名 WITH NO_LOG
2.截斷事務日志：BACKUP LOG 數據庫名 WITH NO_LOG
3.收縮數據庫文件(如果不壓縮,數 據庫的文件不會減小企業管理器--右鍵你要壓縮的數據庫--所有任務--收縮數據庫--收縮文件
--選擇日志文件--在收縮方式裡選擇 收縮至XXM,這裡會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了
--選擇數據文件--在收縮方式裡選擇收縮至XXM,這 裡會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了
也可以用SQL語句來完成
--收縮數據庫DBCC SHRINKDATABASE(客戶資料)
--收縮指定數據文件,1是文件號,可以通過這個語句查詢到:select * from sysfilesDBCC SHRINKFILE(1)
4.為了最大化的縮小日志文件(如果是sql 7.0,這步只能在查詢分析器中進行)a.分離數據庫: 企業管理器--服務器--數據庫--右鍵--分離數據庫b.在我的電腦中刪除LOG文件c.附加數據庫: 企業管理器--服務器--數據庫--右鍵--附加數據庫此法將生成新的LOG，大小只有500多K或用代碼：下面的示例分離 pubs，然後將 pubs 中的一個文件附加到當前服務器。a.分離E X E C sp_detach_db @dbname = 'pubs'b.刪除日志文件c.再附加E X E C sp_attach_single_file_db @dbname = 'pubs',@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf'5.為了以後能自動收縮,做如下設置:企業管理器--服務器--右鍵數據庫--屬性--選項--選擇"自動收縮"--SQL語句設置方式:E X E C sp_dboption '數據庫名', 'autoshrink', 'TRUE'6.如果想以後不讓它日志增長得太大企業管理器--服務器--右鍵數據庫--屬性--事務日志 --將文件增長限制為xM(x是你允許的最大數據文件大小)--SQL語句的設置方式:alter database 數據庫名 modify file(name=邏輯文件名,maxsize=20)特別注意：請按步驟進行,未進行前面的步驟,請不要做後面的步驟否則可能損壞你的數據庫.一般不建議做第4,6兩步第4步不安全,有可能損壞數據庫或丟失數據第6步如果日志達到上限,則以後的數據庫處理會失敗,在清理日志後才能恢復. 另外提供一種更簡單的方法，本人屢試不爽，建議大家使用。更簡單的方法：1。右建數據庫屬性窗口--故障還原模型--設為簡單2。右建數據庫所有任務--收縮數據庫3。右建數據庫屬性窗口--故障還原模型--設為大容量日志記錄 可能有不少朋友遇到過這樣的問題：update或delete語句忘帶了where子句，或where子句精度不夠，執行之後造成了嚴重的後果，這種情況 的數據恢復只能利用事務日志的備份來進行，所以如果你的SQL沒有進行相應的全庫備份或不能備份日志（truncate log on checkpoint選項為1），那麼就無法進行數據的恢復了，或者只能恢復到最近一次的備份的數據了。 以下簡單說明恢復數據方法：1，如果誤操作之前存在一個全庫備份（或已有多個差異備份或增量備份），首先要做的事就是進進行一次日志備份（如果為了不讓日 志文件變大而置trunc. log on chkpt.選項為1那你就死翹了）backup log dbName to disk='fileName'2，恢復一個全庫備份，注意需要使用with norecovery，如果還有其他差異或增量備份，則逐個恢復restore database dbName from disk='fileName' with norecovery3，恢復最後一個日志備份即剛做的日志備份，指定恢復時間點到誤操作之前的時刻restore log dbName from disk='fileName'with stopat='date_time' 以上這些操作都可以在SQL SERVER企業管理器裡完成，難度不大。。。日志文件滿而造成SQL數據庫無法寫入文件時，可用兩種方法：一種方法：清空日志。1．打開查詢分析器，輸 入命令DUMP TRANSACTION 數據庫名 WITH NO_LOG2.再打開企業管理器--右鍵你要壓縮的數據庫--所有任務--收縮數據庫--收縮文件--選擇日志文件--在收縮方式裡選擇收縮至XXM, 這裡會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了。 另一種方法有一定的風險性，因為SQL SERVER的日志文件不是即時寫入數據庫主文件的，如處理不當，會造成數據的損失。1: 刪除LOG分離數據庫 企業管理器－＞服務器－＞數據庫－＞右鍵－＞分離數據庫
---------------------
SQL2005事務日志已滿的解決方案今 天打開網站,突然發現sql 2005出現錯誤:數據庫 'mybase_db' 的事務日志已滿。若要查明無法重用日志中的空間的原因，請參閱 sys.databases 中的 log_reuse_wait_desc 列。
在網上查了下,終於找到了解決辦法:
復制代碼 代碼如下:
--先備份數據庫
--截斷事務日志
backuplog mybase_dbwithno_log
go
--收縮數據庫
dbccshrinkdatabase(mybase_db)
go
OK,搞定
----------------
--SQL2005 自動備份的腳本
declare @DBName varchar(200)
set @DBName='ReportServer$SQL2005'
-- 截斷日志
DUMP TRANSACTION @DBName WITH NO_LOG
--收縮數據庫
DBCC SHRINKDATABASE (@DBName,TRUNCATEONLY)
--備份數據庫
USE master
declare @Version varchar(20)
declare @DateAppend varchar(20)
declare @BasePath varchar(200)
declare @BakPath varchar(200)
--設定備份的基本目錄
set @BasePath='f:\tmp'
--設定版本，每個版本的備份放在不同的地方
set @Version='V6.1'
--設定備份的完整路徑
set @BakPath=@BasePath+'\'+ @Version +'\Db.Bak'
USE master
--創建備份設備，如果存在則無需建立
if exists(select * from sysdevices where name='CTOS_DB_Bak')
begin
EXEC sp_dropdevice 'CTOS_DB_Bak'
declare @tmpcmd varchar(100)
set @tmpcmd='del ' + @BakPath
EXEC sp_configure 'show advanced options',1
RECONFIGURE
EXEC sp_configure 'xp_cmdshell', 1
RECONFIGURE
exec master..xp_cmdshell @tmpcmd
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
EXEC sp_configure 'xp_cmdshell', 0
RECONFIGURE
end
EXEC sp_addumpdevice 'disk','CTOS_DB_Bak',@BakPath
--備份數據庫
BACKUP DATABASE @DBName TO CTOS_DB_Bak
------------------------------------
建議更改數據庫的事務日志，限制文件增長的最大值和定期備份日志和數據。在以下處理之前，最好整體備份整個數 據庫：
1：由小的事務引起日志溢出，系統能正常啟動。
解決辦法：
擴大數據庫日志空間：
alter database 數據庫名 on 設備名=數量（M為單位）
sp_logdevice 數據庫名，設備名
清除日 志
dump transaction 數據庫名 with no_log(no_truncate)
2：由大的事物引起日志 溢出，系統較長時間內無法正常啟動或數據庫無法恢復
解決辦法：
強行清空日志。
在實在無法恢復數據庫或有近 期備份的情況下，可采用強行清空日志的方法。采取這種方法的後果有可能徹底破壞數據庫。執行步驟如下：
Ⅰ 以-v 方式啟動SQL SERVER(不檢測日志)
Ⅱ 修改數據庫狀態為-32768（阻塞狀態）
update sysdatabases set status=-32768 where name=數據庫名
Ⅲ 授權sybase_ts_role權限(sybase_ts_role為SQL SERVER特殊管理員權限，在日常的數據庫管理中，不需要這個角色）
sp_role “grant”,”sybase_ts_role”,sa
set role “sybase_ts_role”
Ⅳ 清除日志
dbcc rebuild_log(數據庫名，1，1)
完成以上步驟後，重新啟動SQL SERVER即可。如果數據庫能正常啟動，數據庫就恢復完成；如果無法啟動，只能重新創建數據庫。
=================================================================壓縮日志
1:截斷事務日志：
BACKUP LOG 數據庫名 WITH NO_LOG
2:清空 日志
DUMP TRANSACTION 庫名 WITH NO_LOG
再：
企業管理器--右鍵你要壓縮的數據庫 --所有任務--收縮數據庫--收縮文件--選擇日志文件--在收縮方式裡選擇收縮至XXM,這裡會給出一個允許收縮到的最小M數,直接輸入這個數,確定 就可以了
3: 刪除LOG
1：分離數據庫 企業管理器－＞服務器－＞數據庫－＞右鍵－＞分離數據庫
2：刪 除LOG文件
3：附加數據庫 企業管理器－＞服務器－＞數據庫－＞右鍵－＞附加數據庫
此法生成新的LOG，大小只有500多K
再 將此數據庫設置自動收縮
或用代碼：
下面的示例分離 pubs，然後將 pubs 中的一個文件附加到當前服務器。
復制代碼 代碼如下:
EXEC sp_detach_db @dbname = 'pubs'
EXEC sp_attach_single_file_db @dbname = 'pubs',
@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf'
4: 如果想以後不讓它增長
企業管理器--服務器--右鍵 數據庫--屬性--事務日志--將文件增長限制為xM(x是你允許的最大數據文件大小)
--SQL語句的設置方式:
alter database 數據庫名 modify file(name=邏輯文件名,maxsize=20)
5.設置為自動收縮
企 業管理器--服務器--右鍵數據庫--屬性--選項--選擇"自動收縮" sql2005 簡單恢復模式下 使用backup log with NO_log是否沒有意義？
-- 第一步：清空日志 DUMP TRANSACTION [YZGA] WITH NO_LOG -- 第二步：截斷事務日志 BACKUP LOG [YZGA] WITH NO_LOG -- 第三步：收縮數據庫 DBCC SHRINKDATABASE([YZGA]) ========================================================== 日志： 不推薦使用 BACKUP LOG WITH TRUNCATE_ONLY 或 WITH NO_LOG。應使用簡單恢復模式自動截斷事務日志。 有關更多信息，請參閱在 http://go.microsoft.com/fwlink/events.asp 的幫助和支持中心。 NO_LOG | TRUNCATE_ONLY 通過放棄活動日志以外的所有日志，無需備份復制日志即可刪除不活動的日志部分，並截斷日志。該選項會釋放空間。因為並不保存日志備份，所以沒有必要指定備 份設備。NO_LOG 和 TRUNCATE_ONLY 是同義的。 注意： 在 SQL Server 的未來版本中將刪除該選項。應避免使用該選項進行新的開發工作，並計劃修改當前使用它的應用程序。 使用 NO_LOG 或 TRUNCATE_ONLY 截斷日志後，記錄在日志中的更改不可恢復。為了進行恢復，請立即執行 BACKUP DATABASE 以執行完整備份或完整差異備份。 注意： 盡管可用該選項手動截斷事務日志，但是我們極力建議您不要這樣做，因為這會將日志鏈斷開。在下一次完整備份或完整差異備份之前，將無法為數據庫提供媒體故 障保護。只在非常特殊的情況下才手動截斷日志，並立即創建數據備份。 注意： 如果不想進行日志備份，請將數據庫設置為簡單恢復模式。
