How much space in the DB will be saved by using RBS?

Question

We are doing a migration from SP 2010 to 2013. We are going site by site (moving content databases to a new server). Some of the content databases are over 200GB, from what I can see mainly due to document versioning.

The theory is that by going to RBS, we will gain "white space" in the content databases, and I will shrink them so that we will get a 1-to-1 exchange in disk space.

I'm a SQL Server DBA, this seems like "crazy talk" to me. ;)

1. Shrinking any database (especially one over 200GB!) is in general a risky endeavor, and may or may not even happen - SQL is just not fond of performing this action.

2. How will this transformation even work? I can understand replacing non-structured data (BLOBS) with an external link, but with multiple versions of, say, word documents currently existing in the database, how long is that going to take? Is it going to clean up after itself when it is done?

I've read several white papers, but unfortunately different people on my team are each interpreting them in different ways.

If anyone can answer these questions, thanks in advance. Any links to blogs or white papers are also appreciated.

FYI: SQL Server 2012 Windows 2012 R2 Sharepoint 2013 (upgrade from 2010)

Answer 1

Before answering your questions, i want to recommend the following excellent technet article:
Deciding to use RBS in SharePoint 2013

Just because you have a content database growing larger than 200GB, you do not have to implement RBS. RBS is mainly a feature to reduce storage-cost by getting BLOBs away from expensive SQL-Storage (like SSDs). RBS adds a lot of complexity to your environment. Especially backup&restore must be planned accordingly as a Database-Backup will no longer cover your BLOBs. Your administrators should fully understand what happens when using RBS to still be able to troubleshoot your farm if something goes wrong. Or get a experienced consultant.

How do you plan to implement RBS? FileStream-Provider or 3rd party tool? There are different things to consider depending on this decision.

Your questions:

1. Shrinking a database from this size will work. I have done this several times. But as you might know, you get massive fragmentation while shrinking. So this is something you normally want to avoid. If shrink is necessary, you should rebuild your indexes after the shrink-operation.

2. SharePoint has a function called Migrate() for RBS. After configuring RBS, you can trigger this function on the SharePoint-Server and it will extract existing BLOBs from the database to the disk. This operation will take time, as all extracted content flows across your SharePoint server.

3. (Topic): Saved space in the database relies massively on the options you set. If using FileStream provider, your only choice is the filesize. If you use 3rd party tools, you can specify a lot more parameters (like modify-date etc.).

Answer 2

Back when I was testing StoragePoint before they were acquired by Metalogix, I was seeing anywhere from 97 to 99% Content DB size reduction. The tool allowed for a lot ot flexibility in determining what types and size limits of fiels that should be offloaded. The more aggressive the file size limit you made, the more was offloaded and the smaller your content DBs become.

The files come into the content db, a guid is written to the db with the id of that blob then it gets ushered out to the blob store. When someone asks for that file, it gets the GUID, fetches it from the blob store and serves it up. There are some timer jobs that run to keep the blob store data "in tune" with the content DBs so you don't end up with orphan blobs.

You might not need to utilize the blob store, they made some improvements to versioning in 2013 so it isn't storing full copies any more. Also enforcing version limits instead of the default unlimited can help keep that data in check.

RBS does make for a more complex backup and recovery process as well.

Answer 3

1. Shrinking the Database is not big problem, we had issue in past where a content DB grew upto 600GB(due to audit log) then we trim the audit log and shrink the DB to get the space back, so shrinking 200 GB is not an issue.

   • You can refer this white paper to DBA

   • Their is another way without involvement of DBA. If you browse Central admin and check the health analyzer rule called "Database has large amounts of unused space". once you done with the RBS, run this rule(by default it runs weekly) and it will list all the database which have white space. Now if you edit the rule and check the box "Repair Automatically". So next time when this rule detect the white space it will shrink automatically without letting any one know. But i would do it one time only.

2. As Mheld migrate() command at the end will move the data from CDB to RBS and then you will get the white space in the db. First time migration is not easy task as it will pull all the files from DB and put in the folders.

We recently did our research and testing, for files less than 50MB will create more performance issue then the saving the costs on space. As you know, the flow is from SharePoint to SQL and from from SQL to RBS. So plan your environment according and test it before.