Here’s an interesting question that came in to our questions line (questions@SQLskills.com – no guarantee of an answer – I check it every so often): I have seen demonstrations where a large database being broken down into smaller ones using synonym names. I think it was used on a data warehouse and allowed smaller database backups instead of doing one large one and simulating file group backups. Is there somebody who has worked with this variation and can identify when this would be an advantage over file group backups if there is even an advantage. My answer will always be to keep the VLDB (Very Large DataBase) as a single unit and go with filegroups if you need to. Breaking the VLDB into smaller databases has some serious issues: These are just the ones that spring to mind in 5 minutes – I’m sure there are more if I sat and thought about it longer (e.g. how to create a database snapshot, run a consistency check, …) So – IMHO it’s always going to be easier to backup and restore a single VLDB split into filegroups than a VLDB split into multiple databases. PS If there’s something you’d like to see me do a blog post on, shoot me an email here.
Summer School Savings SALE is live!
Happy Fourth of July to all who celebrate! I’m looking forward to a great view Thursday evening looking west along the Skagit Valley with some
4 thoughts on “Search Engine Q&A #17: Split a VLDB into filegroups or smaller databases for backups?”
Hello Paul:
I need your expertise advise. i have seen that many recommends to do split backups for faster backups and i am not convince with that unless there are multiple physical drives present to do so. its my understanding that there is one thread per physical drive and splitting multiple file backups on one drive will slow down.
Any pointer, article or white paper is greatly appreciated.
Thanking you in advance.
Jay
http://technet.microsoft.com/en-us/library/ms190954%28v=sql.105%29.aspx
Hi Paul,
I need advise on the issues our DBA’s (I am not a DBA) are facing. Our Database is on MS SQL 2014 with a size of approx 6.9 TB and growing on monthly basis. We have our file groups partitioned into monthly partitions. Our DBA’s complains regularly regarding DB back-up and restoration time, the time it takes to archive data, problem of maintaining indexes etc.
The management direction is to break down the databases into yearly partitions and bases on operations needs they will decide how many years worth of data will be available on production at one time.
What are my options in this scenario.
This is way too big a discussion for a blog post comment. Check out Kimberly’s recent blog post on partitioning: https://www.sqlskills.com/blogs/kimberly/sqlskills-sql101-partitioning/