July 27, 2011 at 6:02 am
Hi,
There was a search sp that I changed and created a new sp. I had to show the difference as the requirement was to bring data first by finding in title column then on other columns. the older sp was searching in all columns and there was only 1 query to bring results. as the requirement i had to make two queries and then put title with TOP priority in searching and it would be displayed first, so I made it with two queries and then return final result.
By now i have to check the performance of both and I am using following way of testing, not sure if this is correct or NOT, because the stats. are sometimes differenent with single query and the two queries are sometimes more better. so I am confused if I am doing wrong way of testing.
declare @DBID int
Select @DBID =db_id('Mydb')
DBCC FLUSHPROCINDB(@DBID)
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
Declare @StartTime Datetime = GetDate()
declare @EndTime Datetime
exec [SearchRecordsWithKeyword] 'classroom',0,1000,1037, '', '', '','', 'RANK', 1, 2, 1, 0, 0
set @EndTime = GetDate()
select Datediff(ms, @startTime, @EndTime)
The difference in milisecond is what I am looking and it is not justifying me. An earliest reply will be highly appreciated...
Shamshad Ali.
July 27, 2011 at 6:22 am
Personally I prefer to use:
SET STATISTICS TIME ON
and / or
SET STATISTICS IO ON
simple and informative 😀
July 27, 2011 at 6:25 am
In addition to what Eugene said, i usually create the replacement proc under a new, temporary name,a dn test them side by side, comparing execution plans;
yoiu know exec pr_myproc @param vs exec pr_myprocNEW @param .
after they've been run once to build the execution plan, the second and subsequent runs are what i'm interested in for the exection plans.
Lowell
July 27, 2011 at 6:26 am
STATISTICS IO is never but once you get to a 30 steps procs it becomes pretty hard to work with.
I like to use profiler and display all statements (and the whole batch / proc).
That way you really see what's going on.
July 27, 2011 at 7:04 am
Could you plz. tell me how do you get stats using profiler? what events and their columns to choose in profiler? plz. write in detail.
Shamshad Ali.
July 27, 2011 at 7:11 am
I just use the basic cpu, reads, writes, duration columns.
Those events are nice to use in their own rights :
Performance:Showplan XML Statistics Profile
SP:StmtCompleted
SQL:StmtCompleted
July 27, 2011 at 2:28 pm
Ninja's_RGR'us (7/27/2011)
http://www.simple-talk.com/sql/performance/finding-the-causes-of-poor-performance-in-sql-server,-part-1I just use the basic cpu, reads, writes, duration columns.
Those events are nice to use in their own rights :
Performance:Showplan XML Statistics Profile
SP:StmtCompleted
SQL:StmtCompleted
I also throw in ROWCOUNT... it sometimes tells the tale for accidental cross joins and other Hidden RBAR.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 27, 2011 at 2:32 pm
Jeff Moden (7/27/2011)
Ninja's_RGR'us (7/27/2011)
http://www.simple-talk.com/sql/performance/finding-the-causes-of-poor-performance-in-sql-server,-part-1I just use the basic cpu, reads, writes, duration columns.
Those events are nice to use in their own rights :
Performance:Showplan XML Statistics Profile
SP:StmtCompleted
SQL:StmtCompleted
I also throw in ROWCOUNT... it sometimes tells the tale for accidental cross joins and other Hidden RBAR.
I love that coutner too but I can't see how it can help detect the RBAR part.
Crosss join is easy, just look for 1 baziliion rows in that counter.
RBAR??? Only looking for AVG returns < 2 I guess?!?
July 27, 2011 at 4:14 pm
With exceptions, of course, many While loops will register 2 or 3 times the number of rows as there end up being in the result set.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply