Viewing 15 posts - 21,886 through 21,900 (of 22,226 total)
There is a lot of time in Itzik's book on graphing & trees & pivots that, in my opinion, won't be used by most people (myself included). However the APPLY &...
"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 3, 2007 at 8:15 am
I want to jump on the band wagon and recommend Itzik Ben-Gan's "Inside TSQL Querying". Add to it his "Inside TSQL Programming". The first book is all about TSQL queries. 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
May 3, 2007 at 8:11 am
Generally, it's probably safer to create the index & temp table together and then add data to it. Clearly it's affecting the locking, but it will also cause recompiles.
"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 2, 2007 at 10:11 am
SQL Server takes exclusive locks on a row, page or data when it wants to perform a write operation. You've got a process within your stored procedure that is escalating...
"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 2, 2007 at 7:03 am
It looks like you may be hitting a bug. I found this kb article that seems to describe your situation:
http://support.microsoft.com/kb/935356
"In SQL Server 2005, assertion error 3624 may occur. 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
May 2, 2007 at 6:18 am
Good catch. Once I spotted that USING word I couldn't see much else.
"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 2, 2007 at 5:12 am
Forgive us our typos as we forgive those who typo against us... unless you just ran a restore on the production server...
"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 1, 2007 at 1:38 pm
Cool. What would you use in 2005? ![]()
"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 1, 2007 at 8:58 am
Are you running this against a 2000 server or against a 2005 server in 8.0 compatibility mode? Either of those will be the problem.
"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 1, 2007 at 8:57 am
One likely issue is the USING word you've got in the very first join. Also, you can't use variables $x. Instead you should use @x. What are those other two...
"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 1, 2007 at 8:56 am
No, you and the article are correct. Seeks are better than scans. Eliminating, as much as you can, bookmark lookups is the way to go. The issue isn't whether or not...
"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 1, 2007 at 5:17 am
The differences in the data are most likely going to cause different query plans. I suspect that's the most likely issue.
One thing you said that concerns me a bit. You've created...
"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
April 30, 2007 at 12:19 pm
Is the amount of data and it's distribution the same between dev & production. Do you have the latest statistics in both environments? Do you have an index maintenance plan in 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
April 30, 2007 at 8:51 am
There are some tools that offer a solution to this problem too. You can try Red-Gate's SQL Refactor which will rename an object and all it's references. Another one 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
April 30, 2007 at 7:58 am
I've only spent five minutes looking at this, but the first two things I'd check would be the parallelism threshold on your server and the cluster on the Subscriber table.
I'd...
"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
April 27, 2007 at 1:05 pm
Viewing 15 posts - 21,886 through 21,900 (of 22,226 total)