Всех с наступающим. Помогите советом или своим опытом. Есть Торговля 7.7 немного переписанная (сделан серийный учет). Размер базы DBF около 1 ГБ. Есть УРБД с 17 узлами. Пользователи начали жаловаться на долгое открытие периода. Период открывается около 2-х минут. Это пользователи совсем охренели или это нормальное время открытия? Как можно ускорить этот процесс? Деятельность - розница с большим номенклатурным ассортиментом. Спасибо.

(48) не, это у мну, блин, чуть ли не основной разрез учета...

(50) ээээ.. а как получается тогда быстрое проведение документа текущим временем - он же рассчитывает (штатно) остатки на момент времени предшествующий проводимому документу... - т.е. итог + движения....??? или я в корне все неправильно понимаю..????

(49) штатными средствами двигается.

сделал приход 10.12.2011 100 тапочек, в RA будет +100 тапочки, в RG будет 01.12.2011 100 тапочки (при периодичности хранения останков месяц)

сделал расход 70 тапочек 12.12.2001, в RA будет 2 записи
10.12.2011 +100 тапочки
12.12.2011  -70 тапочки

в RG будет
01.12.2011 30 тапочки

вот взять итог на 01.12.2011 из таблички итогов - это и еть итог на ТА.

(53) за счет чего так быстро??? (не верю! ;-)

http://hare.ru/old-hareru/koncept/koncept_30.html

(54) т.е. в RG - для текущего периода хранится просто "накопительный" итоговый остаток? - а для прошлых периодов (при открытии нового периода) - формируется/пересчитывается остаток на начало "прошлого" периода..?

(52) он ничего не рассчитывает, просто берется итог из таблички итогов.
всё.

.. т.е. при открытии периода берется остаток на ТА - переносится в новый откр ываемый период и потом от итогов ТА перерасчитывается по табличке движений "начальный" итог для закрываемого периода...? - типа так?

(55) За  счет того что RG маленький, и многое сделано на оборотных регистрах.

маленькие.

(58) это я понял. я всегда считал что итоги на ТА - это есть готовый итог - как ты написал, но почему-то никогда не задавался вопросом - где он хранится...

(57) нет так..
на примере:

в RA

10.12.2011 +100 тапочки
12.12.2011  -70 тапочки

В RG
01.12.2011 30 тапочки

Открываем следующий период, в январь полетят ненулевые итоги из таблички итогов прошлого периода, в RG будет:

01.12.2011 30 тапочки
01.01.2012 30 тапочки

делаем в новом году приход 20 тапок, в RA:

10.12.2011 +100 тапочки
12.12.2011  -70 тапочки
11.01.2012  20 тапочки

в RG

01.12.2011 30 тапочки
01.01.2012 50 тапочки

Фирштейн ??

(6) вот!! а почему:
а) RG - маленький...???
- типа непосредственно перед открытием/закрытием периода "списали" все в ноль, а сразу после открытия периода - "просторнировали"...? с таким подходом КП всегда будут малюпусенькие...???

если ты в прошлом году сделаешь еще расход 50, к примеру, то должен первое, измениться итог на 01.12.2011 и второе, пересчитаться все итоги, что выше, т.е на 01.01.2012..

(64) нет, за счет оборотных регистров.
:)

(63) пока ферштею вроде... при расчете временных итогов в заднем периоде, например в январе считаем документ задним числом на 11.12.2011 - как посчитаем итоги..??

(66) а какая хитрость/смысл в использовании оборотных регистров в этом случае?
заменяем регистры остатков регистрами оборотов..??

(67) имеешь ввиду, как остаток на 11.12.2011 считать ?

берется предыдущий итог, т.е итог тз таблички итогов на 01.11.2011, далее складываем с движениями из таблички движений с 01.12.2011 по 11.12.2011 (Приход-Расход)

если ты в заднем числе что-то меняешь в движениях, то должен и итоги подвигать все что позже этой даты с тем же набором измерений.
Отсюда могут возникнуть "нулевые" итоги в прошлых периодах в табличке итогов.


Например, такое всегда происходит при свёртке.

(69) да,
берем итог ЗА ПРЕДЫДУЩИЙ МЕСЯЦ - потому что там в на данный момент хранится итог за предыдущий месяц на КОНЕЦ ПРЕДЫДУЩЕГО МЕСЯЦА - так..??

