Sql query performance issue - did I screw anything up?
I apologize for the vagueness of the question, but I ran the following query on a production server accidentally (I intended to test it on my local one):
DBCC FREEPROCCACHE
GO
DBCC DROPCLEANBUFFERS
GO
DECLARE @start DATETIME SET @start = getDate()
EXEC test_1a
SELECT getDate() - @start AS Execution_Time
GO
My sql knowledge is just above basic, so I'm not sure what this does. I cancelled the q开发者_如何转开发uery after I realized I was connected to the wrong machine.
Can someone please explain what these set of statements do and if there is any impact?
Yes.
No permanent damage (assuming the stored procedure didn't do any) but you have just cleared out your entire procedure cache and dropped all non dirty pages from the buffer cache on your production box. (A dirty page is one that has been modified in memory and not yet written out to disc)
This means that the queries that are coming in now will all need to be recompiled (high CPU usage) and that pretty much all data will need to be re-read in from disc.
BTW: I recommend using the free SSMS Tools Pack Addin. You can use the Window Connection Coloring to give all production server windows a red title bar for example to make this kind of mistake less likely.
Simple answer: You've cleared all the cached stored procedure plans and they need to be recompiled. The recompiling of the procedures will cause performance issues for a short time.
No damage has been done.
FREEPROCCACHE
Removes all elements from the plan cache, removes a specific plan from the plan
cache by specifying a plan handle or SQL handle, or removes all cache entries
associated with a specified resource pool.
DROPCLEANBUFFERS
Removes all clean buffers from the buffer pool.
I think ther are not harmfull code as from it's name FREEPROCCACHE and DROPCLEANBUFFERS they are cleaning the cache and the buffer then the rest of the code see the running time of the procedure.
精彩评论