Follow storagepoint on Twitter
All posts by thellebuyck

Merge Content Databases After StoragePoint Externalization

by thellebuyck 6. March 2010 18:13

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.

Prerequisites

  1. **** 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.
  2. 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. 
  3. 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

  1. From a SharePoint server in your farm, open a command prompt and navigate to %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin
  2. 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
  3. Restart IIS by running iisreset/noforce from a command prompt.

Tags: , , , ,

BlueThread Wins Innovative SharePoint ISV Award at SPC09

by thellebuyck 19. October 2009 08:49

BlueThread Technologies, Inc. was awarded the Innovative SharePoint ISV Award at 2009 SharePoint Conference during Jeff Teper's keynote address.  For more information on BlueThread Technologies and StoragePoint visit http://www.bluethreadinc.com and http://www.storagepoint.com

Tags:

The Throwdown results are in!

by thellebuyck 6. May 2009 18:29

It has been a long day but the results are in!  Since the 1 million document bulk load test finished early (approximately 5 hours and 45 minutes) we decided to keep the test going.  We ran the test until we maxed out the test harness meter at a 250GB content database for the SharePoint instance NOT running StoragePoint.   The results overwhelmingly favor using StoragePoint in conjunction with your SharePoint implementation. Simply put, if you have SharePoint you should be running StoragePoint. 

There are some important things to note as you review the test results.  SharePoint running with StoragePoint is about 45% faster at insertion and retrieval of document library items with encryption and compression enabled.  The resulting size on disk of the compressed externalized content is 48GB (the uncompressed size is 334GB) which is an approximate compression ratio of 85.6%.  In essence StoragePoint increases the read’write performance of content BLOBs to SharePoint, reduces the SharePoint content database size, while providing a smaller footprint on disk and increased security through encryption.

To put things in perspective, running StoragePoint we successfully bulk loaded 1,615,982 files into SharePoint in just under 10 hours with the resulting SharePoint content database being 8.5GB.  The total disk spaced used was 56.5GB (334 GB compressed down to 48GB plus 8.5GB for SharePoint list metadata).  I am not sure we can provide evidence that is anymore compelling than that …

After approximately 10 hours of testing the results are as follows:

StoragePoint Features Enabled

  • 256 bit AES Encryption
  • File Compression
  • File System Adapter
SharePoint without StoragePoint
 Total Documents Imported 1,099,082
Content Database Size 250 GB
SharePoint with StoragePoint
 Total Documents Imported 1,615,982
Content Database Size 8.5 GB
Size on Disk of Externalized Content 334 GB of externalized data compressed to 48 GB
Content Database Size 8.5 GB

Final Numbers

 

Final Compression Results 

 

Disclaimer:  Your mileage will vary with compression and performance. While StoragePoint, in general, improves performance of SharePoint many factors impact compression and performance including file sizes, file types, file structure, and underlying server infrastructure.

Tags:

Excited about StoragePoint

by thellebuyck 6. May 2009 07:40

A event participant at the SharePoint Techfest 2009 was so excited about StoragePoint that he spilled his coffee all over the BlueThread booth. 

P5060233

Tags:

(Updated) The Throwdown: Hour Eight Update

by thellebuyck 6. May 2009 05:54

Update test results.  Just over eight hours in. 

SharePoint without StoragePoint
Elapsed Time:  8 hours, 4 minutes, 42 seconds
Documents Imported: 969,074
SharePoint Content Database Size:  223.4 GB

SharePoint with StoragePoint
Elapsed time: 8 hours, 4 minutes, 39 seconds
Documents Imported: 1,349,144
SharePoint Content Database Size: 7.0 GB

Percent Smaller: 96.9%  


Hour Seven Update

Update test results.  Just under seven hours in. 

SharePoint without StoragePoint
Elapsed Time:  6 hours, 59 minutes, 42 seconds
Documents Imported: 878,493
SharePoint Content Database Size:  202.5 GB

SharePoint with StoragePoint
Elapsed time: 6 hours, 59 minutes, 40 seconds
Documents Imported: 1,189,415
SharePoint Content Database Size: 6.3 GB

Percent Smaller: 96.9%  


Hour Six Update

Update test results.  Just over six hours in. 

SharePoint without StoragePoint
Elapsed Time:  6 hours, 2 minutes, 3 seconds
Documents Imported: 793,286
SharePoint Content Database Size:  182.9 GB

SharePoint with StoragePoint
Elapsed time: 6 hours, 2 minutes, 0 seconds
Documents Imported: 1,043,086
SharePoint Content Database Size: 5.4 GB

Percent Smaller: 97.0%  


Hour Five Update

Update test results.  Just over five hours in. 

SharePoint without StoragePoint
Elapsed Time:  5 hours, 1 minutes, 3 seconds
Documents Imported: 693,399
SharePoint Content Database Size:  159.9 GB

SharePoint with StoragePoint
Elapsed time: 5 hours, 1 minutes, 2 seconds
Documents Imported: 905,134
SharePoint Content Database Size: 4.7 GB

Percent Smaller: 97.0%  


Hour Four Update

Update test results.  Just over four hours in. 

SharePoint without StoragePoint
Elapsed Time:  4 hours, 1 minutes, 2 seconds
Documents Imported: 586,855
SharePoint Content Database Size:  135.3 GB

SharePoint with StoragePoint
Elapsed time: 4 hours, 1 minutes, 0 seconds
Documents Imported: 745,478
SharePoint Content Database Size: 3.9 GB

Percent Smaller: 97.1%  


Hour Three Update

Update test results.  Just over three hours in. 