+70 или при удалении (пометки на удаление)\распроведении документа

(71) ага..
Только если период хранения останков - месяц ( у меня, к примеру, 5 дней)

(70) т.е при проведении задним числом пересчитываются все итоги до ТА по совокупности измерений - так..?

(74) да.

(73) уф!!! спасибо тебе, добрый человек! как-то это мне В ОБЩЕМ всегда понятно было, но вот в частностях - что разжевали теперь - никогда не было необходимости втыкать.. - поэтому/потомучто 1С прямые запросы мало писал.. ;-)

(70) т.е. например записали задним числом в регистр с неким набором измерений новое значение ресурса - теперь для каждых последующих итогов "докидываем" разницу между предыдущим и текущим(новым) значением ресурса..??? - что то мне кажется что не так это...

на примере тапок:
было в январе
в RA:

10.12.2011 +100 тапочки
12.12.2011  -70 тапочки
11.01.2012  20 тапочки

в RG


01.12.2011 30 тапочки
01.01.2012 50 тапочки


делаем расход 50 тапок в декабре:

в RA:

10.12.2011 +100 тапочки
12.12.2011  -70 тапочки
11.01.2012  +20 тапочки
15.01.2011  -50 тапочки

в RG

01.12.2011 -20 тапочки
01.01.2012 0 тапочки

+78
ошибся мальца
//15.01.2011  -50 тапочки
15.12.2011  -50 тапочки

(78) подожди!! тут втыкнуть надо!! разобраться раз и навсегда...

(80) чебур, ты меня удивляешь :)

(78) хитрый какой!! ;-) это понятно, когда мы НОВЫЙ док впихнули задним числом...
а как считается если мы 12.12.2011 вместо 70 продажи поставим 90...?

(81) ну так блин - я не стеснительный! ;-)
эти ж все тонкости (даже такие простые) платформа штатно скрывает от девелопера - я вот девелопер, а ты - разработчик! - разницу чувствуешь.. ;-) поэтому я у тебя учусь все время, а не ты у меня ;-))

(82) А есть особая разница ? :))

в RA:

10.12.2011 +100 тапочки
12.12.2011  -90 тапочки
11.01.2012  +20 тапочки
15.12.2011  -50 тапочки

в RG

01.12.2011 -40 тапочки
01.01.2012 -20 тапочки

алгоритм тупой до безобразия:

делаешь новую запись в RA или апдейтишь существующую, далее перебираешь все итоги от начала периодичности и позже в табличке итогов и делаешь приращение к итогу, если его нет - добавляется строка в табличке итогов.. всё собственно.

+85 от начала ближайшей даты начала периодичности итогов

(84) не.. было же
в RG
01.12.2011 30 тапочки
01.01.2012 50 тапочки
.
теперь исправляем 70 на 90
(штатный тис) - очищает движения (удаляем расход 70)
т.е. идет первый пересчет итогов
потом идет второй пересчет итогов (добавляем расход 90)
.
так???

не не не не не.. я не девелопер..

(88) ну правильно! это Я - девелопер.. ;-)

(87) ты этот пример рассматриваешь ?
в RA:
10.12.2011 +100 тапочки
12.12.2011  -70 тапочки
11.01.2012  20 тапочки

в RG
01.12.2011 30 тапочки
01.01.2012 50 тапочки

изменяем расход с -70 на -90:
в RA:
10.12.2011 +100 тапочки
12.12.2011  -90 тапочки
11.01.2012  20 тапочки

в RG
01.12.2011 10 тапочки
01.01.2012 30 тапочки

(90) да.
это ты хитро написал - у тебя сразу 90 появилось!!!
а что будет после того как исчезло 70, но еще не появилось 90..?????

в RA:
10.12.2011 +100 тапочки
12.12.2011  -70 тапочки
11.01.2012  20 тапочки

в RG

01.12.2011 30 тапочки
01.01.2012 50 тапочки

убиваем расход с -70
в RA:
10.12.2011 +100 тапочки
11.01.2012  20 тапочки

в RG

01.12.2011 100 тапочки
01.01.2012 120 тапочки

:)

(93) ага!!!
то есть реально идет при изменени количества в документе задним числом - ДВА ПЕРЕСЧЕТА (см.87)
???

(94) на счет этого не скажу, скорее всего один.
Можно в профайлере посмотреть

+95 вот если поддержка актуальности итогов включена, то скорее всего 2 (и больше, после каждой записи движения)

(95) вот уменя сомнения - как это - один??? один может быть только если рассчитывается дельта между 70 и 90 - и в итоги она докидывается...
???

может вот если стоит "автоматическое удаление движений" - то может быть перед записью движения - считывается предыдущее, вычисляется дельта и тогда возможно - один пересчет итогов..???
.
а вот если автоудаления движений нет - как например в типовой ТиС - сначала удаляем движеняи регситров по доку (один пересчет?), потом пишем новые значения (второй пересчет).
???

..или нет..??

(97) ну, 2 раза то проще сделать, чем хранить дельту.
Скорее всего так и реализовано.

(посмотрел у себя по самому проблемнму регистру - см.(46) - все чисто!! чику п уки!! однако же непонятный дисбаланс...)

(100) тогда получается, что при ручном удалении движений - возможно в определенных вариантах имеет смысл дописать вычисление дельты и докидывать ее без удаления движений...? - накладные затраты на такой расчет превысят затарты на лишнюю запись или нет.. будет выигрыш или нет..?

(102) даже не задумывался над этим никогда, обычно, запись движений и пересчет итогов не такой уж и долгий процесс, по сравнению с получением, например, останков.

по-идее, выигрыш будет, не даром же в снеговике есть запись только измененых движений регистра.

(103) получение остаНков - длиннее потому что много чтений надо делать для расчета - итоги извлечь + движения и все это просуммировать..?

(101+ возможно такой дисбаланс за счет того, что итоги я не пересчитывал давным давно и куча ненужных записей нулевых в итоге получилась - когда отлаживал алгоритм учета ОстатковГТД???)

запустил выгрузку/загрузку - м.б. ужмется лишнее...

(106) вполне, сделай выгрузить данные - загрузить данные, или тупо грохни все RG и пересчитай итоги.

(108) угумс!!! идет вроде нормально - движени я пока поряд ка 60 МБ, итоги - порядка 8Мб - так до лжно быть !!!

(108) ты еще здесь - можно еще вопрос дабы устаканить окончательно неустаканенное годами..
?

(110) еще тут

по (96) - что есть "поддержка актуальности итогов" - завсегда меня это смущало...

Параметры:
<ФлагАктуальности> - необязательный параметр. Число: 1 - временный расчет поддерживать в актуальном состоянии; 0 - не поддерживать актуальность временного расчета.  Если параметр не задан, то метод просто возвращает текущий флаг актуальности, не меняя его.
Замечание:
Данный метод можно использовать только в модуле проведения документа. Если флаг установлен, то все последующие движения регистров будут изменять итоги временного расчета, и ,значит, итоги регистров временного расчета будут все время (при проведении документа) находиться в актуальном состояни

(112) после каждого движения регистра остаток по нему изменяется, т.е актуален..
Грубо, сделал ДвижениеПриходВыполнить, если посмотрел остаток там же, в модуле проведения - он изменится на этот приход.

..для чего это..? какой смысл..?
типа для щапсиали задним числом в регистр и потом где-то тут же рядом надо прочитать итоги на немножко другой момент времени..?

Ёпрст3, можно еще воспользоваться Вашими знаниями в соседней теме по УРБД в режиме "Снежинка"?

