August 12, 2011 at 12:39 pm
I'm having a very peculiar problem.
An hourly job creating a database snaphot from a mirror started taking a lot longer to complete last night: 30-40 minutes from about 1 minute previously.
I noticed that the job was waiting exclusively on IO_COMPLETION waits.
However, the ms/Read, ms/Write counters were at normal levels: under 10-20 ms.
I have been having a lot of trouble convincing our server admins that there is something wrong.
What proof can I provide them with, other than some obscure waittype that only DBAs understand?
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
August 12, 2011 at 1:36 pm
40X slower is not enough for them?
sp_update_resume, sp_distribute.
In the mean time, what changed on that server or the db sine the last successful 1 minute exec?
August 12, 2011 at 1:44 pm
Ninja's_RGR'us (8/12/2011)
40X slower is not enough for them?sp_update_resume, sp_distribute.
In the mean time, what changed on that server or the db sine the last successful 1 minute exec?
The hourly snapshot-refresh job is now mysteriously back at normal levels: < 1-2 min
I will be monitoring for any other activity on the server, as this is a VM and there may have been a monstrous SQL query running for a report that caused this.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
August 12, 2011 at 1:49 pm
You can get sql monitor for free for 14 days, that should give you your answer...
August 12, 2011 at 1:51 pm
Ninja's_RGR'us (8/12/2011)
You can get sql monitor for free for 14 days, that should give you your answer...
Thanks, we are using SQL Sentry and IGNITE for monitoring. But thanks for the input.
Marios
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
August 12, 2011 at 1:56 pm
And they can't tell you what happened or what's hapenning during the issue?
Thanks for the tip!
August 12, 2011 at 2:03 pm
Ninja's_RGR'us (8/12/2011)
And they can't tell you what happened or what's hapenning during the issue?Thanks for the tip!
Not fully; SQL Sentry is showing the high IO_COMPLETION waits and the perfmon counters at normal levels, as mentioned in my OP.
This was independently confirmed through some of my own DMV queries and perfmon collection.
But 3rd-party tools can only go so far; to dig deeper, one needs to have the knowledge and expertise these tools cannot provide.
I do have some indication from SQL Sentry that some pretty heavy queries were running on the server at the time, but I started the monitoring fairly late in the process; if this happens again, I will have more historic info to go with.
Most likely, this is an issue of unusually heavy resource contention.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
August 12, 2011 at 2:06 pm
Ok, if you have 2 minutes you can see what SM has to offer (live previous of the servers hosting ssc.com)
August 15, 2011 at 7:26 am
Marios, what version of SQL Sentry are you using? With 6.x you should certainly be able to dig deeper into the individual queries where IO_Completion is high - for example the new query analysis features should let you drill in to the costly operators and help you spot potential statistics or other issues leading to sub-optimal plans.
However keep in mind that IO issues may just be a symptom of an overwhelmed disk subsystem - it's not necessarily going to lead you to a quick solution based on SQL or application code. Unfortunately if you are using a SAN 3rd party tools for the most part can only see so far into the disk subsystem... if there truly is a configuration or resource issue with the SAN, and it's not just because of a spike due to known activity variance, it is likely going to require expert assistance.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply