Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Garth
SQLTeam Author
119 Posts |
Posted - 2001-08-10 : 09:19:12
|
| The performance tuning tip shown below was taken from an editorial written by Brian Moran of SQL Server Magazine. It's good stuff...Garthwww.SQLBook.com"For me, seeing is believing when it comes to SQL Server performanceissues. During the past few years, I've tried a lot of tips that haveyielded amazing results, whereas other tips have offered barely awhisper of performance gains in real-world situations. Implementing allthe techniques that are supposed to give you optimal performance isalmost impossible, which inevitably leads you to implement arcane tipsthat achieve only trivial gains while you miss out onsimple-to-implement solutions that yield truly substantial performanceimprovements. SET NOCOUNT ON is a technique that I know can yield amazing results.Unfortunately, it's so simple that many people ignore it. SQL ServerBooks Online (BOL) says this about SET NOCOUNT ON: "When SET NOCOUNT isON, the count (indicating the number of rows affected by a Transact-SQLstatement) is not returned. When SET NOCOUNT is OFF, the count isreturned. SET NOCOUNT ON eliminates the sending of DONE_IN_PROC messagesto the client for each statement in a stored procedure. When using theutilities provided with Microsoft SQL Server(tm) to execute queries, theresults prevent 'nn rows affected' from being displayed at the end [of]Transact-SQL statements such as SELECT, INSERT, UPDATE, and DELETE. Forstored procedures that contain several statements that do not returnmuch actual data, this can provide a significant performance boostbecause network traffic is greatly reduced.""Significant performance boost"--Microsoft's words, not mine. Howsignificant? You can use the following procedure to demonstrate the gainyou can achieve using SET NOCOUNT ON inside stored procedures that issuemany SQL statements. The procedure accepts two parameters: @NoCount and@NumRows. A value of 1 for @NoCount causes the procedure to issue SETNOCOUNT ON, and the value of @NumRows tells the procedure how many rowsto insert into a simple local temporary table the procedure creates. CREATE PROC NoCountOnTest @NoCount int ,@NumRows int AS CREATE TABLE #NoOrderByClauseOnGUID ( RowIdent int identity ,RowGUID uniqueidentifier default newid() ) IF @NoCount = 1 BEGIN SET NOCOUNT ON END ELSE BEGIN SET NOCOUNT OFF END DECLARE @CurrInsert int SET @CurrInsert = 0 BEGIN TRAN WHILE @CurrInsert < @NumRows BEGIN INSERT INTO #NoOrderByClauseOnGUID default values SET @CurrInsert = @CurrInsert +1 END COMMIT TRAN GO I executed this procedure a few times for SET NOCOUNT ON and SET NOCOUNTOFF, using a @NumRows of 10,000 each time. Results varied from machineto machine, but my laptop ran the procedure in about 800ms with SETNOCOUNT ON and took close to 8 seconds with the setting OFF. In somecases, you could achieve a HUGE performance difference.What accounts for the significant difference in performance? Nothingmore than the network traffic and latency associated with sending theDONE_IN_PROC messages back to the client after executing each statementin the procedure. These time differences happened on a self-containedlaptop. The performance differences could be even greater on a computerrunning across a network with a Web browser in the middle. Now thatyou've seen the proof, consider implementing this simple tuningtechnique in your own application architectures. Although SET NOCOUNT ON can be your friend, it's not a panacea for alltuning problems. Performance tuning is part art, part science, and partexperimentation. Put tuning tips to the test in your environment so youcan see with your own eyes what they can do. Doing so will help you cutthrough the myriad tuning hints that are irrelevant and focus on thetechniques that really matter in your environment." |
|
|
|
|
|
|
|