(116( в очередь!! я первый к Ёпрсту пока!!! МНУ НЕМНОГО ОСТАЛОСЬ...

ну , алгоритмы разные бывают..
Поимел остаток и решил узнать например, какой он будет, если спишем N товара..
При актуальность (1) ты просто взял остаток и посмотрел, а так, придётся самому вычислять..

(116) я ж тебе там ответил, если будешь разве что удалять записи.
Просто при использовании фоксового провайдера, к примеру, он по другому строит индекс, в отличие от 1с, поентому, опосля инсерта\делете необходимо переиндексировать таблички средствами 1с-ины.

Если не делать инсерт, только удалять? Оставлю везде Миграцию "Все для всех". Ну не ставить же для этого sql, не нравится он мне. Работает медленне, чем DBF

(118) это понятно, но как это обеспечивается "технически" - вот если актуальность не выставить - после выполнени ядвижени ярегистра - получается пересчета итогов не будет "внутри" процесса записи движения?? - будет только при "закрытии" транзакции..???

(121) не знаю, скорее всего, всегда пересчитывается  - надо в профайлере смотреть, что там выполняется при этом.

(122), то есть что там  "унутре" - осталось невыясненым... и наскольо нагружаер систему включение/отключение актуальности - непонятно..
ну раз так - пусть ПОКА так.. ;-)

Но вот то, что у меня после загрузки итоги считаются уже час целый при маленькой базе (1.6 Гига, с 01.01.10) - это явно блин что-то не то...

поэтому интересно, что там у NS с оборотными регистрами намучено..? в чем фишка?

Ёпрст, а период для своих 5-идневок как открываешь..?

блин, прошерстил все проблемные места - все нормуль.. а период все равно открывается 10 минут... куда копать? на что смотреть? как уменьшить?

Вот еще какая мысль посетила. Можно ли проверить "закрываемость" регистра (при условии, что есть движения и в плюс и в минус), "раскрыв" его по всем измерениям и проверив отрицательные остатки по ресурсам. Если есть минусы, значит все плохо, регистр "не закрыт".

(128) Можно, но не "минусами..."
1. смотришь количество ненулевых остатков в ресурсах.
2.сворачиваешь по n-1 измерениям, смотришь количество ненулевых остатков в ресурсах. Если сильно упало - значит, по этому измерению со значительной долей вероятности регистр не закрыт...
3. проверяешь по другим измерениям...

(129) пора уже проверялку для баз написать...

(130) Да кому это надо?
Хотя работы на пол-часа, не более..

(131) время пошло.. ;-)

(132) Лень. Все лень. Даже курс насфа слушать лень... покатался на лыжах - вроде и не устал, а лень напала...

(134) так и запишем - сломался...

Подниму тему. Опять долгое открытие периода на январь 2012.
Взял копию базы и оставил только ввод начальных остатков по 18 местам хранения на 31.12.11. Попробовал сделать открытие периода на январь 2012. Времени заняло столько же (порядка 2 минут). Делаю вывод, что "незакрытость" регистров тут уже не причем. Никаких других документов кроме ввода остатков ТМЦ в базе нет. Ускорить  реально или нет?

(136) ПОсмотри профайлером, что оно делает...

Видимо проблема все-таки в количестве остатков. Если оставляю один склад, открытие практически мгновенно, с двумя уже дольше и т.д. SQL даст прирост в скорости?

(138) значит, проблема в индексах...
а будет ли быстрее сиквел.... вопрос сложный. все зависит от соотношения радиусов™....

Может быть проблема из-за дополнительного измерения в регистре? Измерение - справочник, но у справочника не определен код и наименование (длины нулю равны).

(140)если по этому измерению все закрывается - то проблем нет.
если по нему не закрывается - надо исправлять соотношение....

кстати, на работе накидал "проверялку закрыванй". но для сиквела...

(139) А как можно проверить проблему с индексами?

(143)переиндексироваться...

(144) Я пробовал вообще удалить файлы RG и RA, повторно провел документы ввода остатков, ничего не изменилось. Может это все же нормально, такое время открытия? Если в цифрах, то остатков где-то 10000-12000 строк в номенклатуре по каждому из 18 складов, т.е в целом в базе 180000-216000 записей в регистре.

(145) на период соответственно

скопировать 300 тыс записей - недолго

(147) Самое интересное, что сам процесс добавления записей в файл происходит быстро, но перед этим 1С грузит процессор почти все время открытия 1 мин. 50 сек., а секунд 10 именно пишет данные в файл.

(148) Так оно и понятно - сначала в памяти или во временной директории мы записи накапливаем (то есть выполняем запрос), а потом его результат просто и быстро записываем в файл. Как-то, писать неготовые данные - их потом переписывать придётся.

да вот хрен его знает... у меня регистры вроде закрыты, база небольшая, товарные остатки примерно 2500 позиций, по несколько партий на позицию - открытие месяца идет ну офигеть как долго...