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

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

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

(0) после 200 Гбайт

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

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

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

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

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

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

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

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

фигасе...

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

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

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

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

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

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

(12) >> справочник основной  1 лям элементов

И что?
Это не объясняет прироста.
Или размер справочника так увеличивается - по ляму в месяц?

Растут явно регистры и документы...

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

P.S. Это при нормальной архитектуре решения

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

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

(21) Гони приз. :-)

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

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

(24) Гм, а если не клиенты, то что за цифра 1000000?

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

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

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

в остальном пока дисков хватит - будет работать

(26) Я бы посоветовал сделать распределенку

1 год (или квартал) - дочка

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

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

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

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

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

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

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

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

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

гы... решение в 1 000 000 $ перекрыли 5 документиками в 1С? чота я не верю...

вполне можно было в таком случае навалять базу тупо сразу на mssql и клиент хоть на дельфях... какой в ж.пу миллион?

(35) +100

(33) + 1000

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

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

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

Еще плюсы - можно на СУБД возложить формирование тяжелых запросов, статистики, использовать хранимки и триггеры

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

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

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

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

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

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

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

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