sqlserver2000收縮
首先將你要將壓縮的資料庫設置為簡單日誌模式
B. SQL Server 2000資料庫的事務日誌文件過大，如何將其縮小
拷獯穡涸贇QL Server中，所有對資料庫執行的更新操作都會記錄在資料庫的事務日誌文件中，除非將資料庫設為可自動收縮的或手動 的對資料庫進行了收縮，否則事務日誌文件將一直增長，直到達到事先設定的日誌文件增長上限或用盡所有可用的磁碟空間。如果當前的資料庫文件或日誌文件過大，可以使用以下兩個命令對其進行收縮：DBCC SHRINKDATABASE：收縮指定資料庫的所有數據和日誌文件的大小DBCC SHRINKFILE： 收縮資料庫的某個指定數據或日誌文件的大小 這兩個命令可以釋放資料庫中的空閑空間，並將資料庫或指定的資料庫文件收縮到指定的大小，但收縮後的數據文件或日誌文件的大小不會小於檔中現存的有效數據所佔空間的大小。 關於這兩個命令的具體使用方法，可以參考SQL Server 2000聯機叢書中的相應主題。另外，也可在SQL Server企業管理器中執行資料庫收縮，同樣是調用的以上兩個命令，效果類似。 在使用以上命令收縮日誌文件的時候需要注意，已寫入資料庫但未被截斷的事務日誌記錄是不會被收縮的，因為雖然這部分日誌記錄的信息已經寫入資料庫文件，但在使用事務日誌備份進行資料庫還原的時候，還將用到其中的信息。 對於使用簡單恢復模型的資料庫，事務日誌會在每次處理檢查點（CheckPoint）時自動被截斷。對於使用完全恢復模型或大容量日誌記錄恢復模型的資料庫，事務日誌只有在執行日誌備份（BACKUP LOG）時才會被截斷，這時事務日誌中記錄的信息被寫入事務日誌備份文件，而它們所佔用的這部分空間被標記為可用（即被截斷）。 截斷事務日誌並不會使日誌文件變小，但可以將其中的部分空間釋放供以後寫入新的日誌記錄使用。若要減少日誌文件的物理大小，則要使用上面提到的DBCC SHRINKDATABASE和DBCC SHRINKFILE命令。 在執行BACKUP LOG語句的時候，還可以使用WITH NO_LOG（或WITH TRUNCATE_ONLY，含義相同）參數，這時並不真正備份事務日誌，而只是截斷事務日誌中的非活動部分（這和普通的BACKUP LOG語句作用相同）。這適合於剩餘磁碟空間不夠進行事務日誌備份或不打算保留事務日誌中的非活動部分用於資料庫恢復的情況。 為避免事務日誌文件增長過快以致用盡所有磁碟空間的現象發生，一種辦法是將資料庫設為使用簡單恢復模型，這樣可以使SQL Server周期性的自動截斷事務日誌的非活動部分，並回收其佔用的空間供以後寫入事務日誌記錄使用。但這將使資料庫無法利用事務日誌備份還原到實時點，降低了資料庫的可靠性，因此一般不應用於生產型資料庫。 對於生產型資料庫，推薦的做法是使用完全恢復模型，並定期進行資料庫的完全備份和事務日誌備份。例如每周執行一次完全備份，每天執行一次事務日誌備份，這可以通過SQL Server企業管理器中的資料庫維護計劃向導很方便的實現（一般可以設為在每天夜裡業務不繁忙的某個時刻自動執行備份）。 通過定期執行資料庫的事務日誌備份，可以避免日誌文件的迅速增大，而使其保持一個比較穩定的大小。雖然資料庫備份文件也會佔用很多磁碟空間，但隨時可以將這些文件移到其他磁碟上或在不需要它們的時候將其刪除，而且可以在出現故障或誤操作的時候方便的進行資料庫的還原。 由於數據文件的大小是隨資料庫中數據量的增長而增長的，資料庫中已刪除的數據所佔的空間可以供新插入的資料使用；而在定期執行了事務日誌的備份後，我們可以將日誌文件的大小控制在一個比較合理的范圍。因此，一般不需要對資料庫進行收縮，也不推薦將資料庫設為自動收縮模式。建議僅在以下情況下執行資料庫的收縮：1、磁碟空間不足2、數據文件很大，但其中只包含較少量的數據（可能是以前有大量數據，但後來刪除了很多），並且預期今後資料庫中的數據量也不會很大。3、由於長期未進行事務日誌備份，導致事務日誌文件過大。減小事務日誌文件大小的另一種方法是：首先在該資料庫中執行CHECKPOINT命令，然後將該資料庫分離（Detach），再將與其對應的資料庫日誌文件（.ldf文件）改名或刪除或移動到其他目錄下，然後執行sp_attach_single_file_db存儲過程或在企業管理器中重新將其附加（Attach）。由於找不到原來的日誌文件，SQL Server將自動為該資料庫建立一個大小隻有504K的日誌文件。但這種方法必須暫時將資料庫離線，因此一般不適宜在生產環境中使用。如果當前資料庫的事務日誌文件過大，必須對其進行收縮的話，建議參照以下步驟：1、建議首先備份資料庫（但不是必需的）：BACKUP DATABASE database_name TO backup_device
2、備份事務日誌：BACKUP LOG database_name TO backup_device如果不需要當前事務日誌中的記錄進行資料庫還原或沒有足夠的空間進行事務日誌備份的的話，也可僅執行以下命令截斷事務日誌：BACKUP LOG database_name WITH NO_LOG
3、收縮日誌文件：DBCC SHRINKFILE (log_file_name)其中log_file_name是事務日誌文件的邏輯名稱，可以在企業管理器中資料庫屬性的「事務日誌」頁中看到（如Northwind資料庫的默認事務日誌文件邏輯名稱為Northwind_log）。4、如果日誌文件仍然較大的話，可以嘗試重復執行一次BACKUP LOG WITH NO_LOG和DBCC SHRINKFILE命令。5、如果這時仍沒有明顯的效果，請執行DBCC OPENTRAN (database_name)檢查當前資料庫中是否存在長時間未提交的活動事務。有必要的話，可以斷開這些連接並重新嘗試截斷事務日誌和收縮日誌文件。6、日誌文件收縮完成後，建議立即執行一次資料庫的完全備份並根據實際需要制定適當的資料庫備份計劃。
C. sql收縮資料庫日誌的幾種辦法
在SQL Server 2000/2005中可以快速壓縮日誌log文件，通過SQL,
方法一：
--BigData為資料庫名
DUMPTRANSACTIONBigDataWITHNO_LOG
BACKUPLOGBigDataWITHNO_LOG
DBCCSHRINKDATABASE(BigData)
執行以上語句可以快速壓縮日誌文件到1M。
但是以上語句中前兩行在SQL Server 2008下無法執行 ，
第一行提示「Incorrect syntax near the keyword 'TRANSACTION'.」
第二行提示「One or more of the options (no_log) are not supported for this statement. Review the documentation for supported options. 」
第三行可以執行。但日誌log文件沒有任何變化。
原來SQL Server 2008已經不再支持DUMPTRANSACTION和BACKUP LOG WITH NO_LOG，
sql Server 2005說明中明確：包含 DUMP 語句是為了向後兼容。而 後續版本的 Microsoft SQL Server 將刪除該功能。請避免在新的開發工作中使用該功能，並著手修改當前還在使用該功能的應用程序。 使用 BACKUP。
SQL Server 2008說明：BACKUP LOG WITH NO_LOG 和 WITH TRUNCATE_ONLY 選項已廢止。使用完整恢復模式或大容量日誌恢復模式時，如果必須刪除資料庫中的日誌備份鏈，請切換至簡單恢復模式。有關詳細信息，請參閱有關從完整恢復模式或大容量日誌恢復模式切換的注意事項。
方法二：
useDB_NAME
sp_dboptionDB_NAME,"trunc.logonchkpt.",true
checkpoint
sp_dboptionDB_NAME,"autoshrink",true
方法三：（請提前備份文件！！）
Detach資料庫。
刪除log文件。
附加資料庫，選移除log文件，此時SQL Server 會自動重新建立一個512K 的Log 文件。
方法四：
USEBigData;
GO
BACKUPLOGDATABASENAMETODISK='d: est.bak'
--.
DBCCSHRINKFILE(Bigdata_Log,1);
GO
D. 高手請進sql server 2000 收縮，會不會導致數據丟失
1 .資料庫收縮，不會導致數據丟失
2. 寫進資料庫一條數據，這條數據是寫進數據文件中（.MDF） 同時也將寫進資料庫一條數據的這件事 記錄到日誌文件中（.LDF）
這個簡單可以這么理解，不過還有保存點啊之類的概念。
3. 並沒有將這條數據寫入 日誌文件中 這個就不知道什麼意思了
E. SQL資料庫收縮的工作原理是什麼
資料庫收縮的工作原理是：清理空白空間和日誌來實現。
空白空間：刪除表時，資料庫的空間不會自動縮小，隨著建的表越來越多，刪除操
作越來越多時候，數據文件就會越來越多。
日誌：是記錄你歷史操作的，沒用的都可以清除。
F. sql server2000資料庫 怎麼瘦身
/*--特別注意 請按步驟進行,未進行前面的步驟,請不要做後面的步驟 否則可能損壞你的資料庫. 一般不建議做第4,6兩步 第4步不安全,有可能損壞資料庫或丟失數據 第6步如果日誌達到上限,則以後的資料庫處理會失敗,在清理日誌後才能恢復. --*/ --下面的所有庫名都指你要處理的資料庫的庫名 1.清空日誌 DUMP TRANSACTION 庫名 WITH NO_LOG 2.截斷事務日誌： BACKUP LOG 庫名 WITH NO_LOG 3.收縮資料庫文件(如果不壓縮,資料庫的文件不會減小 企業管理器--右鍵你要壓縮的資料庫--所有任務--收縮資料庫--收縮文件 --選擇日誌文件--在收縮方式里選擇收縮至XXM,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了 --選擇數據文件--在收縮方式里選擇收縮至XXM,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了 也可以用SQL語句來完成 --收縮資料庫 DBCC SHRINKDATABASE(庫名) --收縮指定數據文件,1是文件號,可以通過這個語句查詢到:select * from sysfiles DBCC SHRINKFILE(1) 4.為了最大化的縮小日誌文件(如果是sql 7.0,這步只能在查詢分析器中進行) a.分離資料庫: 企業管理器--伺服器--資料庫--右鍵--分離資料庫 b.在我的電腦中刪除LOG文件 c.附加資料庫: 企業管理器--伺服器--資料庫--右鍵--附加資料庫 此法將生成新的LOG，大小隻有500多K 或用代碼： 下面的示例分離 pubs，然後將 pubs 中的一個文件附加到當前伺服器。 a.分離 EXEC sp_detach_db @dbname = '庫名' b.刪除日誌文件 c.再附加 EXEC sp_attach_single_file_db @dbname = '庫名', @physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\庫名.mdf' 5.為了以後能自動收縮,做如下設置: 企業管理器--伺服器--右鍵資料庫--屬性--選項--選擇"自動收縮" --SQL語句設置方式: EXEC sp_dboption '庫名', 'autoshrink', 'TRUE' 6.如果想以後不讓它日誌增長得太大 企業管理器--伺服器--右鍵資料庫--屬性--事務日誌 --將文件增長限制為xM(x是你允許的最大數據文件大小) --SQL語句的設置方式: alter database 庫名 modify file(name=邏輯文件名
G. SQL Server 2000資料庫收縮
1、是不是我的資料庫現在收縮失敗了啊？
答：你的資料庫收縮還沒有完全失敗，但已經可以視為失敗，因為要做完收縮遙遙無期，需要的時間將十分漫長，具體原因見第三問。
2、大家有過對大型資料庫的收縮經驗嗎？時間怎麼這么久啊？
答：資料庫的收縮時間與資料庫大小是成正比的，資料庫越大，收縮時間越長。所以建議要定時進行資料庫收縮，每年一次或幾個月一次，依資料庫增長速度而定。
3、為什麼我按百分比收縮時總是不成功？和盤符所剩空間有關系么？
答：不論是按百分比收縮還是按空間大小進行收縮，都要求資料庫所在磁碟預留一定的空間，最好在15%以上。在資料庫進行收縮時，系統將把這部分預留空間作為緩沖區，用來保存和整理資料庫中的數據，然後再把整理過的數據寫回資料庫。像你說的這種情況，數據文件大小為598G，可用空間為9M，基本無法進行有效的資料庫收縮。建議你把資料庫文件解掛後，復制到750G以上的大容量硬碟中，重新附加資料庫後再進行收縮。
4、資料庫收縮的簡單原理是什麼啊？和盤符所剩空間有關系么？
答：資料庫收縮的簡單原理有兩條，一是清理日誌，因為日誌記錄的是資料庫的歷史操作，在一段時間後，如果沒有保存價值可以清除；二是清理空白空間，這種空間是刪除數據表（一般是臨時表）後造成的，數據表刪除後，資料庫空間不會自動縮小，所以數據文件就會越來越大。和盤符所剩空間的關系，第三問已經回答了。
H. sqlserver2000資料庫文件mdf已經達到70g了，怎麼壓縮
SQL2000我嘗試過將17G的資料庫收縮到5G，收縮了5個小時（不是普通PC，是伺服器，具體配置忘了）沒搞完，最後忍受不了停了，另建一個資料庫將資料庫導入，刪除舊資料庫。我的經驗是，占空比越大，收縮越慢，所以從此後我都建個作業，每周空閑時
I. sql server 2000收縮資料庫總是發生死鎖
出現死鎖的情況：
1). 不按同一順序訪問對象。(註：出現循環)
2). 事務中的用戶交互。(註：增加持有資源的時間，較多鎖競爭)
3). 事務冗長並處於多個批處理中。(註：增加持有資源的時間)
4). 使用較高的隔離級別。(註：使用較低的隔離級別（例如已提交讀））
5). 不使用基於行版本控制的隔離級別：2005中支持快照事務隔離和指定READ_COMMITTE
隔離級別的事務使用行版本控制，可以將讀與寫操作之間發生的死鎖幾率降至最低。
6). 不使用綁定連接。
解決辦法：
使用SET LOCK_TIMEOUT timeout_period(單位為毫秒)來設定鎖請求超時。默認情況下，資料庫沒有超時期限(timeout_period值為-1，可以用SELECT @@LOCK_TIMEOUT來查看該值，即無限期等待)。當請求鎖超過timeout_period時，將返回錯誤。timeout_period值為0時表示根本不等待，一遇到鎖就返回消息。設置鎖請求超時，破環了死鎖的第二個必要條件(請求與保持條件)。
壓縮文件，我覺得這樣比較好，
use 資料庫名;
select * from sys.database_files
dbcc shrinkfile(2,1) --前者參數1代表主數據文件，2代表日誌文件；後者參數是大小
J. SQL資料庫中日誌收縮、截斷等等是什麼
如：shgzts為資料庫名
mp transaction shgzts with no_log --截斷日誌
backup log shgzts with no_log --備份日誌
dbcc shrinkdatabase(shgzts,truncateonly) --資料庫收縮