March 14, 2009 at 5:57 am
Query/Queries are running slow. Troubleshooting steps being taken are
Check CPU utilization which is fine
Also check whether query is using relevant indexes or not which is being used
Check index fragmentation and reorganize or rebuild the indexes and still the query is running slow
All hardware is fine and there is no network issue. Query execution plan is fine.
Any more troubleshooting steps. Please help!!!
March 14, 2009 at 6:39 am
Does the query returns large no. of rows? How much time does it take to execute? How about adding the execution plan as an attachment, so to check for the operators causing the problem?
--Ramesh
March 14, 2009 at 7:32 am
the query is not returning large number of rows still it is taking a huge time to complete. And anything other than operators which could be causing issue
Thanks
March 14, 2009 at 7:40 am
Does the queries are part of a procedure/function that were created using RECOMPILE option? This may be causing the server to re-compile every time on each execution.
--Ramesh
March 14, 2009 at 10:49 am
Such slowness is normally caused by a mistake somewhere in the query... formulas around columns in the WHERE clause will prevent good use of indexes... misunderstanding of the data may cause a partial cross join... etc, etc.
Start with the actual execution plan... check the connecting arrows themselves... look for really fat ones that, when you click on them, contain more rows that what are in the table and look for really skinny ones... especially ones that have one row... those are usually some form of performance robbing RBAR and may be in the form of recursion, poorly written UDF's, or some inappropriate correlation within the queries.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 14, 2009 at 12:14 pm
Reasons for slowness will be a badly written query. Use the profiler to see the reads, writes, cpu and duration figures.
Then get the actual execution plan and check where it takes more time.
Susantha
March 14, 2009 at 2:38 pm
Another possibility is memory shortage and/or slow I/O. The former will almost certainly cause the latter.
Look in perfmon at the following counters:
SQLServer:Buffer Manager - Page Life Expectancy
Physical Disk (all disks used by SQL Server) - Avg Disk sec/Read and Avg Disk sec/Write
If you're not sure how to read these, report the values back to this post.
March 15, 2009 at 8:02 pm
%Idle from your individual physical disks.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
March 16, 2009 at 8:14 am
Could run the query through the Database Tuning Advisor just to see what it's recommendation would be.
Tim White
March 16, 2009 at 1:59 pm
Good advise above, but above all this it is always a good practice to create a baseline of your workload , later you can compare the monitoring activity with this baseline and then quickly identify the bottlenecks.
September 14, 2010 at 7:32 am
Hi
can u plz give me some more clarification about page life expectancy and physical disk counters sec/read,sec/write.how can i troubleshoot by using this
plz help me
Regards
Jayapal
September 14, 2010 at 10:12 am
What version of SQL server are you using?
Are you seeing any Key lookups or RID lookups, Table scans or Index scans in the query execution plans?
Execution plan looks fine? ..... It would be more helpful if you could attach the query exec plan.
Are you experiencing any memory pressures?
Are you using a lot of ad-hoc queries or stored procs?
and.... Is the SQL Server 32 bit or 64-bit?
Thank You,
Best Regards,
SQLBuddy
September 14, 2010 at 2:32 pm
Krishna Potlakayala (3/16/2009)
Good advise above, but above all this it is always a good practice to create a baseline of your workload , later you can compare the monitoring activity with this baseline and then quickly identify the bottlenecks.
Heh... unless the baseline was bad to begin with...:-D
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2010 at 3:17 pm
What is your parallelism set to? Have you tried setting MAXDOP 1, 2, 4, 8, 0 to test if results are any different? How about memory usage? Did you cap it and leave ~4GB or more for the OS?
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply