База 1С  была поднята через cf файл,  пользователи работали  до того момента, как начали обновлять (добавлять) адресный классификатор, после чего лог стал расти (более 8 гб) С другими базами, которые были созданы в то же время, но через шаблон конфигурации, работают без проблем, лог не растет.

Ну и пусть растёт, мешет, что-ли?

(0) так в симпле базы или в фуле ?

А так - наймите админа, который по-нормальному настроит вам осблуживание скуля.

ограничения  стоит 8 гб, если > ругается, приходится увеличивать размер лога.

(2) симпл

А вот за ограничение размера лога я лично бы увольнял с волчьим билетом...

(6) наверное у Вас не разрастался лог в более 20 гб ? не надо вот сейчас!

(7) 20 гб? Я с такими детскими размерами не работаю :-)
У меня сейчас 2 рабочие базы - одна 700Г, другая 1200ГБ...

(8) вот что значит выложил пипиську на стол - так выложил! )))

(6)
если не ограничивать , можно завалить сервак скл и виндовс.

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

запросом в 10 строк. после этого будет вопрос кого увольнять.

(10) согласен с (6), поскольку правильно ограничивать память на запрос, а не размер лога

(9) Дык давно уже ведь всё выкладывали :-)

(10) ИМХО Для больших баз и активной работе большого количества пользователей ограничение лога неприемлимо.

(10)винда на одном диске лог на другом
не вижу проблемы

(11)>>поскольку правильно ограничивать память на запрос
и как ограничишь память под запрос?

(14) и привет работе базы, когда диск кончится.
(8)>>У меня сейчас 2 рабочие базы - одна 700Г, другая 1200ГБ...
это не 1С.

(16) "это не 1С."
А базы-то и не знают... Во дожили...

(17) главное, что 1с не знает... а базы дело десятое )

... если 1с не знает - базам пофиг, какие они.

(18) (19) Я так и не смог всю глубину твоей мысли...

(16) почему не 1с?
У меня за 1 год после замены сервака база выросла с 30Гб до 100Гб и это без логов, я логам не даю разрастись более 50ГБ

(20) 1с не может работать с большими объемами. Так что тут корреляция с пониманием и с 1С ))

(22) "1с не может работать с большими объемами"
Кто тебе такую чушь сказал?

(21)>>У меня за 1 год после замены сервака база выросла с 30Гб до 100Гб
у меня только логи по 120 ГБ, и что прикажете делать - каждый год докупать СХД?

(22) И можно увидеть пруф на сие утверждение?

(23) присоединяюсь к вопросу

(23)1С своей работой. Точнее, не-работой с такими объемами.

(24) А зачем тебе такие логи и почему ты их не обслуживаешь?

(24) шринк

(27) Если у тебя кривые руки, это не значит, что 1с не может с такими объёмами работать

(25) ага, так на селезневской и признались, что за овер 20 лет так и не смастерили ничего на уровне работы БД предприятия.

(30) угусь, пряморукий.

(27) Может это просто ты не умеешь её готовить?

(30) расскажи про 1с еще историй ))

(24) Что вы в этих логах храните?

(33) если интересно - все "умельцы" по готовке рано или поздно засоряют сначала мисту, а потом SQL.ru вечными вопросами "что делать!??"

Как в симпле может расти лог???
Я использовал обработку, которая анализирует размер базы. Оказалось самая огромная - таблица регистрации изменений ИБ (для обмена). Ну и еще пара регистров самописных.

(35) я что храню?! я - абсолютно ничего. А SQL - все транзакции, что у него проходят.

(16)и что делать?
чем это ваше ограничение лога отличается от такой ситуации?

(37)>>Как в симпле может расти лог???
это про какой лог?

(37) А чего бы ему не расти даже в симпле?

(38) В логе SQL хранит не транзакции, и не все. Учите матчасть.