SharePoint without StoragePoint
Elapsed Time:  3 hours, 3 minutes, 24 seconds
Documents Imported: 474,788
SharePoint Content Database Size:  109.5 GB

SharePoint with StoragePoint
Elapsed time: 3 hours, 3 minutes, 22 seconds
Documents Imported: 586,172
SharePoint Content Database Size: 3.0 GB

Percent Smaller: 97.2%


 Two Hour Update

Just over two hours into the test and we have updated results:

SharePoint without StoragePoint
Elapsed Time:  2 hours, 2 minutes, 6 seconds
Documents Imported: 342,116
SharePoint Content Database Size:  78.9 GB

SharePoint with StoragePoint
Elapsed time: 2 hours, 2 minutes, 4 seconds
Documents Imported: 406,727
SharePoint Content Database Size: 2.2 GB

Percent Smaller: 97.3%

 P5060231

 


 One Hour Update

We are just over an hour into the test at the SharePoint Techfest 2009 and the result thus far are:

SharePoint without StoragePoint
Elapsed Time: 1 hour, 0 minutes, 26 seconds
Documents Imported: 183,164
SharePoint Content Database Size: 42.2 GB

SharePoint with StoragePoint
Elapsed time: 1 hour, 0 minutes, 24 seconds
Documents Imported: 210,452
SharePoint Content Database Size: 1.1 GB

Percent Smaller: 97.3%

P5050228 

Tags:

The Throwdown: SharePoint vs. SharePoint with StoragePoint.

by thellebuyck 6. May 2009 04:25

SharePoint Techfest 2009 is upon us and we are getting ready to begin the throw down between SharePoint and SharePoint running StoragePoint.  But first we need to discuss the basic foundation for the tests that we are about to execute.  The StoragePoint team has assembled two identical Dell PowerEdge T605 servers (see the server specifications below) running identical SharePoint environments (environment configuration is listed below as well).  The only difference between the servers is that one is running StoragePoint 2.0 … oh and one was dropped from the back of an SUV onto the pavement … no seriously it happened …  and for good measure we are running StoragePoint on the server that looks like it came from the dent-and-scratch soup can bin at your local grocery store.  To our surprise a 75 pound Dell server can survive a three foot drop onto concrete.  I am beginning to think Dell actually does drop tests on servers.

Server Specifications
CPU 2 – Quad Core AMD Opteron 2378
Memory 8GB
Disk 2 – 250GB SATA (7200RPM)
1- 1 TB SATA (7200 RPM)
Disk Controller SAS6/iR (SATA/SAS Controller)
No RAID
Operating System Windows Server 2003 R2 SP1 Enterprise x64
Database SQL Server 2005 Enterprise x64
SharePoint MOSS 2007 SP1 Standard x64

 

As you can see these are extremely modest servers costing around $1500 each … and we are about to slam 1 million documents into each server (documents varying in size with an average size of 214KB).  I know what you are thinking.  This flies in the face of everything that you have heard about SharePoint scalability.  Let me be the first to tell you that it is possible to manage millions (that’s millions with an “s”) of documents in SharePoint without StoragePoint 2.0.  Adding StoragePoint 2.0 to the mix makes managing millions of documents in SharePoint significantly easier and allows you to put more content in SharePoint running on modest amounts of hardware. 

 

The test:  Bulk load (using BlueThread’s Import Manager product) a sampling of 1 million documents over the course of the day to determine which environment performs better and which environment contains smaller content databases.  Rob D’Oria has developed a slick dashboard that will monitor the servers (elapses time, document counts, and content database sizes) throughout the day.  Here is a screenshot of what you will see if you are visiting us at the SharePoint Techfest 2009 event.  I will be posting actual images of the test throughout the day so check back to receive updates on the progress of the tests.

Warning: The following is a screen shot containing sample data.  I will update the StoragePoint blog throughout the day with images of the actual test. 

Demo Console

Tags:

Introducing StoragePoint 2.0

by thellebuyck 5. May 2009 11:35

SPIcon-v.final18
We are very pleased to announce the launch of the StoragePoint 2.0 Release Candidate Program.  StoragePoint is an innovative product by BlueThread Technologies, Inc. that greatly improves manageability and improves scalability Microsoft Office SharePoint Server (MOSS) 2007 or Windows SharePoint Servers (WSS) 3.0.  In essence StoragePoint allows organizations to externalize binary large objects (BLOB) to direct attached or network addressable storage.  Having this ability greatly reduces the size of SharePoint content databases and, in most cases, increases overall read/write speeds of BLOB data.  Most of you probably already know that the storage of BLOBs in SQL Server databases raises some concern, warranted or not. StoragePoint alleviates these concerns while addressing critical areas such as compliance, security, disaster recovery. 

StoragePoint 1.0 introduced the ability to externalize BLOB data as a function of the MOSS record center.   The primary driver for this functionality was document life cycle management and support for common Enterprise Content Management (ECM) scenarios.  Essentially content being declared as a record could be externalized to direct attached, network addressable, or compliance based (WORM – Write Once, Read Many) storage devices.  The introduction of StoragePoint 2.0 now allows for similar externalization capabilities with BLOB data stored in any SharePoint site template, document library, and/or SharePoint list. 

In the coming weeks the StoragePoint team will blog about the various aspects of implementing StoragePoint including planning, installation/configuration, security, compliance, and disaster recover.  If you would like to download and try the release candidate click here

Tags:

Powered by BlogEngine.NET 1.5.0.7
Theme by Mads Kristensen

Calendar

<<  July 2010  >>
MoTuWeThFrSaSu
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678

View posts in large calendar