Viewing 15 posts - 14,986 through 15,000 (of 22,227 total)
I got an error trying to read the plan. You might recheck the posting.
"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
May 20, 2010 at 6:37 am
samsql (5/20/2010)
Grant there are procedure with begin and tran
E.g
proc ssa
(
Begin tran
exec procedure1
-----create some temp table and do...
"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
May 20, 2010 at 6:27 am
Saby, I'm confused. Where did you get deadlocks in this situation. We're talking about blocking. That's not the same thing as deadlocks.
"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
May 20, 2010 at 6:26 am
It really depends on your needs. That query is returning the data you outlined.
"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
May 20, 2010 at 6:23 am
Brett Robson (5/20/2010)
"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
May 20, 2010 at 5:39 am
Temp tables last for the length of the process that created them. That wrapper proc is the process, so as long as it's running, you'll keep those temp tables. 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
May 20, 2010 at 5:27 am
You can capture DDL commands through an even trace or by looking at the default trace on the server. Based on that volume, the default trace might be rolling over...
"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
May 19, 2010 at 8:12 pm
Yang-703993 (5/19/2010)
I don't know... If you see data like thisTable Namesysobjvalues
Row Count3213517
Reserved (MB)5740.40625
Data (MB)4807.484375
Index Size (MB)22.7890625
Unused Space (MB)910.1328125
Yeah, 3 million rows could be a bit off-putting, but it's still a...
"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
May 19, 2010 at 1:41 pm
There really isn't anything "to do" with the tables. If you have lots of objects in your database, you're going to have lots of rows in the system tables. As...
"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
May 19, 2010 at 1:02 pm
Generally, you don't. I've never heard of anyone defragging a system index. Since you're operating in 2005/2008, you can't get direct access to the tables anyway, you're just looking at...
"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
May 19, 2010 at 10:51 am
No, when a plan is flushed from cache, it's gone forever. The only thing you can do is try to capture the plans regularly (based on how often they flush...
"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
May 19, 2010 at 10:50 am
It adds overhead, but it's pretty trivial. The accumulative effects aren't good, but you're unlikely to see any given query perform badly because of this.
"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
May 19, 2010 at 10:48 am
Please, edit the post, remove the XML. Then go back and save your execution plan as a .SQLPLAN file. You can then post the file as an attachment. From 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
May 19, 2010 at 9:35 am
From the Books Online:
The missing indexes feature is on by default. No controls are provided to turn the feature on or off, or to reset any of the tables returned...
"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
May 19, 2010 at 9:33 am
Dynamic methods are frequently problematic, but to get the data you're looking for, check out the system views available under the schema called INFORMATION_SCHEMA. They should supply you with everything...
"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
May 19, 2010 at 8:19 am
Viewing 15 posts - 14,986 through 15,000 (of 22,227 total)