Каков максимальный размер базы SQL 1C? #592912

Какой вы встречали максимальный размер файла (.mdf) стабильно работающей базы на 8.1 в серверном варианте (под MS SQL). У меня например 10ГБ и мне кажется что уже великовата. Но вроде пока еще работает. Стоит ли делать уже обрезание или пока потерпит?

ну за сотыгу тут у кого то была вроде

стабильность работы не зависит от размера файла

ты видать совсем начинающий :) тут кто-то терабайтом хвастался

Не только в размере базы дело ...

а лог файл уже 60ГБ

18 гигов, считаю маленькой

а резать не пробовали?

ну так шринкование делай

заодно загляни сюда

на днях слышал про 80-100 гиг

[а лог файл уже 60ГБ] не удивил есть настолько тупые админы, что пока место не кончиться на дисках - жо.пу не поднимут

Он после этого всего на пару гигов меньше становится

Какие-то смешные цифры называются.

Еще на семерке больше 100 гиг видел

350 Гб была. Голосовалка хреновая. Надо было до 100 гб до 500 гб выше 500 гб

+100500 А почитать документацию не предлагать?

админ - саботажник, это бывает

встречал такое. База имела размер 120 гигов...  Это являлось следствием работы пионэров с базой - все прелести типа незакрывающихся регистров помноженные на 70 пользователей...

обрезание кстати себе можешь попробовать сделать. лол.

У нас главная 70 Гб база.... правда если ее шринкнуть будет примерно 55 Гб

о да, пускай себе голову обрежет нафик...

предлагать! не поможет.

У нас уже 140. Полет нормальный.

Предлагаю :)))

Более 500 была у кого нить?

штатно 14 терабайт

Детский размер

от 500

есть 600 гб

на прошлой работе бла около 400 гиг

Больше 500 чего? Гиг - видел. Но тема данных не раскрыта

ветка превратилась в мерялку размером пипи... то есть базы

она для этого и создавалась

раньше мерялись select count(*) from _1SJOURN

Есть такая штука как режим восстановления, в котором работает база: simple или full. У вас full - а он вам совсем-совсем не нужен, т.к. за базой всё равно никто не следит. Ставь simple и шринкай лог (потом, так и быть, разрешаю вернуть full).

56 гигов. Центральная. Правда с картинками.

А причем тут админы? Если так скуль с 1С работает, через попу

Типовая БП КОрп (центральная где все бухбазы сидят) вплотную приближаемся к 50 гигам

Самописка управленческая уже перешагнула этот рубеж и ползет к 100 гигам

до 100 гигов - это вообще детский сад

Если отключить сжатие данных, которое 2008R2 умеет делать, то у нас пожалуй за террабайт вылезет. Картинок в базе нет  :)

на прошлой работе самописка на основе какого-то древнего УТП с управленческими примочками и кучей перифериек, центральная база более 700Гб.

При том, что в некоторых конторах администрированием скуля занимаются именно админы.

где вариант 22 см?

И какая связь между логами и админами?

Для 1С ограничения лога - это зло

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

+ У меня на текущей работе у программистов 1С даже доступа к скулю нет. Всем рулят админы (даже созданием баз 1С) - и это, ИМХО, правильно.

А зачем его резать? Чтобы данные фрагмениторовались? Ну лежит этот кусок на 40-50 гиг, ну и пусть лежит

Зато гарантированно это один не фрагментированный кусаок

Хотел бы я позыреть как он вертит этой ерундой в 1Тб ..

Даже неохота на такой глупый вопрос отвечать :)))

была 830 ГБ, Астор:Торговая сеть 6.0

это без логов, только дата-файлы, ессно считаем

при правильном подходе можно нормально вертеть и большими "ерундами"

Ну оно и понятно, аргументов то нет, пора на личности переходить

120ГБ

Дурацкие варианты голосовалки. Сейчас больше 2Тб точно. Может даже более чем в 2 раза, давно не интересовался.

что за база такая? Не журнал транзакция такой :) ?? :)

Я на личности пока не переходил, а вот когда у тебя лог за день вырастет гигов на 100 и место на диске кончится, сразу поймёшь, зачем его обрезать :))

так у вас же там картинки одни - не считается. Бухия1.6 почти 80. переходим на 2.0, всё равно резать же...

У нас такая не одна. ;) И это именно размер базы.

Непонятно, чем же необрезанный лог гарантирует его нефрагментированность. Или ты под лог сразу тупо 50 гигов выделяешь и всё?

А с чего это он будет расти при простом методе? Ну вырастит до 100 и все. Внутри то он сдуется когда закончит работу. А так 100 , значит 100. Если он вырос значит так и нужно и надо думать об увеличении диска а не боржоми пить. А порезать .. это так временная мера, чтобы время было сходить за винтом

Нет он просто вырос и все. Сделал дефрагментацию и он целым куском. А если после каждого чиха бежать и делать обрезание ...

простой метод это имеется ввиду Recovery mode Simple? Нас это не устраивает. У нас все базы на Full живут.

ясно, прикольно. А какая стратегия резервного копирования? Если можно, в двух словах опиши..., просто интересно...

"чтобы время было сходить за винтом". Ну-ну. посчитай сколько будет стоить увеличение размера дискового пространства хотя бы на 100 гигов на 10-м рэйде, например. Это надо все винты в корзине менять. А старые выкидывать?

А том и речь, что не бывает универсального метода. В каждом конкретном случае нужно смотреть, что лучше и проще

С этим полностью согласен, но в больших конторах, как правило, есть чёткое разделение обязанностей: программеры программят, админы - админят. Это я и имел ввиду, когда ты спросил "при чём здесь админы".

Например, средствами скуля 2008 с компрессией

4 базы на одном серваке, до 100 гиг

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

80 с копейками 8.2 год снебольшим работы

Видел 77 скуель 100гб.

у нас 400. полет нормальный.

есть файловая, около 6 гиг

На моей прошлой работе с которой ушел 2 года назад база УПП была 170ГБ. И росла со скоростью 1ГБ в неделю. Так что сейчас наверно она ну очень большая :) На тормоза, кстати, никто не жаловался.

И проголосую

две около 80Гб, центральная 97

+100500 Как влияет на производительность пользователей?

300ГБ (самописная торговля) со скрипом. Но в итоге отчеты для продажников стали делать в отдельной олап системе.

Ваще не в курсе. У нас для этого целый IT-департамент имеется :)