Viewing 15 posts - 13,111 through 13,125 (of 22,219 total)
Make sure you have beefy machinery. I'd suggest reading up on Brent Ozar's blog because he's posted on virtualization quite a bit.
"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 1, 2011 at 2:58 pm
No, that's absolutely not one I've heard of before. If uninstalling and reinstalling didn't fix it, you may not have completely uninstalled and left some SQL Server components. But it...
"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 1, 2011 at 2:56 pm
Do you have a timeout setting on the connection string? If not, put one there. I'm pretty sure if you set it to zero it will be infinite. But, if...
"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 1, 2011 at 2:49 pm
jcrawf02 (3/1/2011)
Brandie Tarvin (3/1/2011)
How 'bout I throw some high heels, a mini skirt, and a lumberjack into the mix to really leave you screaming for the brain bleach?@=)
I.....no, I can't...
"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 1, 2011 at 2:10 pm
You're kind of stuck. There's no way to simply modify the column. You can recreate the table, which is what the GUI is trying to do for you, or 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
February 28, 2011 at 5:39 pm
The basic syntax is like this:
CREATE TABLE x
(MyIdColumn int identity(1,1))
"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
February 28, 2011 at 4:52 pm
And the TSQL syntax is to add REPLACE to the WITH clause of the backup.
"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
February 28, 2011 at 4:41 pm
Jeffrey Williams-493691 (2/28/2011)
"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
February 28, 2011 at 4:00 pm
If you just put a delay in the transaction log backups during that period you can avoid the issue. That's what I'd do. Otherwise, no, I don't think a driving...
"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
February 28, 2011 at 2:38 pm
It kind of depends on the type of log backup failure, but yes, some of them will break the recovery chain. You'll pretty much know the next time you go...
"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
February 28, 2011 at 1:34 pm
Even though the database is in 80 compatibility, I'm pretty sure you can capture the exec plans from cache, so if the bad plan happens, snag it quick, jsut before...
"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
February 28, 2011 at 1:30 pm
Just a side comment, frequently when dealing with UNION, UNION ALL is a way of speeding things up, not slowing things down. If you're hitting problems, it must have to...
"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
February 28, 2011 at 1:29 pm
Not seeing the full plan, I can't guarantee my answer, but, if the operator accessing the cluster says that it's a key lookup operation, deferred or not, that's what it...
"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
February 28, 2011 at 1:25 pm
Glitch. Edited.
"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
February 28, 2011 at 1:20 pm
I find the deadlock graph in Trace can sometimes not provide enough information to really figure out what's up with some deadlocks. You might be better off using the data...
"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
February 28, 2011 at 1:19 pm
Viewing 15 posts - 13,111 through 13,125 (of 22,219 total)