Имя: Пароль:
1C
1C 7.7
v7: Оценка размеров БД
0 linoblack
 
15.05.16
19:59
Подскажите, плиз, такой вопрос:

Есть скульная база, шринкованный размер 30 гиг. 3.2 млн. документов. номенклатура товаров около 20 тыс., к-во контрагентов - около 5 тыс.
в принципе, тормозов не наблюдается. никаких там ожиданий блокировки или т.п. скажем, период открывается довольно бысто. т.е. можно косвенно судить о том, что регистры закрываются. как мне оценить - такой размер базы является более-менее оптимальным для такого количества информации и способа ведения учета. или может база таки подраспухла неоправданно, и нужно поискать узкие места. есть ли какая-то более-менее пошаговая методика оценки?
1 Mikeware
 
15.05.16
20:15
есть АнализТаблицSQL.ert
а так, на первый взгляд - нормальная база. Документы, видать, маленькие...
2 linoblack
 
15.05.16
20:19
(1) львиное количество документов - это Т_РасходнаяНакладная на десяток-другой позиций.
3 Mikeware
 
15.05.16
20:26
(2) "Т_РасходнаяНакладная" - обертка, чтоль? уж очень похоже на наследство Садовникова и Диркса...
4 linoblack
 
15.05.16
20:31
(3) к сожалению не знаю, что такое "обертка". конфа комплексная для уа. последний релиз.

нашел эту обработку. сформировал. ну эти данные я и в скуле могу посмотреть - какой размер таблицы и сколько в ней записей. а вот как именно оценить? вот вижу, что таблица, скажем регистра деньги занимает 2 гига. как понять - это много или нормально?
5 Mikeware
 
15.05.16
20:45
(4) ну, конфы для вна я не  знаю от слова совсем.
а "много-мало" так оно столько, сколько есть.
на мой взгляд, 30 гигов для 3 лямов документов - так маловато, - у меня, наверное, вдвое больше было на аналогичное количество, но у мню была куча движений разных и своих... всякие дефициты, недогрузы, истории изменений, резервы для отделов, клиентов, менеджеров...

ну а цель этого действа вообще? ну, распухла, и что? тормозит - оптимизируй, места мало - режь либо разноси таблицы по дискам, не нравится структура - меняй....
вот измерил ты ногу, получил для нее размер обуви 44 - это мало, много, нормально?
6 linoblack
 
15.05.16
21:03
(5) ну если честно, то цель действа - проверить/выявить закрываемость/незакрываемость регистров :-)
7 Mikeware
 
15.05.16
21:08
(6) это - другое. анализ закрываемости - попытаюсь завтра выложить...
8 linoblack
 
15.05.16
21:16
(7) буду очень благода...
9 Mikeware
 
16.05.16
07:45
(8) чот не нашел.
видимо, протерял со сменой мест...
10 varelchik
 
16.05.16
08:16
(6) Проанализируй остатки где ну как правило Количество=0 а суммы<>0
11 varelchik
 
16.05.16
08:17
вот тебе и незакрытый регистр.
у мене тута на одной базе такое чудо было с РезервамиТМЦ,
14 лет рег не закрывался.
базу разнесло до 50 Гб.
12 Mikeware
 
16.05.16
08:30
(10) (11)  не всегда так.
13 Ёпрст
 
16.05.16
08:35
(11) заремь его провелдение, за ненадобностью, а сам регистр вырежи
14 los_hooliganos
 
16.05.16
08:39
30 Гиг это не очень большая база.
15 varelchik
 
16.05.16
09:12
(14) а кто говорит что большая?
Тем более для комплекса.
Вполне нормальный размер.
16 linoblack
 
16.05.16
09:57
(10) такого нет. отрицательные остатки запрещены и последовательность каждую ночь восстанавливается.
17 Mikeware
 
16.05.16
09:58
(16) ненулевые суммы могутт набнегать и из-за пгрешностей округления...
18 linoblack
 
16.05.16
10:07
(17) в регистре партий товаров не нашел таких записей. но обнаружился большой набор товаров оприходованных по фин-учету давным-давно (6 лет назад). проданы они не будут уже никогда, т.к. в реальности их не существует. так понимаю, их нужно списать?
19 Mikeware
 
16.05.16
10:22
(18) "Никогда не выявляйте в программе ошибки, если не знаете, что с ними дальше делать."© З.М.
20 mistеr
 
16.05.16
10:53
(19) Кто такой З.М.?
21 Mikeware
 
16.05.16
10:56
(20) Законы Мэрфи. (собиратель и публикователь, емнип, Артур Блох)
22 mistеr
 
16.05.16
11:08
(21) Нет у Мерфи такого. Для справки, закон Мерфи один и он вообще не про программирование.
23 Mikeware
 
16.05.16
11:10
24 mistеr
 
16.05.16
11:19
25 linoblack
 
16.05.16
19:47
(9) может хоть в общих чертах? что вспомниться?
2 + 2 = 3.9999999999999999999999999999999...