|
Обновление конфигурации базы данных без пересчета итогов | ☑ | ||
---|---|---|---|---|
0
sound
16.02.12
✎
15:48
|
Возможен ли сабж, да то как, если нет то почему?
|
|||
1
Amra
16.02.12
✎
15:53
|
То есть ты хочешь изменить измерения регистра, а чтобы в таблице остатков все осталось под старыен измерения?
|
|||
2
Живой Ископаемый
16.02.12
✎
15:56
|
да, если отключить итоги предварительно...
|
|||
3
mikecool
16.02.12
✎
15:57
|
(2) все равно когда то включит )
|
|||
4
sound
16.02.12
✎
15:59
|
(1) Я уже сам не совсем хорошо понимаю что я хочу, разве что мира во всем мире :). Просто хотелось бы как-то разделить чтоли процесс обновления и процесс пересчет итогов, или хотя бы понять почему это происходит 2-е суток, вот вопрос КАК это сделать ну и что за это будет.
|
|||
5
zmaximka
16.02.12
✎
16:01
|
а уверен что пересчет идет, а не реструктуризация регистра?
|
|||
6
sound
16.02.12
✎
16:04
|
(5) За 3 неудачные попытки обновиться вовремя было замечено, что сначала идет
1) реструктуризация ~часа полтора 2) потом пересчет итогов ~2 суток 3) потом снова реструктуризация ~часа полтора |
|||
7
Amra
16.02.12
✎
16:08
|
(6) Нормально закрывать регистры не предлагать?) Если итоги распухшие, то и за неделю может не пересчитать
|
|||
8
sound
16.02.12
✎
16:12
|
(7) А нормально закрывать это как? Объясни если не сложно.
|
|||
9
Живой Ископаемый
16.02.12
✎
16:14
|
2(3) Может он для включать перекинет базу с ИД 5400 оборотов в минуту на ССД или РАМ-диск
|
|||
10
Amra
16.02.12
✎
16:14
|
(7) Ну например регистр "Взаиморасчеты", в нем два измерения, Контрагент и Договор. Отгрузка товара прошла по одному договору, а оплата по другому. В целом до контрагенту никто никому не должен, а в итогах плюсовой остаток по одному договору, и минусовой по другому - а должно быть ничего
|
|||
11
sound
16.02.12
✎
16:26
|
(10) А пример для регистра бухгалтерии есть?
|
|||
12
Amra
16.02.12
✎
16:30
|
(11) Аналогично
|
|||
13
sound
16.02.12
✎
16:35
|
(12) Ну вот была бы база гигов 200 можно наверно было бы и про свертки и про закрытия думать, а она всего ~20 гигов - децтво, но почему же она так долго эти итоги пересчитывает?
|
|||
14
Amra
16.02.12
✎
17:47
|
20 гиг при незакрытых регистрах более чем достаточно для таких временных затрат
|
|||
15
sound
17.02.12
✎
08:43
|
сколько же тогда база в 200 гигов будет обновляться
|
|||
16
Aleksey
17.02.12
✎
08:50
|
(15) Нисколько, ибо врядли найдется такая база на 1С
|
|||
17
ДенисЧ
17.02.12
✎
08:51
|
(15) Правильно ведомая база - за полчаса.
|
|||
18
ДенисЧ
17.02.12
✎
08:51
|
(16) Такой длинный хвостик - и такой наивный...
|
|||
19
Aleksey
17.02.12
✎
08:53
|
(18) Ну что то ниразу тут не пробегала инфа, что у кого то база на 200 гиг в 1С 8.2
|
|||
20
Dmitrii
гуру
17.02.12
✎
09:05
|
(14) >> 20 гиг при незакрытых регистрах более чем достаточно для таких временных затрат
У нас такая примерно бухня. Реструктуризация с пересчетом занимают 2 - 3 часа. |
|||
21
Dmitrii
гуру
17.02.12
✎
09:06
|
(19) >> Ну что то ниразу тут не пробегала инфа, что у кого то база на 200 гиг в 1С 8.2
Люди работают (данные вколачивают), а не на фарумах сидят. :)) |
|||
22
Dmitrii
гуру
17.02.12
✎
09:07
|
(0) Что сделали с регистром, что требуется реструктуризация с пересчетом?
Не используется ли в качестве типов субконто простые типы (строка, число, дата)? |
|||
23
ДенисЧ
17.02.12
✎
09:12
|
(19) Если про 120Г на 77 пробегала, то на 82 сделать 200 не проблема...
|
|||
24
Aleksey
17.02.12
✎
09:18
|
(23) Это когда от 1С только оболочка, а остальное - прямые запросы и хранимки?
|
|||
25
sound
17.02.12
✎
10:47
|
(22) А это как-то может повлиять на время пересчета итогов?
|
|||
26
Aleksey
17.02.12
✎
10:49
|
(25) Индексы у ростых типов очень сложные
|
|||
27
sound
17.02.12
✎
10:49
|
Не нету таких
|
|||
28
sound
17.02.12
✎
10:51
|
Ах да, забыл сказать, у нас 6 субконто, есть подозрение что тормоза именно из-за этого
|
|||
29
Sammo
17.02.12
✎
10:57
|
(28) Самоубийцы...
|
|||
30
sound
17.02.12
✎
11:01
|
(29) Жизнь такая
|
|||
31
Amra
17.02.12
✎
11:22
|
(29) Ты б посмотрел Инталев:КМ... Там вообще 15 )))
|
|||
32
Баклажанов
17.02.12
✎
11:38
|
обновление http://goo.gl/GiLcc
|
|||
33
Aloex
17.02.12
✎
11:43
|
(29) бггггг....
|
|||
34
Aloex
17.02.12
✎
11:44
|
(28) на каком счете?
|
|||
35
sound
17.02.12
✎
11:52
|
(34) На 08.03 (Строительство объектов основных средств), на 10.11.1 (Специальная одежда в эксплуатации), на всем 60-м, на 86 (Целевое финансирование из бюджета), и еще есть, на других тоже по 4-5 субконтоф, кароче хватает
|
|||
36
Леха Дум
17.02.12
✎
11:58
|
мы из положения выходили при тотальном пересчете следующим образом для регистров накопления: сносили таблицы остатков регистров (средствами SQL) дату расчета итогов сносили на время до самого первого документа в системе, затем проводили реструктуризацию, потом восстанавливали актуальную дату итогов с пересчетом итогов ессно - получалось гораздо быстрее - SQL серверу оставалось только лить записи по остаткам без необходимости перед этим затирать старые
|
|||
37
Леха Дум
17.02.12
✎
12:00
|
+(36) база как раз в районе 200 гиг :)
|
|||
38
hhhh
17.02.12
✎
12:05
|
(35) а ты не показал бухам, что оборотку можно спокойно формировать и по реквизитам субконт? Тогда бы они не бесились и на всех счетах было бы по два-тир субконто.
|
|||
39
sound
17.02.12
✎
12:13
|
(38) Поздняк метаться, это было еще до меня, переделывать много, да и неохота нифига
|
|||
40
Aloex
17.02.12
✎
12:29
|
(39) Рано или поздно упретесь в не возможность обновлять базы.
|
|||
41
sound
20.02.12
✎
09:34
|
А на что идет нагрузка в момент реструктуризации и пересчета итогов регистров? На файловую систему сервера приложений или на память SQL-сервера или чего-то еще? Можно ли вообще как то ускорить процесс пересчета итогов за счет каких-то физических ресурсов или может быть каких-то серверных настроек?
|
|||
42
sound
20.02.12
✎
14:47
|
Скажите что-нибудь по (41) а?
|
|||
43
sound
24.02.12
✎
09:43
|
UP
|
|||
44
Aloex
01.03.12
✎
20:23
|
(41) Все ресурсы важны, избавляйтесь от лишнего - пи..дeц пришел.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |