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