July 31, 2012 at 1:52 am
Dear all,
I have a database on SQL Server 2008 R2 enterprise edition whose backup suddenly running slow since a server restart. following are the info
1) Database size is 300 GB. Database contains filestream data. Filestreams contribute to most of the size.
2) Database partcipates in merge replication., but for most of the articles it is a subscriber. There about 50 publishers.
Usually the backup takes 1-3 hours. After a Windows security patch and a server restart, the full backup is taking 30+hours.
Remaining performance of the server appears normal. Replication is performance is also good. Any clue why full backup with filestream data is so slow all of a sudden.? Thanks in advance.
Regards,
Raj
July 31, 2012 at 6:18 am
No way to know for sure why you're suddenly seeing slow performance. Can you gather more metrics? Take a look at sys.dm_exec_requests. Can you see the backup process? Is it blocked? What is the latest wait state on it? Does it show a percentage complete? This information will help you troubleshoot what's going on.
"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
August 2, 2012 at 7:07 am
"Database is slow" is similar to saying "the internet's broken" when you cant connect to wifi. There are many many potential causes. We need to do is narrow it down the statements to "this specific query is now running x times slower, or something like that.
you have given one exampe with your backup now taking 30 hours. Now we have a reproducable issue we can test and debug against. Next step is to find out why this is slow.
In SQL Server your first port of call for performance issues should always be the wait stats.
Paul Randall has a great article that comes with a query to look at your wait stats.
http://www.sqlskills.com/BLOGS/PAUL/post/Wait-statistics-or-please-tell-me-where-it-hurts.aspx
I would run this, store the results.
Kick off your backup thats taking 1000% more time than usual.
Intermittently run the wait stats script and store results to a table.
Do a delta to check what wait stats are causing you the most pain when this backup is running.
This may not give you the actual cause but at the very least it will point you in the right direction to investigate the issue further.
I use this process for absolutely all performance issues on SQL Server as a frist step for debugging and analysis.
If your still having trouble after you get the wait stats, post them here.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply