收縮資料庫的影響
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;
找到索引缺失的表，根據查詢結果中的關鍵次逐一建立索引。
『貳』 收縮資料庫有什麼作用
收縮資料庫
資料庫中的每個文件都可以通過刪除未使用的頁的方法來減小。盡管資料庫引擎會有效地重新使用空間，但某個文件多次出現無需原來大小的情況後，收縮文件就變得很有必要了。數據和事務日誌文件都可以減小（收縮）。可以成組或單獨地手動收縮資料庫文件，也可以設置資料庫，使其按照指定的間隔自動收縮。
文件始終從末尾開始收縮。例如，如果有個 5 GB 的文件，並且在 DBCC SHRINKFILE 語句中將 target_size 指定為 4 GB，則資料庫引擎將從文件的最後一個 1 GB 開始釋放盡可能多的空間。如果文件中被釋放的部分包含使用過的頁，則資料庫引擎先將這些頁重新放置到文件的保留部分。只能將資料庫收縮到沒有剩餘的可用空間為止。例如，如果某個 5 GB 的資料庫有 4 GB 的數據，並且在 DBCC SHRINKFILE 語句中將 target_size 指定為 3 GB，則只能釋放 1 GB。
自動資料庫收縮
將 AUTO_SHRINK 資料庫選項設置為 ON 後，資料庫引擎將自動收縮具有可用空間的資料庫。此選項可以使用 ALTER DATABASE 語句來進行設置。默認情況下，此選項設置為 OFF。資料庫引擎會定期檢查每個資料庫的空間使用情況。如果某個資料庫的 AUTO_SHRINK 選項設置為 ON，則資料庫引擎將減少資料庫中文件的大小。該活動在後台進行，並且不影響資料庫內的用戶活動。
將資料庫設置為自動收縮
ALTER DATABASE (Transact-SQL)
手動資料庫收縮
您可以使用 DBCC SHRINKDATABASE 語句或 DBCC SHRINKFILE 語句來手動收縮資料庫或資料庫中的文件。如果 DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 語句無法回收日誌文件中的所有指定空間，則該語句將發出信息性消息，指明必須執行什麼操作以便釋放更多空間。有關收縮日誌文件的詳細信息，請參閱收縮事務日誌。
在該過程中任意時間都可停止 DBCC SHRINKDATABASE 和 DBCC SHRINKFILE 操作，所有已完成工作都將保留。
在使用 DBCC SHRINKDATABASE 語句時，您無法將整個資料庫收縮得比其初始大小更小。因此，如果資料庫創建時的大小為 10 MB，後來增長到 100 MB，則該資料庫最小隻能收縮到 10 MB，即使已經刪除資料庫的所有數據也是如此。
但是，使用 DBCC SHRINKFILE 語句時，可以將各個資料庫文件收縮得比其初始大小更小。必須對每個文件分別進行收縮，而不能嘗試收縮整個資料庫。