收縮資料庫與收縮日誌
請按步驟進行 未進行前面的步驟時 請不要做後面的步驟 以免損壞你的資料庫
一般不建議做第 兩步 第 步不安全 有可能損壞資料庫或丟失數據 第 步如果日誌達到上限 則以後的資料庫處理會失敗 在清理日誌後才能恢復
清空日誌
DUMP TRANSACTION 庫名 WITH NO_LOG
截斷事務日誌
BACKUP LOG 資料庫名 WITH NO_LOG
收縮資料庫文件(如果不壓縮 資料庫的文件不會減小
企業管理器 右鍵你要壓縮的資料庫 所有任務 收縮資料庫 收縮文件
選擇日誌文件 在收縮方式里選擇收縮至XXM 這里會給出一個允許收縮到的最小M數 直接輸入這個數 確定就可以了
選擇數據文件 在收縮方式里選擇收縮至XXM 這里會給出一個允許收縮到的最小M數 直接輸入這個數 確定就可以了
也可以用SQL語句來完成
收縮資料庫
DBCC SHRINKDATABASE(客戶資料)
收縮指定數據文件 是文件號 可以通過這個語句查詢到:
select * from sysfiles
DBCC SHRINKFILE( )
為了最大化的縮小日誌文件(如果是sql 這步只能在查詢分析器中進行)
a 分離資料庫:
企業管理器 伺服器 資料庫 右鍵 分離資料庫
b 在我的電腦中刪除LOG文件
c 附加資料庫:
企業管理器 伺服器 資料庫 右鍵 附加資料庫
此法將生成新的LOG 大小隻有 多K
或用代碼
下面的示例分離 pubs 然後將 pubs 中的一個文件附加到當前伺服器
a 分離
EXEC sp_detach_db @dbname = pubs
b 刪除日誌文件
c 再附加
EXEC sp_attach_single_file_db @dbname = pubs
@physname = c:/Program Files/Microsoft
SQL Server/MSSQL/Data/pubs mdf
為了以後能自動收縮 做如下設置
企業管理器 伺服器 右鍵資料庫 屬性 選項 選擇 自動收縮
SQL語句設置方式:
EXEC sp_dboption 資料庫名
autoshrink TRUE
如果想以後不讓它日誌增長得太大
企業管理器 伺服器 右鍵資料庫 屬性 事務日誌
將文件增長限制為xM(x是你允許的最大數據文件大小)
SQL語句的設置方式:
lishixin/Article/program/SQLServer/201311/22266
Ⅱ SQL Server實用經驗技巧集（1）
此文是Sql Server實用操作小技巧集合 包括安裝時提示有掛起的操作 收縮資料庫 壓縮資料庫 轉移資料庫給新用戶以已存在用戶許可權 檢查備份集 修復資料庫等 （一）掛起操作 在安裝Sql或sp補丁的時候系統提示之前有掛起的安裝操作 要求重啟 這里往往重啟無用 解決辦法 到HKEY_LOCAL_ Manager刪除PendingFileRenameOperations （二）收縮資料庫 重建索引DBCC REINDEXDBCC INDEXDEFRAG 收縮數據和日誌DBCC SHRINKDBDBCC SHRINKFILE （三）壓縮資料庫 dbcc shrinkdatabase(dbname) （四）轉移資料庫給新用戶以已存在用戶許可權 exec sp_change_users_login update_one newname oldname go （五）檢查備份集 RESTORE VERIFYONLY from disk= E:dvbbs bak （六）修復資料庫 ALTER DATABASE [dvbbs] SET SINGLE_USERGODBCC CHECKDB( dvbbs repair_allow_data_loss) WITH TABLOCKGOALTER DATABASE [dvbbs] SET MULTI_USERGO CHECKDB 有 個參數: REPAIR_ALLOW_DATA_LOSS 執行由 REPAIR_REBUILD 完成的所有修復 包括對行和頁進行分配和取消分配以改正分配錯誤 結構行或頁的錯誤 以及刪除已損壞的文本對象 這些修復可能會導致一些數據丟失 修復操作可以在用戶事務下完成以允許用戶回滾所做的更改 如果回滾修復 則資料庫仍會含有錯誤 應該從備份進行恢復 如果由於所提供修復等級的緣故遺漏某個錯誤的修復 則將遺漏任何取決於該修復的修復 修復完成後 備份資料庫 REPAIR_FAST 進行小的 不耗時的修復操作 如修復非聚集索引中的附加鍵 這些修復可以很快完成 並且不會有丟失數據的危險 REPAIR_REBUILD 執行由 REPAIR_FAST 完成的所有修復 包括需要較長時間的修復（如重建索引） 執行這些修復時不會有丟失數據的危險 DBCC CHECKDB( dvbbs ) with NO_INFOMSGS PHYSICAL_ONLY SQL SERVER日誌清除的兩種方法 在使用過程中大家經常碰到資料庫日誌非常大的情況 在這里介紹了兩種處理方法…… 方法一 一般情況下 SQL資料庫的收縮並不能很大程度上減小資料庫大小 其主要作用是收縮日誌大小 應當定期進行此操作以免資料庫日誌過大 設置資料庫模式為簡單模式 打開SQL企業管理器 在控制台根目錄中依次點開Microsoft SQL Server >SQL Server組 >雙擊打開你的伺服器 >雙擊打開資料庫目錄 >選擇你的資料庫名稱（如論壇資料庫Forum） >然後點擊右鍵選擇屬性 >選擇選項 >在故障還原的模式中選擇 簡單 然後按確定保存 在當前資料庫上點右鍵 看所有任務中的收縮資料庫 一般裡面的默認設置不用調整 直接點確定 收縮資料庫完成後 建議將您的資料庫屬性重新設置為標准模式 操作方法同第一點 因為日誌在一些異常情況下往往是恢復資料庫的重要依據 方法二 SET NOCOUNT ONDECLARE @LogicalFileName sysname @MaxMinutes INT @NewSize INTUSE tablename 要操作的資料庫名SELECT@LogicalFileName = tablename_log 日誌文件名@MaxMinutes = Limit on time allowed to wrap log @NewSize = 你想設定的日誌文件的大小(M) Setup / initializeDECLARE @OriginalSize intSELECT @OriginalSize = sizeFROM sysfilesWHERE name = @LogicalFileNameSELECT Original Size of + db_name() + LOG is +CONVERT(VARCHAR( ) @OriginalSize) + K pages or +CONVERT(VARCHAR( ) (@OriginalSize* / )) + MB FROM sysfilesWHERE name = @LogicalFileNameCREATE TABLE DummyTrans(DummyColumn char ( ) not null)DECLARE @Counter INT @StartTime DATETIME @TruncLogVARCHAR( )SELECT@StartTime = GETDATE() @TruncLog = BACKUP LOG + db_name() + WITH TRUNCATE_ONLY DBCC SHRINKFILE (@LogicalFileName @NewSize)EXEC (@TruncLog) Wrap the log if necessary WHILE @MaxMinutes > DATEDIFF (mi @StartTime GETDATE()) time has not expiredAND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName)AND (@OriginalSize * / ) > @NewSizeBEGIN Outer loop SELECT @Counter = WHILE((@Counter < @OriginalSize / ) AND (@Counter < ))BEGIN updateINSERT DummyTrans VALUES ( Fill Log )DELETE DummyTransSELECT @Counter = @Counter + ENDEXEC (@TruncLog)ENDSELECT Final Size of + db_name() + LOG is +CONVERT(VARCHAR( ) size) + K pages or +CONVERT(VARCHAR( ) (size* / )) + MB FROM sysfilesWHERE name = @LogicalFileNameDROP TABLE DummyTransSET NOCOUNT OFF lishixin/Article/program/SQLServer/201311/22232
Ⅲ 收縮資料庫日誌的影響，資料庫日誌已滿，如何處理
--此為數據文件、資料庫日誌文件收縮操作語句
--保存時間：2017-1-9
--使用說明：
--「DataBase」為資料庫名稱，在進行數據收縮操作前，先做好數據備份
--將語句中的「DataBase」替換為需要進行數據收縮的資料庫名稱，如：test
--在進行資料庫收縮的時候，要留出操作時間，期間不要進行任何用戶操作
--確認無誤後，執行語句，即可進行數據收縮！
usemaster
go
_WAIT
go
go
declare@namevarchar(20)
declare@sqlvarchar(100)
select@name=namefromsys.database_fileswheretype=1
set@sql='DBCCSHRINKFILE(N'''+@name+''',11,TRUNCATEONLY)'
exec(@sql)
go
dbccshrinkdatabase(DataBase)
go
_WAIT
go
--設置恢復模式（'SIMPLE'表示簡單；'FULL'表示完整）
go
--設置資料庫兼容性級別為sql2008
_level=100
go
Ⅳ sql2008中如何收縮資料庫日誌文件
解決方法:
方法一
右鍵選擇資料庫-》任務-》收縮-》文件-》文件類型-》日誌-》在釋放未使用的空間前重新組織頁
方法二（不推薦）
1 必須先改成簡單模式
2 然後用
----Logical Files :
--CMS1.5_Data
--CMS1.5_Log
DBCC SHRINKFILE (N'CMS1.5_Log' , 1)
GO
註：Data是數據文件，Log是日誌文件
Ⅳ 資料庫日誌文件過大如何收縮
網頁鏈接我是用這個方法收縮的，可以將日誌收縮到1MB
守得雲開見月明,花了一個上午結合前輩的博客，終於弄好了sqlserver2008的資料庫日誌收縮到1MB，分享給大家
# 方法步驟
1、執行SQL語句改成「簡單模式」
2、收縮資料庫
3、執行SQL語句改回「完全模式」
## 第一步：執行SQL語句改成「簡單模式」
USE [master]
GO
ALTER DATABASE SlowXWebDB (改成你需要進行收縮的資料庫名) SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE SlowXWebDB (改成你需要進行收縮的資料庫名) SET RECOVERY SIMPLE --改成簡單模式
GO
## 第二步：進行資料庫操作
相關界面截圖和操作
假定：
資料庫名：SlowXWebDB
日誌文件名：SlowXWebDB_Log
## 第三步：執行SQL語句改成「完全模式」
USE [master]
GO
ALTER DATABASE SlowXWebDB (改成你需要進行收縮的資料庫名)SET RECOVERY FULL WITH NO_WAIT
GO
ALTER DATABASE datebaseName(改成你需要進行收縮的資料庫名)SET RECOVERY FULL --還原為完全模式
GO
==最後不要忘記實測下資料庫是否能夠正常使用==
網頁鏈接
Ⅵ sql server怎麼收縮日誌
1、首先選中資料庫右鍵--屬性 點擊
Ⅶ sql server 2008 r2如何收縮資料庫和文件
1、右擊資料庫選擇，打開Files窗口
2、Files窗口，File type 選擇 Log，單擊OK完成日誌收縮。
按以上方法操作沒有效果，原因是資料庫的恢復模式不是簡單模式，只需要將恢復模式改為簡單模式即可用以上操作來收縮日誌，方便又好用。
將資料庫恢復模式改為簡單模式方法：
1、右擊資料庫選擇屬性，彈出窗口如下圖，選擇Options選項，將 Recovery Model 改為 Simple 即可。
按如下方法操作也可收縮日誌：
1、當資料庫恢復模式為簡單時。使用dbcc shrinkfile (logfile_name,target_size)命令來完成。如
use mydb
dbcc shrinkfile (mydb_log,10) --將mydb_log收縮至10m
2、當資料庫恢復模式為完全時。可以先將資料庫模式改為簡單模式，再使用上述方法來進行。
use master
alter database mydb set recovery simple
dbcc shrinkfile (mydb_log,10) --將mydb_log收縮至10m
也可以直接備份事務日誌文件後再收縮：
use master
backup log mydb to disk='d:/dd.bak'
use mydb
dbcc shrinkfile (mydb_log,10) --將mydb_log收縮至10m;
3、通過分離資料庫，然後再刪除事務日誌文件，再附加mdf數據文件，也可以達到某種意義上的事務日誌收縮。
以下是有關日誌文摘
對於每一個資料庫來講，都需要至少一個事務日誌文件。事務日誌文件是整個資料庫的血液，如果沒有事務日誌的話，那麼將無法進行任何操作。
事務日誌有什麼東西？
事務日誌記錄著在相關資料庫上的操作，同時還存儲資料庫恢復(recovery)的相關信息。
事務日誌與資料庫恢復(recovery)是密切相關的，其實資料庫在啟動時，便會進行相關的恢復(recovery)操作，如下所示。當然，在資料庫還原時，也可以指定手工恢復(recovery).任何在資料庫上的改變，如果在事務日誌內被標記為已提交，並用一個LSN(LOG SEQUENCE NUMBER)來標識，同時相關改變就會體現在數據文件上，而被標記為未提交的改變將不會體現在數據文件上。
2010-01-12 18:31:48.72 spid7s Recovery is complete. This is an informationa message only. No user action is required.
事務日誌文件還存儲著資料庫需要回滾的相關信息。在SQL Server資料庫上，默認是隱式提交的，也就是說在查詢分析器裡面進行的每一個操作，在操作完成後，都是默認已經commit，但如果通過指定begin tran 和rollback tran的命令來標識事務時，rollback tran就需要使用事務日誌內的相關信息才可以回滾。當然，如果SQL Server遇到相關錯誤時，如死鎖，那麼也會產生一個內部回滾，這些都需要用到事務日誌文件。
為什麼要收縮事務日誌？
收縮日誌的原因有很多種，有些則是考慮空間不足，有些則是應用程序限制導致的，一般情況下，是不建議對事務日誌進行其他改變的，如需要控制事務日誌的大小，則可以通過安排事務日誌備份來解決。如果確定事務日誌包含將不再使用的未使用空間，則可以通過減少事務日誌的大小，以便回收過多空間。但這種情況對於一個DBA來講，應該要盡量避免。
僅當資料庫處於聯機狀態，而且至少一個虛擬日誌文件可用時，收縮才會發生。在某些情況下，直到下一個日誌截斷後，才能收縮日誌。
事務日誌收縮的原理:
每個事務日誌由多個虛擬日誌文件組成(virtual log file).虛擬日誌文件沒有固定的大小，也沒有固定的個數。在創建事務日誌文件或者擴展事務日誌文件時，SQL SERVER便會自動創建合適大小的虛擬日誌文件，DBA無法控制虛擬日誌文件的大小和個數。在擴展日誌文件後，虛擬文件的大小是現有日誌大小和新文件增量大小之和。因此，如果在創建資料庫時，對資料庫指定了比較小的初始大小，又指定了比較小的日誌增長量，隨著事務日誌的自動擴展，虛擬日誌文件個數會越來越多，從而影響了資料庫性能。因此，在創建資料庫時，盡量指定比較合適的初始事務日誌大小，同時指定合理的事務日誌增長量，這點可以參考數據文件的標准。如果大於10G或者更大的話，則指定固定的增長量，如果比較小，則指定按百分比的增長量來進行。
詳情參考
http://hi..com/lxiangshanyu/item/7057ce04081efae9fe240d64