(39) тем, что вовремя сделаный транкэйт (в ранних SQL, сейчас сложнее) спасает мир.
И чаще делать полные бэкапы, и база чтоб в Simple была.
А 1С уж постарается "замусорить" все, до чего дотянется, вплоть до зависших сессий, из-за которых даже лог не обрежешь вручную.

(42) ага. понятно.

(43)полная модель нужна не для того чтобы лог выращивать )))

(5) раз симпл и растёт, значит надо искать отличие в бизнес-процессах

сами собой длинные транзакции не родятся,
возможно включены лишние регламентированные задания ?

(45) никогда не понимал со дня появления 1С, зачем народ делает для неё full.

(15) настройками скуля, емнип, я не админ

(47) значит ты ни разу не видел квадратных глаз ГБ, чисто случайно укокошевшей пол-часа назад сотню поступлений

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

(38) Лог растет при модели full, когда долго не делаются полные бэкапы - у вас их запрещают делать?

(47)можешь не делать.
(50)они думают что достаточно режим поставить )))

(51)

при реструктуризации размер бд варастал на 8.1 и мс скл 2005

в 2 раза.

при перезаписи "больших" таблиц типа кладра может вывасти темпдб

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

(51) Уточнение - не полные бэкапы, а бэкапы лога. Полный бэкап на лог никак не влияет.

(53) Это я специально не стал писать, т.к. "вырастает и стабилизируется" :)

(54) Ну да, давно настраивал, забыл.

(48) понятно.
тогда зачем написал "поскольку правильно ограничивать память на ЗАПРОС", если в глаза не видел ни галочки, ни параметров таких? ))

(49)>>значит ты ни разу не видел квадратных глаз ГБ, чисто случайно укокошевшей пол-часа назад сотню поступлений
а ты ни разу не видел разностный бэкап?

(57)галочку видели праотцы )))

(59) ну да, ведь никто не знает, что там было на самом деле...
(51)лог растет, когда 1С делает миллион ненужных операций, а в результате - всего-то надо было 10... А SQL все пишет и пишет...
(54)вот для этого и ставите full - чтобы делать бэкапы логов... А восстановление на "момент времени" - для 1С ни о чем: у неё свое понимание "транзщакций", которые к SQL-транзакциям не относятся никак, а SQL восстанавливает транзакции как раз в своем понимании. И никто никогда не угадает, где закончилась 1С транзакция, чтобы её восстановить.
Это и к (49).

(60)ну хватит уже не смешно...

(5) Наверное симпл после поставили, когда лог стал расти, и не могли его обрезать!? А база в фуле осталась... Пересоздай базу - создаешь новую, пустую, ставишь ее в симпл, и только после этого грузишь в нее выгрузку из dt. Через скульный бэкап с не обрезанным логом в симпл не переведешь.

(61) а мне смешно. Давно уже.
Столько "специалистов" - ууу...
Кстати, был случай, что модель full нормально заработала "с самошринкованием" только после принудительной обрезки.

(61) да, кому еще тоже не смешно - могут вполне поупражняться "раздели транзакции 1С и SQL".
А я повеселюсь )))

сожми лог в скуле

ДенисЧ а можете в каких-то еще показателях рассказать про свои базы в 700 и 1200 гиг ? Кол-во док, строк и т.д. период. Самая большая табличка какая и т.д. ? Ну правда очень интересно.

+(66)
время ТиИ

(66) Лень считать :-)
Но в одной, та, что 700 - максимум это регистр версий.
В другой заказы, остатки и продажи по over 400 подразделений по дням с 2010 года, + дополнительные всякие заморочки
(67) не делаем.

(68)что и требовалось доказать.

(69) Что доказано ? Пиписька коротенька у Дениски ? Или что ?

(64) шо за зверь транзакция 1С?

сдается мне, что    РенеДекарт

был забанен на этом форуме. под другим ником.

(68)>>что 700 - максимум это регистр версий.
и что? размер какой?
(70)>>Что доказано ?
"ТИИ не делаем"
(71)>>шо за зверь транзакция 1С?
неделимая и непрерывная операция 1С-сервера.