|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 2:33 PM
Points: 37,741,
Visits: 30,019
|
|
Joie Andrew (1/7/2013) Of couse these solutions are only good if SQL has not been restarted since the TempDB errors, as the DMVs will only collect metrics from the time SQL was started.
Those aren't since SQL started. They're queries whose plans are still in cache.
Gail Shaw Microsoft Certified Master: SQL Server 2008, MVP SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter We stand on the bridge and no one may pass
|
|
|
|
|
Mr or Mrs. 500
      
Group: General Forum Members
Last Login: Today @ 7:23 AM
Points: 553,
Visits: 1,032
|
|
Ah, great point. I did not realize that. That is an important difference. Thanks for pointing it out Gail!
Joie Andrew "Since 1982"
|
|
|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Thursday, January 24, 2013 2:06 PM
Points: 19,
Visits: 72
|
|
I've sent an email to all our report writers, reports are written in Crystal. so i'd expect the queries are hardly optimised. problem is becuase it's the start of the year big reports are being run though they "should" be run on the dedicated report server. Some of these guys think they know better.
There are also built in reports in the application that some have been modified by the report team. these can be run by anyone with required security rights in the application all it asks for is a date range. These are all run off the live DB as well. I've asked the report writers to check any reports they might have changed in the last few weeks.
I feel it must be a report as if it was an application glitch we should have had it before. unless it was just one of those things that need a perfect situation to occur.
The server has not been rebooted since it happened.
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: Monday, May 20, 2013 6:18 AM
Points: 242,
Visits: 882
|
|
The default trace records which login is responsible for file autogrowth. This sometime shows as sa, for example during some system operations, but it is worth a try.
Here's the script I use:
use master; set nocount on;
declare @path sql_variant select @path = value from ::fn_trace_getinfo(0) i join sys.traces t on t.id = i.traceid where t.is_default = 1 and i.property = 2
select df.StartTime, e.name, df.DatabaseName, case when df.ApplicationName like 'SQLAgent%JobStep%' then isnull((select name from msdb..sysjobs where job_id = CONVERT(uniqueidentifier, convert(varbinary(16), substring(df.ApplicationName, charindex('(Job', df.ApplicationName) + 5, 34), 1))), df.ApplicationName) else df.ApplicationName end AppName, df.LoginName, df.SPID, df.Duration, df.EndTime, df.FileName, df.TextData, df.IntegerData from ::fn_trace_gettable(convert(nvarchar(255), @path), 0) df join sys.trace_events e ON df.EventClass = e.trace_event_id where e.category_id = 2 order by df.StartTime desc
If the default trace file has rolled over, modify the first bit to look at an older file.
 FREE DOWNLOAD www.sqlcopilot.com
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Today @ 1:46 PM
Points: 6,730,
Visits: 11,783
|
|
To view all default trace files:
Reviewing AutoGrow events from the default trace by Aaron Bertrand
__________________________________________________________________________________________________ There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Believe you can and you're halfway there. --Theodore Roosevelt
Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein
The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein
1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy
|
|
|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Thursday, January 24, 2013 2:06 PM
Points: 19,
Visits: 72
|
|
Well the issue has not happened again.
I did get some feedback from one of our report writters that they were testing a new large report at that time. I'd say this was the cause, they are now only going to run that report off the report server.
|
|
|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Thursday, January 24, 2013 2:06 PM
Points: 19,
Visits: 72
|
|
| Are apparently a few new reports where run and the user accidently set some filters wrong so alot more data was pulled than should have been. the report has been re run and the issues didn't return.
|
|
|
|