收縮sql資料庫
收縮MSSQL資料庫之一：清空日誌DUMP TRANSACTION 庫名 WITH NO_LOG 收縮MSSQL資料庫之二：截斷事務日誌：BACKUP LOG 資料庫名 WITH NO_LOG收縮MSSQL資料庫之三：收縮資料庫文件(如果不壓縮,資料庫的文件不會減小企業管理器--右鍵你要壓縮的資料庫--所有任務--收縮資料庫--收縮文件--選擇日誌文件--在收縮方式里選擇收縮至XXM,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了--選擇數據文件--在收縮方式里選擇收縮至XXM,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了也可以用SQL語句來完成--收縮資料庫DBCC SHRINKDATABASE(客戶資料)--收縮指定數據文件,1是文件號,可以通過這個語句查詢到:select * from sysfilesDBCC SHRINKFILE(1)收縮MSSQL資料庫之四：為了最大化的縮小日誌文件(如果是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'收縮MSSQL資料庫之五：為了以後能自動收縮,做如下設置:企業管理器--伺服器--右鍵資料庫--屬性--選項--選擇"自動收縮"--SQL語句設置方式:E X E C sp_dboption '資料庫名', 'autoshrink', 'TRUE'6.如果想以後不讓它日誌增長得太大企業管理器--伺服器--右鍵資料庫--屬性--事務日誌--將文件增長限制為xM(x是你允許的最大數據文件大小)--SQL語句的設置方式:alter database 資料庫名 modify file(name=邏輯文件名,maxsize=20)收縮MSSQL資料庫之特別注意：請按步驟進行,未進行前面的步驟,請不要做後面的步驟否則可能損壞你的資料庫.一般不建議做第4,6兩步第4步不安全,有可能損壞資料庫或丟失數據第6步如果日誌達到上限,則以後的資料庫處理會失敗,在清理日誌後才能恢復.另外提供一種更簡單的方法，本人屢試不爽，建議大家使用。收縮MSSQL資料庫之更簡單的方法：1。右建資料庫屬性窗口--故障還原模型--設為簡單2。右建資料庫所有任務--收縮資料庫3。右建資料庫屬性窗口--故障還原模型--設為大容量日誌記錄以上就是對如何讓收縮MSSQL資料庫的簡單介紹。卑錟憬舛寥患指慈砑
㈡ 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
㈢ 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、日誌文件收縮完成後，建議立即執行一次資料庫的完全備份並根據實際需要制定適當的資料庫備份計劃。
㈣ sql資料庫的收縮命令是什麼
1.清空日誌 DUMP TRANSACTION 庫名 WITH NO_LOG 2.截斷事務日誌： BACKUP LOG 資料庫名 WITH NO_LOG3.收縮資料庫文件(如果不壓縮,資料庫的文件不會減小 企業管理器--右鍵你要壓縮的資料庫--所有任務--收縮資料庫--收縮文件 --選擇日誌文件--在收縮方式里選擇收縮至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.分離 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。右建資料庫屬性窗口--故障還原模型--設為大容量日誌記錄
㈤ SQLServer資料庫收縮相關知識
SQL Server 資料庫採取預先分配空間的方法來建立資料庫的數據文件或者日誌文件，比如數據文件的空間分配了300MB，而實際上只佔用了20MB空間，這樣就會造成磁碟存儲空間的浪費。可以通過資料庫收縮技術對資料庫中的每個文件進行收縮，刪除已經分配但沒有使用的頁。從而節省伺服器的存儲的成本。
官方解釋：收縮數據文件通過將數據頁從文件末尾移動到更靠近文件開頭的未佔用的空間來恢復空間。在文件末尾創建足夠的可用空間後，可以取消對文件末尾的數據頁的分配並將它們返回給文件系統。
收縮後的資料庫不能小於資料庫最初創建時指定的大小。 或是上一次使用文件大小更改操作（如 DBCC SHRINKFILE）設置的顯式大小。
比如：如果資料庫最初創建時的大小為 10 MB，後來增長到 100 MB，則該資料庫最小隻能收縮到 10 MB，即使已經刪除資料庫的所有數據也是如此。
不能在備份資料庫時收縮資料庫。 反之，也不能在資料庫執行收縮操作時備份資料庫。
介紹：收縮指定資料庫中的數據文件大小。
語法格式：
參數說明：
介紹：收縮當前資料庫的指定數據或日誌文件的大小，或通過將數據從指定的文件移動到相同文件組中的其他文件來清空文件，以允許從資料庫中刪除該文件。文件大小可以收縮到比創建該文件時所指定的大小更小。這樣會將最小文件大小重置為新值。
語法格式：
參數說明：
例如，如果創建一個10MB 的文件，然後在文件仍然為空的時候將文件收縮為2 MB，默認文件大小將設置為2 MB。這只適用於永遠不會包含數據的空文件。
另附SqlServer常見問題解答
1）管理器不會主動刷新，需要手工刷新一下才能看到最新狀態（性能方面的考慮）
2）很少情況下，恢復進程被掛起了。這個時候假設你要恢復並且回到可訪問狀態，要執行：
RESTORE database dbname with recovery
這使得恢復過程能完全結束。
3）如果你要不斷恢復後面的日誌文件，的確需要使資料庫處於「正在還原狀態」，
這通常是執行下面命令：
RESTORE database dbname with norecovery
原來SQL Server對伺服器內存的使用策略是用多少內存就佔用多少內存，只用在伺服器內存不足時，才會釋放一點佔用的內存，所以SQL Server 伺服器內存往往會佔用很高。我們可以通過DBCC MemoryStatus來查看內存狀態。
SQL SERVER運行時會執行兩種緩存:
1. 數據緩存：執行個查詢語句，SQL SERVER會將相關的數據頁（SQL SERVER操作的數據都是以頁為單位的）載入到內存中來， 下一次如果再次請求此頁的數據的時候，就無需讀取磁碟了，大大提高了速度。
2.執行命令緩存：在執行存儲過程，自定函數時，SQL SERVER需要先二進制編譯再運行，編譯後的結果也會緩存起來， 再次調用時就無需再次編譯。
可以調用以下幾個DBCC管理命令來清理這些緩存：
但是，這幾個命令雖然會清除掉現有緩存，為新的緩存騰地方，但是Sql server並不會因此釋放掉已經佔用的內存。SQL SERVER並沒有提供任何命令允許我們釋放不用到的內存。因此我們只能通過動態調整SQL SERVER可用的物理內存設置來強迫它釋放內存。
解決SQLSERVER內存佔用過高的方法：
1、清除所有緩存DBCC DROPLEANBUFFERS
2、調整SQLSERVER可使用的最大伺服器內存。
在SQL管理器，右擊實例名稱
在屬性實例屬性裡面找到內存選項
把最大內存改成合適的內存，確定後內存就會被強制釋放，然後重啟實例。再看看任務管理器，內存使用率就降下來啦。
1、查看連接對象
USE master
GO
--如果要指定資料庫就把注釋去掉
SELECT * FROM sys.[sysprocesses] WHERE [spid]>50 --AND DB_NAME([dbid])='gposdb'
當前連接對象有67個其中『WINAME』的主機名，『jTDS』的進程名不屬於已知常用軟體，找到這台主機並解決連接問題。在360流量防火牆中查看有哪個軟體連接了伺服器IP，除之。
2、然後使用下面語句看一下各項指標是否正常，是否有阻塞，正常情況下搜索結果應該為空。
SELECT TOP 10
[session_id],
[request_id],
[start_time] AS '開始時間',
[status] AS '狀態',
[command] AS '命令',
dest.[text] AS 'sql語句',
DB_NAME([database_id]) AS '資料庫名',
[blocking_session_id] AS '正在阻塞其他會話的會話ID',
[wait_type] AS '等待資源類型',
[wait_time] AS '等待時間',
[wait_resource] AS '等待的資源',
[reads] AS '物理讀次數',
[writes] AS '寫次數',
[logical_reads] AS '邏輯讀次數',
[row_count] AS '返回結果行數'
FROM sys.[dm_exec_requests] AS der
CROSS APPLY
sys.[dm_exec_sql_text](der.[sql_handle]) AS dest
WHERE [session_id]>50 AND DB_NAME(der.[database_id])='gposdb'
ORDER BY [cpu_time] DESC
查看是哪些SQL語句佔用較大可以使用下面代碼
--在SSMS里選擇以文本格式顯示結果
SELECT TOP 10
dest.[text] AS 'sql語句'
FROM sys.[dm_exec_requests] AS der
CROSS APPLY
sys.[dm_exec_sql_text](der.[sql_handle]) AS dest
WHERE [session_id]>50
ORDER BY [cpu_time] DESC
3、如果SQLSERVER存在要等待的資源，那麼執行下面語句就會顯示出會話中有多少個worker在等待
SELECT TOP 10
[session_id],
[request_id],
[start_time] AS '開始時間',
[status] AS '狀態',
[command] AS '命令',
dest.[text] AS 'sql語句',
DB_NAME([database_id]) AS '資料庫名',
[blocking_session_id] AS '正在阻塞其他會話的會話ID',
der.[wait_type] AS '等待資源類型',
[wait_time] AS '等待時間',
[wait_resource] AS '等待的資源',
[dows].[waiting_tasks_count] AS '當前正在進行等待的任務數',
[reads] AS '物理讀次數',
[writes] AS '寫次數',
[logical_reads] AS '邏輯讀次數',
[row_count] AS '返回結果行數'
FROM sys.[dm_exec_requests] AS der
INNER JOIN [sys].[dm_os_wait_stats] AS dows
ON der.[wait_type]=[dows].[wait_type]
CROSS APPLY
sys.[dm_exec_sql_text](der.[sql_handle]) AS dest
WHERE [session_id]>50
ORDER BY [cpu_time] DESC;
4、查詢CPU佔用最高的SQL語句
SELECT TOP 10
total_worker_time/execution_count AS avg_cpu_cost, plan_handle,
execution_count,
(SELECT SUBSTRING(text, statement_start_offset/2 + 1,
(CASE WHEN statement_end_offset = -1
THEN LEN(CONVERT(nvarchar(max), text)) * 2
ELSE statement_end_offset
END - statement_start_offset)/2)
FROM sys.dm_exec_sql_text(sql_handle)) AS query_text
FROM sys.dm_exec_query_stats
ORDER BY [avg_cpu_cost] DESC;
5、索引缺失查詢
SELECT
DatabaseName = DB_NAME(database_id)
,[Number Indexes Missing] = count(*)
FROM sys.dm_db_missing_index_details
GROUP BY DB_NAME(database_id)
ORDER BY 2 DESC;
SELECT TOP 10
[Total Cost] = ROUND(avg_total_user_cost * avg_user_impact * (user_seeks + user_scans),0)
, avg_user_impact
, TableName = statement
, [EqualityUsage] = equality_columns
, [InequalityUsage] = inequality_columns
, [Include Cloumns] = included_columns
FROM sys.dm_db_missing_index_groups g
INNER JOIN sys.dm_db_missing_index_group_stats s
ON s.group_handle = g.index_group_handle
INNER JOIN sys.dm_db_missing_index_details d
ON d.index_handle = g.index_handle
ORDER BY [Total Cost] DESC;
找到索引缺失的表，根據查詢結果中的關鍵次逐一建立索引。
㈥ SQL資料庫收縮的工作原理是什麼
資料庫收縮的工作原理是：清理空白空間和日誌來實現。
空白空間：刪除表時，資料庫的空間不會自動縮小，隨著建的表越來越多，刪除操
作越來越多時候，數據文件就會越來越多。
日誌：是記錄你歷史操作的，沒用的都可以清除。