Имя: Пароль:
1C
1С v8
Поможет ли клиент-сервер?
0 Mary01
 
14.01.13
17:44
Суть проблемы: для БП 8.2 есть отчет по задолженности контрагентов, его необходимо сдавать в конце каждой недели. Для того, чтобы отчет был корректен, необходимо перед его формированием восстанавливать последовательность (т.к. часто заводим документы не в том порядке, в каком они есть в реальности, а еще часто возникает необходимость исправить что-либо в ранее проведенных документах - таковы издержки бизнес-процесса).
В базе примерно 50 тыс. документов Поступление на расчетный счет, столько же Релизаций ТиУ. На компьютере с оперативной памятью 2 ГБ восстановление посл-стей идет около суток, работать нереально. т.е. в эту базу отчет пока внедрить не могу, а нужно. Как повысить производительность? Достаточно ли увеличить оперативку? Поможет ли перевод базы с файлового режима на клиент-серверный?
1 mikecool
 
14.01.13
17:45
запусти регламент для восстановления последовательности - пусть ночами вытягивает
2 pessok
 
14.01.13
17:46
больше рамы и клиент сервер немного помогут.
(1) еще лучше поможет :)
3 Mary01
 
14.01.13
17:48
(1) регламентное задание что ли создать?
но ведь процедура длилась больше суток, ночи не хватит...
4 pessok
 
14.01.13
17:49
(3) если надо раз в неделю, то что мешает делать это все воскресенье? + ночью нагрузка меньше, сиречь будет ползти быстрее
5 mikecool
 
14.01.13
17:49
(3) не хватит, но в ночи к примеру 6-7 часов, итого за 4 ночи неделя проведется
6 pessok
 
14.01.13
17:50
(5) дак они постоянно сбивать будут
7 Mary01
 
14.01.13
17:52
(2) эээ... что такое рама?
В том-то и дело, что "немного". А мне надо как-то показать руководству, на сколько именно процентов помогут? На 10, 20, 50? Т.к. если предстоят немалые расходы на сервер, перенос базы на клиент-серверный вариант и т.д., и если после этого все будет ползти так же медленно, то меня, мягко говоря, "по головушке не погладят".
8 mikecool
 
14.01.13
17:53
(6) сервер все равно круглосуточно работает, зато на утро максимально реальные данные
9 Mary01
 
14.01.13
17:53
(5) дело в том, что даже если часть восстановится в первую ночь, бухгалтера на следующий день могут влезть и опять там что-то провести - опять надо будет восстановить.
10 pessok
 
14.01.13
17:54
(7) так и хочется пошутить в стиле американских комедий, да не буду :) на самом деле прирост должен быть ощутимым, скорее всего.
11 hhhh
 
14.01.13
17:54
(9) надо не по сети запускать задание, а прямо на сервере. Тогда где-то в 10 раз будет быстрее. То есть не 6 часов, а полчаса.
12 pessok
 
14.01.13
17:55
(9) об этом я написал в (6), но в (8) есть крупица истины. на УТРО инфа будет боль-мень актуальная
13 YF
 
14.01.13
17:55
(9) Раз такой бардак - проси либо железо для сервера максимально возможной производительности + СКЛ-сервер, либо пусть бухи руками исправляют свои косяки
14 pessok
 
14.01.13
17:56
(13) чем больше правок руками, тем меньше последовательностей, же
15 samozvanec
 
14.01.13
17:58
(0) боюсь, тут медицина бессильна
16 YF
 
14.01.13
17:58
(14) Не понял
17 Mary01
 
14.01.13
17:58
(15) Почему?
18 samozvanec
 
14.01.13
18:00
(17) распараллелить вряд ли удастся, а скоко сервер не корми - он столько разом не проглотит.
19 samozvanec
 
14.01.13
18:01
+ (18) подумай лучше, как избежать восстановления
20 MrStomak
 
14.01.13
18:02
Выигрышь в скорости проведения документов при переходу на SQL может вообщеть быть отрицательным относительно работы 1го пользователя в файловом режиме.
Важно понимать другое - при такой специфике последовательность надо дробить по контрагентам и восстанавливать по ним же.
Ну и если восстанавливать её каждый день, то не нужно будет сутки ждать, не успеет она так сильно сбиться.
21 Mary01
 
14.01.13
18:06
(18) этого я и боялась, ждала здесь этой фразы.
Потому что на форумах и в статьях не раз встречала 2 противоположных мнения в ответ на вопрос: как сделать, чтобы 1С работала быстрее:
Превое: поможет sql и максимально производительное железо!
Второе - это не поможет, т.к. 1с все равно сожрет всю память, а sgl не означает ускорение - бывает даже и наоборот, замедляет!
Рекомендовали что-то мутить с блокировками (самостоятельно для каждого документа настраивать), но тут, как я понимаю, не в блокировках дело, ведь восстановление идет монопольно.
22 Mary01
 
14.01.13
18:08
(19), (20) - супер идея, но как именно? Можно написать обработку, которая бы восстанавливала только по тем контрагентам, по которым были измнения, тогда:
1. Как узнать, по каким? и где хранить эту разницу?
2. Как вообще работает восстановление, где код посмотреть? Точку останова там, увы, не поставишь.
23 bzaugolnov
 
14.01.13
18:09
Есть вариант: не использовать последовательность, а генерить собственную временную таблицу (например регистр сведений) а отчет строить на основе нее.
Что касается перепроведения, то локальный файловый вариант перепроводиться на порядок быстрее SQL.
24 MaxS
 
