SPTechWeb Logo
Home About Us  Advertise       
 
 

Why SharePoint admins need a say in storage




September 12, 2013 —  (Page 1 of 2)
Sharing information and collaborating on work has increased productivity as well as fostered creativity. As SharePoint deployments grow with the business, application managers have more data to maintain. But it also poses a challenge to the storage admin who suffers from performance degradation as well as increased acquisition costs. Both impede the benefits of the organization’s collaboration and the value of the document-management solution.

There are five common challenges that application managers face due to SharePoint running sub-optimally on traditional storage subsystems. I’m writing to tell you the suffering can end for application, storage and database administrators.

1. Size of the database
The size of the content database has always been a challenge for SharePoint application managers. It used to be 200GB, and now with SharePoint 2012, it can go up to 4TB. This 4TB scale-up gives a completely different approach to the required storage perspective.

The recommended number of IOPS for performance is 2 IOPS per GB. So this means that for a 4TB content database the storage system needs to deliver 8,000 IOPS per content database. This would mean that for 200TB in a SharePoint farm, you need to have 400,000 IOPS. What kind of impact does this have on your application performance? Better yet, how quickly can the data be retrieved and delivered to the end user? These are important questions to consider in avoiding an unhappy user experience with the phenomenal growth of the storage consumption and the user connectivity.

2. DBCC consistency checks
The main reason to use bigger databases is the reduction of servers and SQL Server licenses. The size of a content database has a negative impact on the database consistency check. The data integrity of the SQL Server needs to be regularly checked. The bigger the database size, the longer it takes.

This is a maintenance task and cannot be run during production hours. Four terabytes is 20x the previous size of the content database. If the previous consistency checks took one hour, will that be 40 hours for a 4TB environment? How will that impact the other maintenance requirements, like backup? It will only leave eight hours in the weekend to get that in order.

3. Index and statistics defragmentation
When the database is indeed growing up to 4TB per content database, it is also clear that the index and statistics defragmentation will take longer. The index has about 20% of the content database as a sizing rule. This means that the defragmentation needs to happen on 800GB rather than on 40GB. This will have a major impact on the amount of time for performing this task. And it cannot be scheduled like the consistency checks; this will occur randomly at the point that SharePoint finds it necessary. The end result is that it will have an impact on the user experience for all the databases running from the same SQL Server.

Pages 1 2 


Share this link: https://sptechweb.com/link/64098

Add comment


Name*
Email*  
Country     






 
 
This site's content Copyright © 1999 - 2013 by BZ Media LLC, All rights reserved.
Legal and Privacy
• E-mail: