Имя: Пароль:
1C
1С v8
Растет база sql
0 tsaboy
 
17.06.14
15:26
База 1С  была поднята через cf файл,  пользователи работали  до того момента, как начали обновлять (добавлять) адресный классификатор, после чего лог стал расти (более 8 гб) С другими базами, которые были созданы в то же время, но через шаблон конфигурации, работают без проблем, лог не растет.
1 ДенисЧ
 
17.06.14
15:27
Ну и пусть растёт, мешет, что-ли?
2 shuhard
 
17.06.14
15:27
(0) так в симпле базы или в фуле ?
3 ДенисЧ
 
17.06.14
15:27
А так - наймите админа, который по-нормальному настроит вам осблуживание скуля.
4 tsaboy
 
17.06.14
15:28
ограничения  стоит 8 гб, если > ругается, приходится увеличивать размер лога.
5 tsaboy
 
17.06.14
15:29
(2) симпл
6 ДенисЧ
 
17.06.14
15:29
А вот за ограничение размера лога я лично бы увольнял с волчьим билетом...
7 tsaboy
 
17.06.14
15:31
(6) наверное у Вас не разрастался лог в более 20 гб ? не надо вот сейчас!
8 ДенисЧ
 
17.06.14
15:32
(7) 20 гб? Я с такими детскими размерами не работаю :-)
У меня сейчас 2 рабочие базы - одна 700Г, другая 1200ГБ...
9 mikecool
 
17.06.14
15:33
(8) вот что значит выложил пипиську на стол - так выложил! )))
10 МихаилМ
 
17.06.14
15:37
(6)
если не ограничивать , можно завалить сервак скл и виндовс.

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

запросом в 10 строк. после этого будет вопрос кого увольнять.
11 mikecool
 
17.06.14
15:42
(10) согласен с (6), поскольку правильно ограничивать память на запрос, а не размер лога
12 ДенисЧ
 
17.06.14
15:42
(9) Дык давно уже ведь всё выкладывали :-)
13 13_Mult
 
17.06.14
15:48
(10) ИМХО Для больших баз и активной работе большого количества пользователей ограничение лога неприемлимо.
14 mkkd
 
17.06.14
15:51
(10)винда на одном диске лог на другом
не вижу проблемы
15 РенеДекарт
 
17.06.14
15:55
(11)>>поскольку правильно ограничивать память на запрос
и как ограничишь память под запрос?
16 РенеДекарт
 
17.06.14
15:56
(14) и привет работе базы, когда диск кончится.
(8)>>У меня сейчас 2 рабочие базы - одна 700Г, другая 1200ГБ...
это не 1С.
17 ДенисЧ
 
17.06.14
15:57
(16) "это не 1С."
А базы-то и не знают... Во дожили...
18 РенеДекарт
 
17.06.14
15:59
(17) главное, что 1с не знает... а базы дело десятое )
19 РенеДекарт
 
17.06.14
15:59
... если 1с не знает - базам пофиг, какие они.
20 ДенисЧ
 
17.06.14
16:00
(18) (19) Я так и не смог всю глубину твоей мысли...
21 bodri
 
17.06.14
16:00
(16) почему не 1с?
У меня за 1 год после замены сервака база выросла с 30Гб до 100Гб и это без логов, я логам не даю разрастись более 50ГБ
22 РенеДекарт
 
17.06.14
16:01
(20) 1с не может работать с большими объемами. Так что тут корреляция с пониманием и с 1С ))
23 ДенисЧ
 
17.06.14
16:02
(22) "1с не может работать с большими объемами"
Кто тебе такую чушь сказал?
24 РенеДекарт
 
17.06.14
16:02
(21)>>У меня за 1 год после замены сервака база выросла с 30Гб до 100Гб
у меня только логи по 120 ГБ, и что прикажете делать - каждый год докупать СХД?
25 SSSSS_AAAAA
 
17.06.14
16:02
(22) И можно увидеть пруф на сие утверждение?
26 bodri
 
17.06.14
16:02
(23) присоединяюсь к вопросу
27 РенеДекарт
 
17.06.14
16:02
(23)1С своей работой. Точнее, не-работой с такими объемами.
28 ДенисЧ
 
17.06.14
16:03
(24) А зачем тебе такие логи и почему ты их не обслуживаешь?
29 bodri
 
17.06.14
16:03
(24) шринк
30 ДенисЧ
 
17.06.14
16:03
(27) Если у тебя кривые руки, это не значит, что 1с не может с такими объёмами работать
31 РенеДекарт
 
17.06.14
16:04
(25) ага, так на селезневской и признались, что за овер 20 лет так и не смастерили ничего на уровне работы БД предприятия.
32 РенеДекарт
 
17.06.14
16:04
(30) угусь, пряморукий.
33 SSSSS_AAAAA
 
17.06.14
16:04
(27) Может это просто ты не умеешь её готовить?
34 РенеДекарт
 
17.06.14
16:04
(30) расскажи про 1с еще историй ))
35 ptiz
 
17.06.14
16:05
(24) Что вы в этих логах храните?
36 РенеДекарт
 
17.06.14
16:05
(33) если интересно - все "умельцы" по готовке рано или поздно засоряют сначала мисту, а потом SQL.ru вечными вопросами "что делать!??"
37 Strogg
 
17.06.14
16:05
Как в симпле может расти лог???
Я использовал обработку, которая анализирует размер базы. Оказалось самая огромная - таблица регистрации изменений ИБ (для обмена). Ну и еще пара регистров самописных.
38 РенеДекарт
 
17.06.14
16:06
(35) я что храню?! я - абсолютно ничего. А SQL - все транзакции, что у него проходят.
39 mkkd
 
17.06.14
16:06
(16)и что делать?
чем это ваше ограничение лога отличается от такой ситуации?
40 РенеДекарт
 
17.06.14
16:06
(37)>>Как в симпле может расти лог???
это про какой лог?
41 ДенисЧ
 
17.06.14
16:07
(37) А чего бы ему не расти даже в симпле?
42 SSSSS_AAAAA
 
17.06.14
16:08
(38) В логе SQL хранит не транзакции, и не все. Учите матчасть.
43 РенеДекарт
 
17.06.14
16:10
(39) тем, что вовремя сделаный транкэйт (в ранних SQL, сейчас сложнее) спасает мир.
И чаще делать полные бэкапы, и база чтоб в Simple была.
А 1С уж постарается "замусорить" все, до чего дотянется, вплоть до зависших сессий, из-за которых даже лог не обрежешь вручную.
44 РенеДекарт
 
17.06.14
16:10
(42) ага. понятно.
45 mkkd
 
17.06.14
16:13
(43)полная модель нужна не для того чтобы лог выращивать )))
46 shuhard
 
17.06.14
16:14
(5) раз симпл и растёт, значит надо искать отличие в бизнес-процессах

сами собой длинные транзакции не родятся,
возможно включены лишние регламентированные задания ?
47 РенеДекарт
 
17.06.14
16:14
(45) никогда не понимал со дня появления 1С, зачем народ делает для неё full.
48 mikecool
 
17.06.14
16:16
(15) настройками скуля, емнип, я не админ
49 shuhard
 
17.06.14
16:17
(47) значит ты ни разу не видел квадратных глаз ГБ, чисто случайно укокошевшей пол-часа назад сотню поступлений
50 SSSSS_AAAAA
 
17.06.14
16:22
(47) Представь, некоторые таки уважают труд пользователей и не считают возможным для себя заставлять этих пользователей вводить доки за, например, потерянные сутки. Для чего используют восстановление на определенный момент времени, что в симпле просто невозможно. Хотя соглашусь, что многие этот режим ставят совершенно не понимая зачем они ставят именно его.
51 ptiz
 
17.06.14
16:22
(38) Лог растет при модели full, когда долго не делаются полные бэкапы - у вас их запрещают делать?
52 mkkd
 
