Viewing 15 posts - 6,676 through 6,690 (of 22,226 total)
It's not a perfect solution because if you have heaps it won't work, but you can look to the sys.dm_index_usage_stats for everything 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
February 26, 2015 at 6:12 am
Brandie Tarvin (2/26/2015)
Jeff Moden (2/25/2015)
Brandie Tarvin (2/25/2015)
"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 26, 2015 at 4:44 am
Thanks for posting the answer to your question. That'll be helpful when someone else with the same one finds this using a search.
"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 26, 2015 at 4:27 am
And go and have the discussion with the business people about the recovery point objectives and recovery time objectives for this database.
"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 26, 2015 at 4:26 am
If the text isn't visible from sys.dm_exec_sql_text, then it's gone. But, you can prove it's an open transaction by looking at sys.dm_tran_active_transactions.
"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 26, 2015 at 4:25 am
The column is storing the entire name? Up front, that's a bad design.
You could use the LEFT function in combination with the CHARINDEX function to find the location of 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
February 26, 2015 at 4:22 am
Yeah, it just grows. There isn't a default size. Best to follow an approach similar to what Shafat suggests above.
"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 26, 2015 at 4:18 am
fdthompson35 (2/25/2015)
personid
personnum
fullnm
we want the following field from the ASSIGNPAYRULE TABLE
payruleid
where the personid from the PERSON table = the employerid in 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
February 26, 2015 at 4:14 am
It does, thanks. And Gail nailed it. You need to go the previous one.
"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 25, 2015 at 12:15 pm
Not that I'm aware of, no.
"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 25, 2015 at 11:56 am
You keep saying "restore during".
So, point of clarification for me. Do you mean you're going to try to restore the same database that a backup is being run against? Because...
"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 25, 2015 at 11:45 am
If it's saying your log backup is incorrectly formed, it might be corrupted. Try doing the restore without a stopat as a test. Oh, and not on the production box...
"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 25, 2015 at 11:24 am
Those are cross-database queries and not technically connections between the databases. First, I'd suggest reexamining your security to prevent that type of stuff if it's occurring in ways you don'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
February 25, 2015 at 11:22 am
Yeah, I'd validate it by querying the cache directly using DMVs.
Nothing using WITH RECOMPILE? No one running DBCC FREEPROCCACHE? Nothing like that?
"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 25, 2015 at 7:18 am
Just a plus one to what Gail said. Better to capture diffs so you still have the accumulated values.
BTW, running it doesn't hurt, but if you ran it over and...
"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 25, 2015 at 5:35 am
Viewing 15 posts - 6,676 through 6,690 (of 22,226 total)