There has been a lot of misconcenption around remote blob storage (RBS) capabilities with SharePoint 2010. For some time many thought that RBS would be a optional feature included in the core release of SharePoint 2010/SharePoint Foundation 2010. We know now that this is simply not the case. The StoragePoint team has previously published materials comparing the features of the RBS FileStream Provider (an additional downlad that is part of a feature pack) with StoragePoint. You can view that comparison here. Microsoft has recently published a short white paper detailing RBS options with SharePoint Foundation 2010. This is an excellant white paper that identifies the need for RBS (scalability and storage costs) along with addressing misconceptions about the capabilities of the RBS FileStream Provider. For quite a while I have asserted that the RBS FileStream provider was purpose built to support upgrades from WSS 3.0 w/ WIDE (Windows Integrated Database) option and that RBS FileStream is not an enterprise solution. The recently published document confirms my previous assertions. You can download a copy of the white paper here http://www.microsoft.com/downloads/en/details.aspx?FamilyID=90ef5bf8-915e-41bd-806b-f915fbf5d353&displaylang=en
Yesterday we announced a new webinar series where we will review and demonstrate the features of StoragePoint 3.0. StoragePoint 3.0 is a highly anticipated release that provides significant advancement over our already robuts BLOB remoting capabilities for SharePoint 2007 and SharePoint 2010. New features like Intelligent Archiving, Multiple Storage End Points, and advanced reporting capabilities significantly reduces the total cost of ownership of SharePoint deployments while providing improved performance, reduced backup/restore time frames, and flexible storage options . StoragePoint 3.0 is a must have for organizations deploying any level of document management or enterprise content management solutions on SharePoint 20007 or SharePoint 2010. To register for an upcoming webinar please visit our Event Brite page at http://storagepoint.eventbrite.com. For more information on StoragePoint visit www.storagepoint.com, blog.storagepoint.com, or www.youtube.com/user/storagepoint.
Organizations are often tasked with storing content in a compliant way. Whether you are dealing with SEC, HIPAA, SOX, or DOD compliance scenarios, SharePoint’s native storage architecture fails to meet the level compliance that organizations require. Enter StoragePoint. By leveraging supported APIs and interfaces, StoragePoint alters the native SharePoint storage architecture allowing you to separate the BLOB (Binary Large Object) from the content metadata. The metadata is stored within SharePoint Content Databases while the BLOB can be remoted to a variety of storage locations. For complaince scenarios organizations often turn to EMC Centera to provide WORM (Write Once Read Many) storage. StoragePoint provides a certified storage adapter for storing SharePoint content on EMC Centera. EMC recently certified our StoragePoint adapter. Check out the press release. http://finance.yahoo.com/news/Metalogix-Releases-bw-3469966683.html?x=0&.v=1
The marketing folks on the StoragePoint team recently released a very compelling StoragePoint customer evidence video. The list of customer success stories with StoragePoint continues to grow. There is little question that StoragePoint is the premier BLOB remoting solution for SharePoint. Check out the video below. For more information on StoragePoint visit http://www.storagepoint.com. Stay tuned for information on the highly anticipated release of StoragePoint 3.0 with full support for SharePoint 2010.
It’s not uncommon to have multiple SharePoint content databases for a single SharePoint application. The separation of site collections into different content databases is typically done in an attempt to work around content database size recommendations provided by Microsoft (see Microsoft’s Plan for Software Boundaries document for more information). In many cases organizations have one content database per site collection. After deploying StoragePoint into your existing SharePoint farm the next logical step is to run the externalize job(s) which will relocate your existing content outside of the content database. Once completed you will be left with very small content databases that can now be merged (note that you will have to run the DBCC_ShrinkDB script several times to reclaim your unused database space or rebuild table indexes before running dbcc_shrinkDB. For more information consult the StoragePoint Administrator’s Guide). Merging SharePoint content databases can be done using the stsadm command. Execute the steps below to merge your content databases.
- **** Important! Microsoft recommends applying the April Cumulative Update before you merge content databases. There are known issues with this merge database command prior to this update.
- Even though your content databases will be very small after relocating BLOBs with StoragePoint’s externalize job, you must make sure you have enough free space to merge content databases. The general rule is that you must have at least three times the size of source site collections database size. *** Note: Do not use the value returned for the StorageUsedMB property when running the stsadm -o enumsites -url webappurl to determine your database size. With StoragePoint deployed this property will reflect the total space used by content in SharePoint but not the actual size of the content database.
- In order to execute the following STSADM command you must be a member of the Farm Administrators group and be an Administrator on the local computer. Additionally you need to have Full Control permission for any site collection being moved. For SQL Server, you must be a member of the db_owner database role.
Steps to Merge Content Databases
- From a SharePoint server in your farm, open a command prompt and navigate to %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin
- Type the following STSTADM Command
STSADM –o mergecontentdbs –url <url of web application> –sourcedatabasename <source db name> –destinationdatabasename <dest. db name> –operation2 Note that the URL is the URL of the web application that contains the site collection. This is not the URL of the site collection itself.
Operation2 = full database merge
- Restart IIS by running iisreset/noforce from a command prompt.