Интересно кто с какими максимальными объемами баз работал и каково это было.

Интересует от 100 Гб.

Очередной замер писек. Зачем тебе это?

Сто тыщ террабайт. Куда приходить за призом?

(0) /me затягиваясь и пуская вверх дым: "Это было великолепно!".

Чего ты о 1С хочешь?
Тут вопрос наличия грамотного админа по SQL, плюс хорошего знания механизмов блокировок, запросов и т.д.

300 гиг было на прошлой работе, 300 юзеров

(0) Чистый объём -не показатель (загрузить 100 тыщ раз в базу "войну и мир" - делов-то!).... реорганизацию давно делали?

На одной, принятой на обслуживании, фирмочке сама база скулевая была 6Г, а лог 170Г - такое пойдет? :))) УТ 10.1 на 2000Скуле, установленном "по 1С-книжке"

(6) ха-ха-ха... не пытались пересоздать дт-шником базу???

Скулем разобрался

(6) Лог скуля или 1С, который в тексте?

Лог Скуля

109 КБ

(0) 350 гигов было. но это она распухла на время. обычный рабочий объем в районе 160 гигов.

100 гиг по меркам скуля не очень большая база.

(6) ну это от беспризорности.

(13) +1000

(13) Там еще не такие чудеса были.. :))

(0) А что смущает? Напихай картинок, а для рабочей 100 гб, не очень большая.

как правило реальные данные процентов 40-50 занимают. остальное индексы. у кого 2008 врубайте сжатие. потом раскажите ))

(6) охренеть. и как сиё работало?

(18) Работало. У нас была такая же ситуация. Сама база порядка 10 гектар, лог транзакций - около 230. УТ 10.3 на SQL 2000

(18) а в чем проблема? старый лог транзакций на производительность не влияет. просто лежал мертвым грузом на харде и все.

(12) смотря скока оперативки.

(0) щас у нас вроде (я тут 3 недели только еще, толком не знаю пока чо к чему) 1.5 или 2 аж терабайта центральная база. Усеров 500+
не быстро, но и не сильно медленно, да и это не из за платформы, а из за кривой архитектуры и быдлокода инсайд. И я видел базы на 30Гб и 100 пользюков, которые работали в пару десятков раз медленнее.

С какой целью интересуешься-то? С фалометрической или какие конкретные вопросы есть?

8 терабайт.

600 TB. Я работал только с конфой. Про особенности БД ничего сказать не могу.

(24) сколько хардов ?

(23) (24) Вы про 1С говорите ???

GROOVY 600 Gb или же TB ??

(26) полюбому Гб.

(0) -40 гб мдф
(24) -мастер ки облажался

нет, чтоб самой большой грудью меряться..

(29) [Смотрит фотку. Сдается]

(29) Что мешает? Начинайте! :)

Объем БД не влияет напрямую на производительность. Я даже сказал бы категоричнее - он вообще на нее не влияет при условии правильной архитектуры.

150гб. упп. и?
тема беседы то какая?

(32) к сожалению не все это знают. не давно приходилось отстаивать что 20 млн записей в таблице это не слишком много. нужных записей. человек был против такого объема записей в базе. типа это слишком много. причем это записи за 3 года.

(6) средствами скуля сжатие делать надо и в свойствах модель не фул а смалл.

(34)20 млн это серьезное количество, которое при неправильном подходе может привезти к тормозам. Но если человек  разбирается в том как работает SQL (в частности использование индексов), то проблем нет.

(34)Поэтому в твоем споре наверно нужно было показать что ты разбираешься, что все под контролем... :)

(36) ха... УПП, расчет с/с (распределение общепроизводственных и общехозяйственных расходов) за 1 месяц - 3,5 записей в регистр бухгалтерии.
каждый месяц увеличивал базу на 70 гиг

(38) * 3.5 млн

300 гиг на ДБ2 экспресс (это пц :) )