14.01.13
18:11
Можно распараллелить базы. Сделать две распределённых.
В одной круглосуточно восстанавливается последовательность, в другой оперативная работа. Потом обмен данными - всё с движениями регистров быстро переливается.
25 Mary01
 
14.01.13
18:12
(23) - спасибо, попробую.
26 MrStomak
 
14.01.13
18:13
(22)
1.Последовательность может содержать измерения, они там прям в объектах и указывается.
2. Указывается связь этого измерения с измерениями регистров, которые двигают последовательность (ну там тупо контрагент=контрагент).

В типовом функционале последовательность ведётся только в разрезе организации. После описанной в п.1-2 доработки, можно восстанавливать последовательность методом Восстановить с передачей структуры отбора по нужному контрагенту.

Минусы: собъётся последовательность партионного учета.
27 MrStomak
 
14.01.13
18:14
(24) и как только сливается, сразу теряет актуальность восстановленная последовательность...
28 MaxS
 
14.01.13
18:20
(27) периодически нужно закрывать период для изменений задним числом.
Например, в оперативной рабочей базе закрыли период на такое-то число.
В соседней распределённой спокойно восстанавливаем последовательность на это число.
Если бухгалтеру нужно изменить документ задним числом, останавливаем проведение документов, двигаем дату запрета, меняем документ, обмениваемся данными и т.п.  бесконечная борьба за последовательность ;)
29 Mary01
 
17.01.13
13:53
Снова всем здравствуйте!
Вот - для сравнения - у меня память на компе 4 ГБ, вечером восстановление запустила, утром пришла - все готово (на копии базы, она составляет примерно 2 Гб)
На сервере: память 8 Гб, 1С и база (база 2,5 Гб) - на этом сервере, в терминальном доступе запустили восстановление посл-стей: длилось оно сутки (пол-суток монопольно, потом пользователи подключились. т.к. уже нужно было начинать работу), тогда вообще зависло. А ведь при восствновлении последовательностей часто еще и ошибки возникают, когда процедура прерывается и не может документ провести - его надо проводить руками, и заново запускать процедуру.
30 Живой Ископаемый
 
17.01.13
13:56
2(29) кому это может быть интересно?
31 Mary01
 
17.01.13
13:57
(23) Да, такой регистр есть - отчет строится именно по нему. В программе есть доработка, чтобы типовые документы (Реал. ТиУ, Поступл. на расч. сч. и др.) двигали этот регистр. Вопрос только в том, что как в этом регистре отмечать, какие документы проведены в верной последовательности. а какие нет.
32 Mary01
 
17.01.13
13:58
(30) Вам, например. Вы же зашли в эту тему. Или мне надо было новую создавать?
33 lefthander
 
17.01.13
14:01
может быть попробовать оптимизировать издержки бизнес процесса? приведите пример когда каждый день надо изменять кучу документов за прошлые периоды. Может тех кто сидит на документах заставить не ошибаться при их вводе?
34 Mary01
 
17.01.13
14:05
(33) Почти каждый день. Такое бывает, т.к. часто первичные документы приходят в бухгалтерию с опозданием на несколько дней.
35 Lexusss
 
17.01.13
14:06
Будет получше. Конкретика зависит от слишком многих факторов, чтобы дать ответ по фотографии. Проще всего - проверить.
36 syktyk
 
17.01.13
14:11
В порядочных конторах ввобщ запрещено доки задним числом править. За это увольняют или лишают плюшек.
37 ИС-2
 
naïve
17.01.13
14:12
(34) пусть поставшики присылают в электронном виде. Используйте ордерную схему (в начале товар), а потом документы.
38 Mary01
 
17.01.13
14:14
Поменять бизнес-процессы не в моих силах. Но за варианты спасибо, обязательно вынесу на обсуждение, может быть руководство что-то и решит.
39 lefthander
 
17.01.13
14:14
(34) я не про то что документы приходят позже, я про их изменение...
ИМХО конечно, но ваша борьба за последовательность смахивает на параною...
Какая именно последовательность влияет на долги контрагентов? вы же наверняка эту задолженность берете не из регистров накопления а из регистра бухгалтерии. :)
40 Mary01
 
17.01.13
14:15
Но пока мне вот этот вариант интересует - с регистром. Имею в виду, как по нему отследить, какие документы надо перепровести, а какие нет.
41 lefthander
 
17.01.13
14:18
а какие документы определяют важность последовательности? Долги - это суммы, на счетах, итоги по счетам фиксируются раз в месяц. после закрытия месяца изменения не должны происходить.
42 Mary01
 
17.01.13
14:19
(39) - изменений тоже полно. пересмотр цены за услугу - очень часто. поэтому лезут в документы задним числом и исправляют.
Влияет общая последовательность. Да, именно из регистра накопления. Но даже если б и брала из регистра бухгалтерии - что, в нем разве последовательность роли не играет?
43 lefthander
 
17.01.13
14:26
Значит отчет у вас самописный и что то допилено на регистрах. Смотреть надо структуру регистра и реализацию отчета. Копайте в эту сторону.

Пересмотр цены за услугу и исправление ее задним числом в документе в течении текущего месяца... лихо.
44 Mary01
 
17.01.13
14:42
(43)да там всё лихо. Ну да, самописный он, и на самописном же регистре.
45 Живой Ископаемый
 
17.01.13
16:41
2(32) зашел, думал что-то интересное. а тут нюансы какой-то базы. кому они нужны - не понятно.
46 Naumov
 
17.01.13
16:48
(0)Рам-диск для восстановления используй.
ну или SSD на худой конец.
Чтобы обнаруживать ошибки, программист должен иметь ум, которому доставляет удовольствие находить изъяны там, где, казалось, царят красота и совершенство. Фредерик Брукс-младший