Если вы не используете квоты, вы подвергаете свое хранилище SQL Server риску, поскольку пользователи могут загружать огромное количество данных на My Site или Team Site. Сейчас это сделать легче, чем когда-либо, так как есть SkyDrive.
Если пользователь синхронизирует SkyDrive Pro (библиотеку документов My Site) с локальным компьютером и случайно загружает в него коллекцию iTunes, я надеюсь, ваше хранилище SQL Server готово к работе в полную силу.
Необходимо использовать квоты, причем на каждой коллекции сайтов! Пусть квота будет большой (скажем, 200 или 500 Гбайт), но она должна быть, и будет защищать ваше хранилище от случайных повреждений.
Облегчите перенос базы SQL Server с помощью псевдонимов
Псевдонимы весьма важны. В SQL Server они представляют собой вымышленные имена для сервера базы данных. Псевдонимы определяются в клиенте SQL Native Client, который запускается на всех серверах SharePoint (cliconfg.exe). Откройте CliConfg и задайте псевдоним для соединения TCP/IP. Повторите и определите псевдонимы на каждом сервере SharePoint. Затем используйте эти псевдонимы во всех настройках SharePoint, когда указываете сервер базы данных. Следует иметь отдельные псевдонимы для того, чтобы обращаться к отказоустойчивому серверу, если вы используете зеркалирование для устранения отказов.
Когда приходит время перемещать базы данных на другой SQL Server или использовать кластеры либо другую технологию, которая эффективно изменяет имя сервера, это будет сделать очень просто. Определите заново псевдонимы на каждом сервере SharePoint, чтобы указать новое имя сервера. Одно действие для одного сервера.
Это намного проще, чем копаться в параметрах настройки SharePoint и менять имя сервера на всех веб-приложениях и служебных приложениях.
Управляйте изменением размеров базы данных
Многие администраторы SharePoint не фокусируют внимание на первоначальном размере и автоматическом увеличении размера контента баз данных. Эти настройки важны с точки зрения SharePoint: стандартные подходят для «нормальных» приложений SQL, но не для тяжеловесного контента, как в SharePoint.
Ваша база данных в «первоначальном виде» должна отражать разумное понимание того, как много места для хранения контента в базе данных вам потребуется в ближайшем будущем. Помните, что контент базы данных может содержать более одной коллекции сайтов, поэтому посчитайте их все.
«Автоматическое увеличение размера» используется, когда база данных сталкивается с превышением начального размера и вынуждена расширяться. Вам понадобится задать параметры автоматического увеличения размера так, чтобы когда база данных начнет расти, она не должна делать это «по своему разумению». Следует понимать, что корректное увеличение основывается на использовании вами хранилища. Я предлагаю применять фиксированный размер приращения (а не увеличение размера в процентном соотношении), который исчисляется как процент от первоначального размера.
Итак, возьмем сценарий совместной работы (сайт группы). Предположим, вы ожидаете от своей базы данных размера 50 Гбайт в этом году, но она может вырасти до 100 Гбайт. Цифры могут быть другими, но вы можете установить первоначальный размер в 50 Гбайт и задать увеличение размера на 10 Гбайт (20% от первоначального размера).
Когда размер и процент увеличения размера баз данных SharePoint задаются по умолчанию, производительность SQL может быть заметно снижена. Другими словами, сервер слишком занят только увеличением размера базы данных посредством небольших приращений (1 Мбайт увеличения размера по умолчанию), поэтому не может делать что-то еще. Кроме того, сами по себе базы данных фрагментируются в файловой системе, что тоже снижает производительность.
Дополнительную информацию о каждой из настроек, о которых я рассказал выше, вы можете найти в материалах «Best Practices for SQL Server in a SharePoint Server Farm» (http://technet.microsoft.com/en-us/library/hh292622.aspx) и "Considerations for the 'autogrow' and 'autoshrink' settings in SQL Server(http://support.microsoft.com/kb/315512).