Microsoft Office Tutorials and References
In Depth Information
content databases, which holds all SharePoint’s precious content—are stored on a different SQL
server, planning for storage is still important.
Consider that the maximum default size allowed for document uploads is 50 MB. A large
multimedia Word document can often about 5 MB, so a maximum of 50 MB is usually more
than sufficient. Of course, you can adjust the size; this is just a good default. And of course, if
you upload more than just Word files, you may need to change that limit.
It goes without saying that storage needs will depend on how your users will use the lists
and libraries on your SharePoint sites. For example, assume they are creating marketing
materials to send out every quarter, and they are storing and collaborating on the materials in a
document library. If they create five major documents each quarter, that would be 20 large documents
per year, possibly up to 10 MB per document. That could be 200 MB of space for those
documents alone. If other people manage the images for the document in a picture library and the
material had 10 large, full-color pictures per document, that could be 2,000MB (2 GB) per year
for that picture library in addition to its related document library. You could need gigs and gigs
of hard drive space—and that doesn’t include versioning.
If you have versioning enabled in your document libraries, there will be multiple copies (as
many copies as you allow when you set up versioning) of each document. Therefore, if
versioning (say four major versions and three minor versions per document) were enabled in the
previous scenario, then at least 1.4 GB per year would be needed for versioning in the marketing
document library alone. Keep in mind that versioning can be allowed for most lists as well.
Most list entries, when stored in the content database, are tiny—just a few kilobytes, if that.
However, if you enable attachments for the lists or libraries, those files (by default less than 50
MB) will be saved with those list items, increasing the size of your content database in ways you
may not have intended. And don’t forget about incoming email. If you configure an incoming
email–enabled list or library to save original emails, those emails (including attachments) need
to be stored in the content database too.
You also need to consider that, depending on what you allow, users can easily create their
own document workspace subsites from a document if they need additional team work to
collaborate. When a document workspace is spun off of a document, it takes a copy of the original
document with it. An additional site will need to be stored in the content database, and a copy of
that document with its own versions will be stored on that site. That document will very likely
be returned to the original library, and the workspace will probably be deleted when the project
is done. Until then, however, that document (and its workspace) is yet another thing
requiring storage. You can also allow users to create their own site collections (with Self-Service Site
Creation); this adds yet more storage overhead to the SharePoint content databases.
Finally, remember that the more stuff you have in SharePoint, the more stuff you will have
in the search database. It holds the indexed search data for documents, list entries, and page
content (it does not index attached files); that data is stored on the SharePoint server itself and
merged regularly into the search database. To make sure that it returns only the entries that the
user making the query is allowed to see, Search also records the Access Control List information
for every indexed entry.
Generally, Search is only allowed to store indexed word entries that equal about 40 percent of
the original document’s size, with a maximum of 64 MB of stored words for a single document.
That means if you have 20 documents in a library, the search database can have (maximum) 1.3
GB of entries for that library alone. Of course, if the documents themselves never exceed 50 MB
(which should have less than 64 MB of unique words to store) and Search sticks to its 40 percent
Search JabSto ::




Custom Search