Viewing 15 posts - 7,681 through 7,695 (of 22,219 total)
If it's just doing scans (no WHERE clause), you're completely subject to any number of areas of contention, on the disk, in memory, on the CPU. You could be seeing...
"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
July 23, 2014 at 3:47 am
First off, are you taking regular log backups? If you're not taking those, then you can't do a restore to a point in time anyway. Determine if you need 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
July 23, 2014 at 3:45 am
All I can do is guess based on what you've provided.
How about using SQL Agent. When you set up the Job in SQL Agent you'll have to create Steps. 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
July 23, 2014 at 3:41 am
Lynn Pettis (7/22/2014)[hr
It really comes down to using the right tool for the job.
+INFINITY!
"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
July 22, 2014 at 12:43 pm
But, doing what Jack is suggesting will mean that you still have data in the table that doesn't match the related table. I'd suggest tracking that data down and fixing...
"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
July 22, 2014 at 11:43 am
You have to look at the execution plan to understand how the query is being resolved. It may not be using your index at all, or it might just 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
July 22, 2014 at 11:42 am
New Born DBA (7/22/2014)
Grant Fritchey (7/22/2014)
Learn PowerShell.Automate all the things.
Would love to, but where should I start?
My preferred PowerShell instructor, for just PowerShell itself, is Don Jones. He has...
"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
July 22, 2014 at 9:37 am
ananda.murugesan (7/22/2014)
server side 800 GB freespace available at log file partition, so I am not executed that command let it be gorw that file....
"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
July 22, 2014 at 8:28 am
Absolutely what Gail says. But, the real issue is going to be, what happens next time you run index maintenance, etc. Isn't the log just going to grow again? 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
July 22, 2014 at 6:35 am
J Livingston SQL (7/19/2014)
...and here is a link that defines your problem exactly...including poor grammar and spelling errors....hmmmmm:-)http://p2p.wrox.com/access/28374-ms-access-mdb-ldb-database-corrupted.html
Oh, I get it. They're going to create some sock puppets to answer...
"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
July 22, 2014 at 5:54 am
J Livingston SQL (7/19/2014)
...and here is a link that defines your problem exactly...including poor grammar and spelling errors....hmmmmm:-)http://p2p.wrox.com/access/28374-ms-access-mdb-ldb-database-corrupted.html
OK, that's officially weird on several levels. What the heck is it hoping...
"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
July 22, 2014 at 5:51 am
The only way to shrink the size of the file is to shrink the size of the file.
If your file is growing too large, you have a couple of choices....
"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
July 22, 2014 at 5:48 am
Learn PowerShell.
Automate all the things.
"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
July 22, 2014 at 5:46 am
Yeah, I agree with John, test it.
It's a pretty standard approach when you're doing large scale inserts to drop the indexes. This is because maintaining indexes across all the inserts...
"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
July 22, 2014 at 5:44 am
If you need to access data on more than one database within Microsoft Azure SQL Database, you must do that at that application level. The databases are absolutely isolated from...
"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
July 22, 2014 at 5:40 am
Viewing 15 posts - 7,681 through 7,695 (of 22,219 total)