Viewing 15 posts - 5,446 through 5,460 (of 22,224 total)
If you don't have something like Extended Events already capturing your data, then you're completely dependent on what is currently in cache accessed through the Dynamic Management Views (DMVs). The...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 7, 2015 at 3:44 pm
Absolute agreement with Chris. We'd need to see the query, the function and the execution plan to make an assessment.
If it's a multi-statement, table-valued, user-defined function, that's problematic right there.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 7, 2015 at 6:38 am
There are also a number of ways to simply call the SSIS package directly.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 7, 2015 at 6:36 am
GilaMonster (10/7/2015)
Grant Fritchey (10/7/2015)
You're already capturing deadlock information in the system_health extended event session.On 2008?
Yep.
No gui, but it works.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 7, 2015 at 6:33 am
You might have it. Check your system_health extended event session. You can use this query [/url]to take a look.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 7, 2015 at 3:18 am
You're already capturing deadlock information in the system_health extended event session. You don't have to clutter up your error log with deadlock graphs through the traceflag if you don't want...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 7, 2015 at 3:16 am
The command you want to shrink the file is DBCC SHRINKFILE.
As for defragmenting the indexes, you have a bunch of options. The one I'm currently suggesting people look at is...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 7, 2015 at 3:13 am
I recognize that Kalen Delaney's book, SQL Server Internals, can be pretty advanced, but it's the kind of thing you read over and over again to build up knowledge. It's...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 6, 2015 at 8:08 pm
You can use the SET DEADLOCK_PRIORITY to make it the lowest priority. That should result in it always being the victim.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 6, 2015 at 8:04 pm
I'd name every object that takes one. Letting the defaults do the naming for you leads to issues down the road, if nothing, in clarity. When you compare your development...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 6, 2015 at 4:17 pm
Having one of those days where I'm sitting here in slack-jawed wonder that some of the people we serve are actually getting paid to do whatever the heck it is...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 6, 2015 at 11:54 am
krypto69 (10/6/2015)
Let's say this is a memory buffer issue...is there any way to force this to stay in buffer without querying the indexes..?
I'm with Gail, I don't understand what you...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 6, 2015 at 11:51 am
BrainDonor (10/6/2015)
BL0B_EATER (10/6/2015)
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 6, 2015 at 11:21 am
Just make sure this is a one-time shrink. If you get in a situation where you're shrinking over and over, that leads to issues down the road.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 6, 2015 at 8:26 am
GilaMonster (10/6/2015)
Because SQL's taken either a page lock or a table lock, probably due to inadequate indexing, maybe due to the way the query was written
Or both.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 6, 2015 at 8:25 am
Viewing 15 posts - 5,446 through 5,460 (of 22,224 total)