Viewing 15 posts - 18,016 through 18,030 (of 22,226 total)
Do you mean in terms of licensing or in terms of physically can it be done? If the latter, yeah. You're talking Standard edition to Standard Edition. It shouldn't be...
"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
March 16, 2009 at 6:24 am
The query was resolved through auto-parameterization because it was a trivial plan. A trivial plan is not kept in cache because there is almost no generation cost for them. That'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
March 16, 2009 at 6:19 am
Is BlogEntry by chance a view? Does the underlying table have a different datatype than what you have presented here?
"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
March 16, 2009 at 6:15 am
I worked somewhere similar, everyone in the company had 'sa' privs on production. Made for a few entertaining late night phone calls followed by some serious screaming matches the next...
"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
March 16, 2009 at 6:13 am
The issue is that you have either table or column collation settings on the first set of data are different than on the second set. You'll need to look 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
March 16, 2009 at 6:07 am
Only if you can't reapply them. It's fairly common practice for really large scale data moves to remove indexes and foreign keys at the beginning of the move and then...
"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
March 16, 2009 at 6:01 am
moojjoo (3/14/2009)
"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
March 14, 2009 at 10:17 am
Since it's not executing, can you post the estimated execution plan?
It sounds like you might be getting some blocking. Are there other processes hitting the table at the same time?
"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
March 14, 2009 at 5:37 am
Amit Lohia (3/13/2009)
I do not think it will make much difference but my testing is on platform 64
I think that's worth noting. Now we know it happens on two platforms....
"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
March 13, 2009 at 11:00 am
If it's two different plans, that's probably the issue.
Make sure the same parameters are in use on both and make sure that both have updated statistics and defragmented indexes.
The very...
"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
March 13, 2009 at 10:30 am
Different parameters?
"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
March 13, 2009 at 10:23 am
Nope removing the certificate didn't fix the issue. That makes me feel better. There must be an alter database statement that removes the reference to encryption.
"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
March 13, 2009 at 8:27 am
Nuts. I might have been premature in posting to Connect. I finally found another reference:
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=351548&wa=wsignin1.0
I'm testing removing the certificate now.
"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
March 13, 2009 at 8:20 am
I posted it to Connect:
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=423249
You can vote on it, set the priority, add your comments, especially since this is your issue.
I'm going to keep hacking at it as time allows.
"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
March 13, 2009 at 8:14 am
I hit the same issue. I went back to retest and now I'm hitting the issue on the test database, where I didn't hit it before...
I'm trying to track down...
"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
March 13, 2009 at 7:59 am
Viewing 15 posts - 18,016 through 18,030 (of 22,226 total)