Какой вы встречали максимальный размер файла (.mdf) стабильно работающей базы на 8.1
в серверном варианте (под MS SQL).

У меня например 10ГБ и мне кажется что уже великовата.
Но вроде пока еще работает.

Стоит ли делать уже обрезание или пока потерпит?

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

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

(0) ты видать совсем начинающий :)

тут кто-то терабайтом хвастался

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

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

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

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

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

заодно загляни сюда v8: Реорганизация и перестроение индексов ms sql 2008r2

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

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

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

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

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

(0) 350 Гб была. Голосовалка хреновая. Надо было

до 100 гб
до 500 гб
выше 500 гб

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

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

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

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

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

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

(16) предлагать!
(19) не поможет.

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

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

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

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

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

от 500

есть 600 гб

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

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

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

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

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

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

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

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

Как ограничить рост журнала транзакций на скуле?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

120ГБ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На тормоза, кстати, никто не жаловался.

И проголосую

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

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

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

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