Каков критичный размер базы SQL под 8.2 ? #610854

База 8.2 41 гиг в архиве. Прирастает 3 гига в месяц. Вопрос -когда начинать беспокоиться и думать о резке базы. База самописка.

когда место на диске заканчиваться начнёт

не документооборот, случайно?

после 200 Гбайт

для порнушки 3Гбайт маловато =)

какие таблицы больше всего пухнут погляди, может там урезать инфу можно. Например чудо самописное версионирование если есть - можно и допилить

Зависит от самописки. Стоит начинать беспокоиться, когда начинаются тормоза. Но это не значит, что надо думать о резке базы, может стоит подумать об оптимизации запросов...

Не .ldf пухнет то?

Сама база так прирастает или включая логи транзакций?

Когда время восстановления из backup-а станет неприлично большим.

Пухнет mdf. Там 4 регистра всего и 5 документов, ничего лишнего. Только резать.

>Там 4 регистра всего и 5 документов, ничего лишнего фигасе...

А что ? справочник основной  1 лям элементов

Билинг, видимо.

что-за база-то? не услуги связи, случаем?

одинэсники больше ничего не знают

биллинги на 1Ц строят только идиоты... доказано зануси

Ничего не делать. Почитать сколько разработчик БД декларирует размер.

>> справочник основной  1 лям элементов И что? Это не объясняет прироста. Или размер справочника так увеличивается - по ляму в месяц? Растут явно регистры и документы...

И что? рАзмер то вам как мешает? В 2008 скуле бэкапы со сжатием. Если все работает нормально - хоть несколько террабайт... P.S. Это при нормальной архитектуре решения

Бинго. Контора зажала 1 лям баксов для нормального решения. Я же написал 4 регистра 5 документов. :) Все проще некуда. У меня 2005 SQL.

может пухнут итоги?

Гони приз. :-) Причем тут итоги? 1000000 пользователей = в месяц 2000000 документов.

Пухнут конечно, но не критично. Все закрывается в ноль когда надо, я за этим следил при разработке :) Думаю сделаю количественный тест и посмотрю на каком размере база начнет совсем загибаться. Не, клиентов в 2 раза меньше пока, и у меня по другому закрывается все -с целью делать меньше движений. Может 1 "движение" в год по 1 клиенту, а может и 3-5 в месяц. В зависимости от бабла на ЛС клиента.

Гм, а если не клиенты, то что за цифра 1000000? Кстати, что за паника оно уже медленно работает?

Ну пока теоретически возможных абонентов  :) Работает как и работала год назад. Просто хотелось бы заранее подстраховаться. Краем уха слышал что проблем с базами до 50 гигов нет. после 50 возможны. Вот и решил провентилировать данную тему.

у тебя единственная угроза - размер и время бэкапа, когда полный бэкап идёт дольше 24 часов его нельзя делать каждый день в остальном пока дисков хватит - будет работать

Я бы посоветовал сделать распределенку 1 год (или квартал) - дочка делаем обмен (односторонний) потом в основной базе свертку, при необходимости залезть в свернуытый диапазон распроводим документ свертки и делам обратный обмен

Имхо вы можете столкнуться только с одной проблемой - когда заходите обрезать базу средствами 1с, вы будете целый месяц удалять документы :) Лимиты на размер базы у MSSQL конечно есть но они очень далеки. Насчет сжатия бэкапа: начиная с 2008R2 даже в редакции стандарт доступно сжатие. Оооочень сокращает время бэкапа именно 1с баз, буквально на порядок. Оооочень советую! Еще одна возможная проблема - блокировки. Но у вас вероятно уже все сделано правильно, иначе бы словили бы давно. Ну и на всякий случай поищите неиспользуемые индексы, бывает они жрут чуть ли не больше самих данных, если данные текстовые. В ssms отчет - топ 100 таблиц.

И есть еще нетривиальный способ сокращения базы: вынести архивные данные в другую базу, даже необязательно 1с. Особенно теперь с внешними данными стало вообще удобно работать (я надеюсь, сам не пробовал)

топ 10 тяжелых таблиц из SQL структуру хранения самой тяжелой в студию

В SQL Студио удаляется как нефиг делать. ПОтом ТиИ и проверено - Работает!

Если всего 4 регистра и 5 документов не проще было сделать биллинг на голом SQL+C# ? И летало бы и про размер базы можно было бы не вспоминать

Знаю фирму где основная база 1.5 террабайта уже, и ничего, работают.

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

небось косячок в данных - единичное движение регистра в далекое будущее. никому не мешает, так на хрен никому не нужно, а итоги вздулись дирижаблем

гы... решение в 1 000 000 $ перекрыли 5 документиками в 1С? чота я не верю... вполне можно было в таком случае навалять базу тупо сразу на mssql и клиент хоть на дельфях... какой в ж.пу миллион?

+100 + 1000 любое изменение метаданных регистра - база встает колом хз на сколько времени...

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

если уж так надо было интерфейс на 1С сделать, можно было вообще ее использовать как прослойку - все проведения переписать на прямую работу с SQL базой - "INSERT/UPDATE/SELECT", чтоб в 1С базе вообще ничего не хранилось, только запросы по ODBC пуляло. Еще плюсы - можно на СУБД возложить формирование тяжелых запросов, статистики, использовать хранимки и триггеры

ага, потом у тебя отчеты бы тормозили ужасно..

Думаю, исходя исключительно из удобства обслуживания, здравого смысла и решаемых задач. Если мощности позволяют, то и с терабайтными базами вряд ли будут проблемы (если нет архитектурных ошибок).

летало бы все. тормозит скд.

Легко. Например ЛС абонента в нескольких валютах одновременно и списание бабла за 1 услугу несколькими валютами с пересчетом и приоритезацией - все западные системы сразу говорили -иди лесом. Или допиливание за 30-40% от стоимости продукта. И много еще "местного" калорита, которые западные систему не переваривают вообще. Ну и постоянная смена "курса" компании не благоприятствует покупать "промышленную" систему. Хотя некоторые системы просто конфетки, но увы :(

а как эти 2000000 документов в месяц создаются? у тебя система реального времени что ли, каждая  операция абонента сразу пишется в 1С?

Нет у меня столько документов. Движений больше, документов намного меньше.. Система не реального времени -бизнес этого не требует.

вот-вот если бы в приоритете была бы гибкость то западные системы не сдюжили бы имхо а систему где все минималистично и много запрещено сделать быстреенадежнее естественно проще

Один западный специалист по биллингу был в шоке, когда я нарисовал ему алгоритм списания бабла и алгоритм продления услуг. Сказал что надо подумать сколько займет реализация данного алгоритма в их системе за 500 килобаксов. Уже полгода думает. В россии очень трудно с автоматизацией западными системами, все что хотят то и творят :(