20 гиг файловая (потом пришлось обрезать самую большую таблицу - серийные номера (отслеживание движения оборудования))

еще есть 120 гиг скулевая.

реструктуризация самой большой таблицы в файловом варианте только через выгрузку 70-90% в файл (с обрезанием), реструктуризация, затем загрузка обратно. ибо она замедляется со временем :(

Есть УПП 370 гб, база работает 5 лет, около 100 польз. ТИИ проходит ровно сейчас крутится на sql2008

(44) ТИИ в 1С проходит?
И сколько времени это длится?

вы sql.ru почитайте. вот там у людей объемы. по нескольку млн записей в день в таблицы грузят.

у нас скромные 140 гигов.

(0) Дома фильмы на раздачу храню в самописной базе 1С 8.2, больше полутора терабайт. Работает отлично.

(46) Мы готовимся то же самое с 1С делать.

(0) как мерил?

(32) Неправда. Конечно на мелких объёмах данных размер при правильной архитектуре не сильно влияет. Но для баз 100-500-1000 ТБ, считая размер занятый данными, а не тупо размер файлов, уже можно наткнуться на ограничения производительности.

Примеры проблем производительности на больших БД:
1. Статистика хранится только для 200 значений. Т.е. на больших таблицах MS SQL будет криво сравнивать селективность индексов (Поле1, Поле2, Поле3) и (Поле1, Поле3, Поле2)
2. На запросах, которые приводят к table spool в плане может сильно возрастать нагрузка на tempdb.
3. Запрос для среза последних (особенно нефильтрованного) при относительно небольшом наборе уникальных вариантов (10к-100к) измерений и большом количестве записей внутри изменений имеет тенденцию к плохим планам запросов.
4. На больших таблицах MS SQL откровенно слабо генерит планы для бух. регистров с субконтами.

На более крупных БД, начаная с такого характерного объёма как "максимальный размер обычного жёсткого диска", т.е. сейчас это 2-3 ТБ, есть также много проблем обслуживания, начиная с бэкапов, которые длятся уже неприлично долго и занимают неприлично много (если не юзать сжатие из 2008), также проблемы с обслуживанием индексов, с checkpoint при перезапуске сервера (может быть дольше, чем время жизни на UPS).

120 ГБ было на 7.7..как пришел тока на эту фирму...перевел на 8.2 ...сервак немощный был...еле тянул...

(51) для оптимизации больших бекапов у скуля есть все необходимые инструменты.

(53) Ну, во-первых, немалая часть из них появились только в 2008/2008R2 по сути (сжатие рез. копии, зеркальные и чередующиеся резервные копии и некоторые другие). Во-вторых есть еще много чего, что бы было неплохо сделать: резервные копии баз в состоянии standby или аналогичных, резервное копирование с перестройкой обычных индексов (а не только в full text), шифрование резервных копий, не такое тормозное создание разностных резкопий... В общем, необходимое, конечно, есть (особенно если сравнить с SQL Server 7.0), но его недостаточно для удобной работы.

(54) шифрование резервных копий есть если я не ошибаюсь. только не давно читал про это.

(55) Пруф на BOL есть? Именно на штатное шифрование и именно резервных копий (не прозрачное шифрование данных, у которого, впрочем, есть свои ограничения).

(54)
>> немалая часть из них появились только в 2008/2008R2 по сути (сжатие рез. копии, зеркальные и чередующиеся резервные копии и некоторые другие
собственно, из перечисленного, только сжатие резервных копий и появилось в 2008-м. Хотя, возможно, я не понял что такое чередущиеся резервные копии.

>>не такое тормозное создание разностных резкопий
это вы про диф. копии? А почему оно тормозное? ИМХО, весьма шустро работает.

>> резервное копирование с перестройкой обычных индексов
о да, боюсь даже представить сколько это будет занимать..

>>резервные копии баз в состоянии standby
ммммм.. а зачем? вы ж базу в стандбае изменять не можете - это как бы "не до конца восстановленная" БД. Не удаляйте копии из которых делали базу в стандбае и все..

(56) что то не могу в BOL найти. Вечером в книге гляну. Я эту главу по диагонали пока прочитал. Но помню что то там было про резервные копии, безопасность и сертификаты.

(58) Нету вроде шифрования. может перепутал с BACKUP CERTIFICATE (http://msdn.microsoft.com/ru-ru/library/ms178578.aspx)

(22) А что за конфа? Какое железо, как организовано создание бэкапов?

(22) Цель общепознавательная.

(59) BACKUP CERTIFICATE это совсем не то.

(17) Я включил писал уже что база сжалась раза в 4 :)

(63) то что жмет хорошо, это понятно. производительность как?

400 Гб из них где-то 150 Гб вложенные файлы
~270 активных пользователей

(60) Самописка. ХЗ. ХЗ. :)

(64) Замеров не делал, но по субъективным ощущениям возросла ~30%, видимо за счет уменьшения дисковых операций, так же бэкапы стали быстрее делаться.

(57)
1. Действительно, зеркальные резервные копии появились еще в 2005, но в Enterprise редакции (см. BACKUP .... MIRROR TO ...), и чередующиеся тоже не новинка.
2. Разностные резервные копии делаются достаточно медленно (в мегабайтах в секунду если считать), скорее всего это связано с тем, что полные резервные копии используют блок для IO 1 МБ и активно используют предчтение, а разностные резервные копии 64 кБ (экстент).
3. Зато место на носителе бэкапов можно было бы сэкономить.
4. База в состоянии stand by может быть в результате постоянной докачки доставкой журналов (log shipping). Её "исходные" резервные копии могут быть и за несколько месяцев.

просто интересно почитать. вот где базы то реальные

http://www.microsoft.com/industry/publicsector/partnersolutionmarketplace/global/CaseStudyDetail.aspx?casestudyid=4000006654

на прошлой работе в самописке было 700Гб.
(48) "Дома фильмы на раздачу храню в самописной базе 1С 8.2, больше полутора терабайт."
а зачем нужна база фильмов? неужели каталогизатор типа movienizer не спасает?

(68) 1. Ну так и сжатие бэкапов изначально (в 2008-м) было только в EE. Где-то читал, что в R2 добавлено в Standard только для того, чтобы перетянуть пользователей на "неполноценный" (без собственного номера, включающий в себя не так много отличий от 2008-го) релиз.
2. Про блок для диф бэкапа не знал, спасибо. А вот упреждающее чтение там использовать никак не получится - выдираются ведь только измененные экстенты, по Differential Changed Map. Но в любом случае, у меня время создания диф бэкапа пропорционально времени создания полного бэкапа. Т.е. полный делается за 15 минут, дифференциальный за 1,5-2 - размеры бэкапов так же пропорциональны.
3. Мне кажется это весьма сомнительным плюсом. Место на диске относительно дешево, а вот "окно обслуживания" в этом случае придется увеличивать. Если сейчас я делаю бэкап во время работы пользователей, то в случае с одновременной перестройкой индексов, придется использовать только время когда пользователи не работают. Тем более, если перестраиваться будут все индексы. У нас это займет порядка 4-5 часов - совершенно неприемлимо.
4. Дак вы же бэкапы "основной" базы делаете. Берете последний полный бэкап, последний диф с нее же и добиваете оставшимися бэкапами логов, которые делались лог-шиппингом. Не вижу проблемы, если честно.

(51) Для 1С это фантастика:)Я предпологал объем максимум в 10 ТБ. При хорошей нормализации данных я вообще не представляю чем можно такой объем заполнить. Хотя знаю что есть более 1000 ТБ базы на MSSQL - разумеется они аналитические. На моей практике в основной массе большие базы на 1С порядка 200 ГБ. (Знаю что есть парочка с объемом приблизительно 2 ТБ.) Для таких БД проблемы производительности не связанны с объемом, могу это утверждать на основании статистики.