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

проверить закрытие регистров

потом будет 5 мин, потом 10, потом час, и т.д.

Регистры нормально закрываются, остатков много, но они должны быть - это розница

Время открытия периода месяц от месяца не увеличивается, т.к. остатки приблизительно одни и те же из месяца в месяц. Как ускорить и есть ли смысл в этом?

неужели раз в месяц трудно 2 мин. подождать?

Пользователи они такие пользователи

сколько периодов (месяцев) в базе?
2 минуты - это нормально...
хотя конечно мне больше нравится 30 сек

Базе 6 месяцев

(5)+1
Наши по полчаса ждут и ничего

В принципе, если базы сиквельные - то можно сделать "фоновое открытие периода". Только вряд ли они у ТС сиквельные - слишком мелкие базенки...

как сделать юзеров счастливыми? сначала нужно увеличить время открытия периода до 30 мин, а потом героически его сократить до 5 мин.

(8) какой самый большой файл из файлов DBF RA* ? - размер его?
какой самый большой файл из файлов DBF RG* ? - размер его?
..
если 6 месяцев - готовьтесь, месяца через два открытие периода скакнет резко до десятков минут, потом до часа...

(8) и имена файлов для 12!!!

Самый большой регистр - регистр Партий RA328.DBF, размер 132 мб. Самый большой RG RG328.DBF, размер 46 мб.

Базы не сиквельные, я в первом сообщении это написал. SQL не будут покупать - это точно.

(0) 2 минуты долго?! Скажи им, что они офигели просто! Могу показать базу, где 40 минут период открывается.

Оборотные регистры с периодом месяц могут увеличивать время открытия периода?

Переходите на восьмёрку. Там пользователи сначала год ругаются и увольняются, потом привыкают и всем довольны.

В шестёрке такого не было.

посмотри пары регистров RG и RA - смотри те пары, которые RG сопоставим или ненамного меньше размером с RA - это проблемные регистры
смотри - неподтвепжденные заявки должны закрываться!! все заявки долджны закрываться!!!!
.
если по банку показывают в основном только приход - закрывайте банк!!!
обнуляете ли кассу? или только туда приход днег идет - надо закрывать!!!!
если берете на комиссию/отдаете на комиссию - закрываете ли отчетами комиссионера??
если есть продажи в базе от разных ваших фирм с общих остатков - есть ли сделанные перепродажи между фирмами?
.
формируете ли в конце месяца регламентный документ "Формирование записей книги продаж" и "..книги покупок" (эти доки закрывают регистры книг)!!
.
вот тебе первые кандидаты на незакрытые регистры

(0) 2 минуты это долго.
база в 20 гигов открывает следующий период за несколько секунд.
Меньше минуты, это точно.

+21 дбф, если что.

Злопчинский, спасибо! Действительно не закрыты регистры книг и кассы, сейчас закрыл, все залетало. Еще раз спасибо и с Новым Годом!

(21) Ёпрст, а вот это утверждение - правильно?
"пары регистров RG и RA - смотри те пары, которые RG сопоставим или ненамного меньше размером с RA - это проблемные регистры"
???
.
с какого соотношения размеров можно бить тревогу?

(24) когда RG>RA..
и то , смотря что за регистр, мот там налепили тока приходов и всё.. а расхода и нет вовсе, к примеру.

(25) 4 незакрытых регистра у меня... странно... то-то не сильно быстро период открывается...

А почему незакрытые регистры при открытии периода так тормозят процесс..??

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

(28) давай на [email protected]
и обработку свою лучше дай, а тоя прошу а ты все молчишь.. так и скажи не дам! ;-)

http://s55.radikal.ru/i147/0907/fc/0d1be61a68c2.jpg

о блин.. 351 - первый незакрытый регистр - ПартииОтданные - откуда там незакрытость вообще в принципе - если за все время только одна выдача на комиссию и то - в этом месяце...??? непонятно...

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

(30) дай лучше обормотку, которая это рисует ... правда если она для скула - то пользы мну мало - на dbf у меня...

(33) эту картинку я нарисовал рученьками, а не обработкой, одному упёртому дятлу с инфостарта, в качестве примера, что он натворил с базой.
:)

(32) - это все понятно. но почему так ДОЛГО Открывается период чисто технически..???
для каждого итога предыдущего месяца при открытии следующего месяца что происходит...??? почему так долго..?? он что - для новых итогов берет  предыдущие итоги и начниает плюс/минус движения складывать...??? типа "перепроводит" период...? а как же итоги на ТА - они же быстро получаются..? имеем итоги на ТА - прочитали их и записали на новый итог период...???

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

При открытии периода, берём итоги на та (т.е на ближайшую дату начала периодичности хранения останков ) и переносим их в следующий период с проверкой, если по всем ресурсам итог =0, его не переносим.
Всё собственно.
Просто у незакрытого регистра, таких записей будет много, фактически, они кочуют из периода в период прирастая новыми итогами.

Смотри картинку слева.

4335 - покупатели - тут не особо понятно... надо смотреть... хотя есть много покупателей на длинных отсрочках... и есть мелкие суммы незакрытые которые тянуться могут очень долго...

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

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

(37) это понятно! но ну не может так долго быть!! лабудень какая-то все равно... база к меня 1.6 Гига - даже при вообще тотальной незакрытости регистров все по идее быстро переноситься должно!!!

(40) да, это понятно мну!

(39) да очень просто, итоги на та, это просто селект к табличке итогов когда period = ближайшая дата начала периода хранения останков.

Итоги на любую дату = итоги на предыдущую дату начала хранения останков + движения из таблички движений от начала даты хранения останков до выбранной даты.

Из=за обращения к большой табличке движений (а там записей вагон и маленькая тележка) - все тормоза с расчетом регистров.

(21) 50 гигов - несколько секунд.

вру - 70 Гигов уже.

8389 - остатки  ГТД (самописный) - по сути это партионный учет остатков, закрываемый по ЛИФО
RG = 102 МБ, RA = 64 МБ - если бы было что-то незакрытое - у меня бы напрочь все сразу колом сталов проведении.. непонятно...

(43) эээ.... а где в итогах на ТА учет движений от итогов до точки ТА...???? итоги на ТА - это ближайшие итоги  таблице итогов + движени zjn последних итогов по таблице движений до точки ТА - так????
.

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

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

(47) не так :)

Итоги на ТА - это просто итоги в табличке итогов на последнюю дату начала периодичности хранения останков.
всё.

(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 позиций, по несколько партий на позицию - открытие месяца идет ну офигеть как долго...