Viewing 15 posts - 2,806 through 2,820 (of 22,219 total)
I have not seen this behavior. Is the size allocated smaller than the actual size? I've seen that cause problems. Try flushing it to see if that clears the collection....
"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
January 10, 2019 at 7:01 am
"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
January 9, 2019 at 5:30 am
Take one database and try running a full backup on it, then running a log backup (both manually, both using standard SQL Server BACKUP commands). Maybe that first full 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
January 8, 2019 at 8:45 am
Sure. Still, lots of coordination will be involved in putting the view in place over the table so that the code isn't affected, renaming the table underneath that (because 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
January 8, 2019 at 8:20 am
Since it's a primary key on the table, you are really limited in choices. I'd would experiment on the side with every one you outlined. Testing is going to 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
January 8, 2019 at 8:04 am
One exception to what I just typed, the very first full backup and the very first log backup ever taken on a given database are kind of linked. However, once...
"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
January 8, 2019 at 7:16 am
Full backups and log backups are not directly connected (Differentials on the other hand...). Just talking about full backups, whether from commvault or not, shouldn't be affecting log backups. Instead,...
"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
January 8, 2019 at 7:15 am
I was in your shoes 1 year ago and just studying is 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
January 3, 2019 at 5:28 am
Specifically this stuff:
(covert(int,n.SSICatyear) = year(convert(int,ep.proceduredate)))
Is going to kill performance.
"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
January 3, 2019 at 5:13 am
In terms of overall impact to the server, I'd pick extended events over audit, every day. Audit is much more likely to have a negative impact on the instance.
"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
January 3, 2019 at 5:10 am
And, calculations like this are best done into a variable once:
@SearchTextLenght + @Q - 2
Having it in the filter criteria leads to problems.
"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
January 2, 2019 at 8:57 am
Just so the link to my book is on the thread...
Look below in my signature.
"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
January 2, 2019 at 8:29 am
"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
January 2, 2019 at 8:28 am
Go with Muthukkamaran's advice. Change the Cost Threshold to a higher value and then leave everything else at the defaults until you see a reason to change through monitoring. "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood" Author of:
- Theodore Roosevelt
SQL Server Execution Plans
SQL Server Query Performance Tuning
December 20, 2018 at 6:59 am
Maybe I don't understand what you're doing then. I don't know how you went from backups to Elastic Query as a way to solve a database refresh. Since the backups...
"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
December 20, 2018 at 4:49 am
Viewing 15 posts - 2,806 through 2,820 (of 22,219 total)