Еще один вопрос от вчерашнего общения с гуру SharePoint во время обучения MCM. В рекомендациях SharePoint указано, что базы данных контента размером более 100 ГБ не поддерживаются. Не вдаваясь в причины, лежащие в основе этих рекомендаций, мне интересно услышать о базах данных контентабольшеболее 100 ГБ и ваш опыт работы с ними (в первую очередь в плане производительности, аварийного восстановления и предоставления высокой доступности).
Насколько далеко вам удалось продвинуть установку SharePoint? Я слышал истории из вторых рук о базах данных контента > 1 ТБ, но я хотел бы услышать мнение самих администраторов SharePoint.
Спасибо за любую имеющуюся у вас информацию.
решение1
У нас есть БД на 111 и 102 ГБ соответственно, которые копируются менее чем за 30 минут в сети GigE. Я слышал, что у больших баз данных могут быть проблемы с долго выполняющимися хранимыми процедурами, но не видел никаких демонстраций этого.
Хорошая цитата из технического документа «Масштабирование SharePoint 2007: Архитектура хранения»:
«...Это обычно называют «ограничением размера базы данных контента в 100 ГБ». На самом деле, это не настоящее ограничение, а скорее рекомендация. Базы данных SQL Server уже много лет масштабируются намного дальше 100 ГБ. На практике эта рекомендация основана в первую очередь на двух важных факторах:
Требования соглашения об уровне обслуживания (SLA) для определенной организации могут диктовать, что операции резервного копирования для баз данных SharePoint должны быть выполнены в течение ограниченного периода времени. Размер баз данных контента будет иметь прямое влияние на то, сколько времени потребуется для выполнения этого резервного копирования.
Подсистема хранения данных должна быть достаточно надежной, чтобы справляться с требованиями дискового ввода-вывода решения SharePoint, которое она обслуживает.
Пока данная организация способна смягчить эти два фактора, можно позволить базам данных контента расти. Реальные внедрения SharePoint показали успешные развертывания, в которых были реализованы базы данных размером 100 ГБ, 150 ГБ, 200 ГБ, 250 ГБ, 300 ГБ, 350 ГБ и 400 ГБ».
решение2
Для повседневного использования размер базы данных не так важен — большинство запросов возвращают элементы в одном списке, и неважно, что еще находится в базе данных. Однако операции, которые работают со всей базой данных, станут сложнее. Резервное копирование — наиболее очевидный пример — оно займет больше времени с большими базами данных. Однако, пока база данных не превышает того, что можно скопировать за ночь, все будет в порядке — резервное копирование рассчитано на длительный срок и довольно надежно, пока у вас не закончится место на диске.
Реальные проблемы могут возникнуть при менее частых действиях, таких как перемещение или обновление баз данных контента. Для них может потребоваться примерно в 5 раз больше свободного места, чем размер базы данных, и они реализуются с помощью запросов, которые могут, например, вызывать неконтролируемый автоматический рост.
решение3
У нас есть база данных контента размером 300 ГБ. Никаких проблем с резервным копированием после перехода на Lite Speed. До перехода мы наблюдали серьезное снижение производительности веб-сайтов.
Для протокола мы НЕ хотели иметь такую большую базу данных контента. У нас были особые бизнес-требования к обмену контентом, которые было бы очень сложно реализовать, если бы мы поместили контент в отдельные коллекции сайтов.
Когда мы впервые запустили проект, у нас были серьезные проблемы с блокировкой базы данных во время пиковой нагрузки. Мы связали это с использованием объекта CrossListQueryCache в SharePoint. Мы отказались от использования этого API, и это исправило большую часть нашей производительности.
Я написал небольшую статью в блоге с более подробной информацией.здесь.
Мы по-прежнему сталкиваемся с проблемами блокировки при определенных типах обновлений (удаление больших двоичных объектов размером более 20 МБ), переименовании веб-сайтов (это может привести к обновлению большого количества записей в таблице AllUserData). Мы работаем со службой поддержки Microsoft по конкретным случаям (например, удаление больших элементов из корзины). Они связаны со способом удаления данных определенными хранимыми процедурами в SharePoint, но у нас пока нет решения.
Лично я считаю, что проблемы возникают, когда в таблице AllUserData появляется слишком много записей, и для MS самым простым способом донести это до людей было сказать: не превышайте объем в 100 ГБ.
Предлагаю обратиться к сотрудникам MS IT... Я слышал неофициально, что у них есть база данных контента SharePoint размером > 800 ГБ.
решение4
Это ложь. Ограничений по размеру нет. Они рекомендуют не иметь больших баз данных, а только для того, чтобы упростить управление базами данных и минимизировать время резервного копирования/восстановления. Можно сказать, что ограничение по размеру зависит только от вашей инфраструктуры SQL.