email article printer friendly more resources

Ensure SPS Capacity and Integrity
Follow proven best practices for SharePoint Portal Server 2003 storage-capacity planning, risk mitigation, administration, and maintenance.
by Kenton Gardinier

Posted January 13, 2004

For This Solution: Microsoft SharePoint Portal Server 2003, Microsoft SQL Server 2000

SharePoint Portal Server (SPS) 2003—released in late 2003 as part of Microsoft Office 2003—has already proven to be dramatically more scalable, reliable, and versatile than its predecessor. Although still primarily a document- or knowledge-management portal solution, SPS can now also be a viable means of integrating with other systems. SPS 2003 provides complete portal functionality and centralizes how users obtain and work with information from various sources. This new approach lets you manage, manipulate, and access information, no matter where the information resides.

The sources and locations of the information SPS can access vary widely, depending on your technical and business objectives. However, most of the document- and knowledge-management information is stored and managed within SPS, so it's essential to ensure that the data and content stored in the SPS databases are available, well maintained, and secure. This article will explain how to provide adequate storage capacity for SPS and care for the data it holds.

You can alleviate many issues in the long run and ensure overall proper sizing and design by beginning SPS design with thorough storage-capacity planning. Capacity planning is the process of determining and understanding technical requirements, such as resource capabilities, and matching them with business requirements. Mapping business objectives to technical requirements in the context of SPS storage can be one of the most challenging aspects of building an SPS document- or knowledge-management solution.

Capacity planning begins with obtaining initial data-size estimates and understanding possible constraints that affect the solution. For instance, an organization might store information in a number of locations, such as an intranet, Exchange public folders, e-mail attachments, local files on the desktop, shared folders on the network, and so on. In many organizations these locations tend to involve a substantial amount of overlap and multiple file versions. It's important not only to identify all the locations but also to determine how much duplication might exist among them. This process can be daunting and take a considerable amount of time, but it's well worth the effort. Constraints come in many forms, the most common of which are budget considerations for hardware and limited available local storage or storage area network (SAN) capacity.

Special considerations that stem from SPS's design compound these more-general storage-capacity considerations. SPS uses either MSDE 2000 or SQL Server 2000 to store content and information. Only small organizations or small SPS projects should use MSDE 2000 because of its storage-capacity and connection-throttling limitations. Although a system can have up to 16 MSDE 2000 databases on a single server, each database is limited to 2 GB of storage, and only five concurrent users can connect to the database. MSDE 2000 doesn't compare to SQL Server 2000 in terms of reliability, available database utilities, security, and other features. You must use SQL Server 2000 with multiple servers that constitute an SPS portal farm. I'll use the term "database" throughout this article to refer to a SQL Server 2000 database.