既然你問「爲什麼」,我要去給你完整的答案:)
定期運行DBCC FREEPROCCACHE
和DBCC DROPCLEANBUFFERS
是不是一個有效的解決您的問題。就像重啓一樣,如果它能夠改善任何事情,那只是巧合,而且你很可能會看到不穩定的結果。如果這個「修復」糾正了你的性能問題,那麼它很可能會在未來看起來隨機而且比現在看到的更嚴重。
當您運行DBCC FREEPROCCACHE
時,SQL Server將重新編譯每個存儲過程或下次運行時的高速緩存查詢計劃。如果事實證明SQL Server選擇的計劃對於後續運行中的常規操作更好,則通常會看到性能提高。如果SQL Server選擇通常性能較差的計劃,則會看到性能下降。爲什麼會選擇一個通常更糟糕的計劃?那麼,這取決於執行的第一個查詢 - SQL Server將根據傳遞參數的選擇性爲語句選擇一個計劃。看看這個例子:
SET NOCOUNT ON;
IF OBJECT_ID('temporary_demo') IS NOT NULL DROP TABLE temporary_demo;
IF OBJECT_ID('temporary_demoproc') IS NOT NULL DROP PROC temporary_demoproc;
GO
CREATE TABLE temporary_demo (id int primary key identity(1,1), id2 int, txtval nvarchar(100));
insert temporary_demo (id2, txtval) values (1, 'something highly selective');
declare @i int;
set @i = 1;
while @i < 10000 begin
insert temporary_demo (id2, txtval) select 2, 'something else ';
set @i = @i + 1;
end
insert temporary_demo (id2, txtval) select 2, 'needle in a haystack';
create index ix_id2 on temporary_demo(id2);
GO
create proc temporary_demoproc @searchid int, @searchtxtval nvarchar(100) as
select * from temporary_demo where id2 = @searchid and txtval = @searchtxtval;
GO
--Look at the query plans for both of these procedures.
--Note that the plan chosen depends on which one is called first.
exec temporary_demoproc 1, 'something highly selective';
exec temporary_demoproc 2, 'needle in a haystack';
dbcc freeproccache;
exec temporary_demoproc 2, 'needle in a haystack';
exec temporary_demoproc 1, 'something highly selective';
所以,如果你看到的例子,如果你的表現恰好增加,因爲到DBCC FREEPROCCACHE
呼叫,這是最有可能的,因爲你是給你的應用程序的機會獲得下次運行時針對查詢的不同查詢計劃。再次 - 只是偶然或巧合,您的應用程序會變得更快(或更慢)。
只要DBCC DROPCLEANBUFFERS
去,週期性地運行這將幾乎總是減慢你的應用程序。此命令強制查詢轉到存儲子系統,而不是從內存中讀取緩存頁面。我認爲這可能有助於提高性能的唯一方法是,如果數據庫服務器的內存配置不合適,並且由於其物理內存不足而切換到頁面文件。
那麼有什麼解決方案?
解決方案是不尋找一般原因或創可貼。您將需要使用SQL Server分析器運行一系列性能不佳的查詢,並確定存在問題的各個查詢。你將不得不對這些查詢做一些「堅果和螺栓」分析,並真正理解它們。您需要確定是否需要在逐個查詢的基礎上添加,更改甚至刪除索引,並且您需要確定可能需要重寫的有問題的查詢。
'偶爾'意味着什麼?你多久打一次電話?另外,這是一個高IO分貝?這可能是一個索引問題。 – ScottE 2010-10-15 10:45:08
它每2-3天發生一次。是的,這是一個高IO分貝。是的,它可能是一個索引問題,但爲什麼然後它相對運行更快,當sql服務器重述。 – user476769 2010-10-15 10:55:02
我也很好奇爲什麼重啓可以解決這個問題。我們在SQL Express 2008中遇到同樣的問題,並且不確定原因,但是確定重啓可以修復它,直到下一次,這可能是一天,或者只有幾個小時。 – CrazyTim 2012-12-12 03:14:03