17.06.14
16:23
(47)можешь не делать.
(50)они думают что достаточно режим поставить )))
53 МихаилМ
 
17.06.14
16:27
(51)

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

в 2 раза.

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

другое дело, что размер бд и логов вырастает и стабилизируется. поэтому шринк для баз 1с - не всегда хорошо.
54 SSSSS_AAAAA
 
17.06.14
16:27
(51) Уточнение - не полные бэкапы, а бэкапы лога. Полный бэкап на лог никак не влияет.
55 ptiz
 
17.06.14
16:28
(53) Это я специально не стал писать, т.к. "вырастает и стабилизируется" :)
56 ptiz
 
17.06.14
16:30
(54) Ну да, давно настраивал, забыл.
57 РенеДекарт
 
17.06.14
16:33
(48) понятно.
тогда зачем написал "поскольку правильно ограничивать память на ЗАПРОС", если в глаза не видел ни галочки, ни параметров таких? ))
58 РенеДекарт
 
17.06.14
16:34
(49)>>значит ты ни разу не видел квадратных глаз ГБ, чисто случайно укокошевшей пол-часа назад сотню поступлений
а ты ни разу не видел разностный бэкап?
59 mkkd
 
17.06.14
16:34
(57)галочку видели праотцы )))
60 РенеДекарт
 
17.06.14
16:41
(59) ну да, ведь никто не знает, что там было на самом деле...
(51)лог растет, когда 1С делает миллион ненужных операций, а в результате - всего-то надо было 10... А SQL все пишет и пишет...
(54)вот для этого и ставите full - чтобы делать бэкапы логов... А восстановление на "момент времени" - для 1С ни о чем: у неё свое понимание "транзщакций", которые к SQL-транзакциям не относятся никак, а SQL восстанавливает транзакции как раз в своем понимании. И никто никогда не угадает, где закончилась 1С транзакция, чтобы её восстановить.
Это и к (49).
61 mkkd
 
17.06.14
16:42
(60)ну хватит уже не смешно...
62 Mikhail Volkov
 
17.06.14
17:02
(5) Наверное симпл после поставили, когда лог стал расти, и не могли его обрезать!? А база в фуле осталась... Пересоздай базу - создаешь новую, пустую, ставишь ее в симпл, и только после этого грузишь в нее выгрузку из dt. Через скульный бэкап с не обрезанным логом в симпл не переведешь.
63 РенеДекарт
 
17.06.14
17:14
(61) а мне смешно. Давно уже.
Столько "специалистов" - ууу...
Кстати, был случай, что модель full нормально заработала "с самошринкованием" только после принудительной обрезки.
64 РенеДекарт
 
17.06.14
17:15
(61) да, кому еще тоже не смешно - могут вполне поупражняться "раздели транзакции 1С и SQL".
А я повеселюсь )))
65 Медвепут
 
17.06.14
17:20
сожми лог в скуле
66 МоеИмя
 
17.06.14
17:58
ДенисЧ а можете в каких-то еще показателях рассказать про свои базы в 700 и 1200 гиг ? Кол-во док, строк и т.д. период. Самая большая табличка какая и т.д. ? Ну правда очень интересно.
67 МихаилМ
 
17.06.14
18:05
+(66)
время ТиИ
68 ДенисЧ
 
17.06.14
18:22
(66) Лень считать :-)
Но в одной, та, что 700 - максимум это регистр версий.
В другой заказы, остатки и продажи по over 400 подразделений по дням с 2010 года, + дополнительные всякие заморочки
(67) не делаем.
69 mkkd
 
17.06.14
18:59
(68)что и требовалось доказать.
70 МоеИмя
 
17.06.14
19:14
(69) Что доказано ? Пиписька коротенька у Дениски ? Или что ?
71 krbIso
 
17.06.14
20:40
(64) шо за зверь транзакция 1С?
72 МихаилМ
 
17.06.14
20:52
сдается мне, что    РенеДекарт

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