Есть 25gb файловая база ут 10.3

Сделал управление итогами Рассчитать по было 31.05.2015, стало 30.06.2018.
Сделал пересчет итогов через ТИ.
Хочу понять эффективность проделанной работы. Делаю запрос
ВЫБРАТЬ
    ТоварыНаСкладахОстатки.Склад,
    ТоварыНаСкладахОстатки.Номенклатура,
    ТоварыНаСкладахОстатки.КоличествоОстаток
ИЗ
    РегистрНакопления.ТоварыНаСкладах.Остатки КАК ТоварыНаСкладахОстатки

И такой же к Продажи, ВзаиморасчетыСКонтрагентами и прочее.


Разницы по исполнению в старой и новой, никакой 2-3%.

Почему? Как ускорить базу?

Это 1С

(0) Насколько долго выполняется запрос?

Самый долгий к ТоварыНаСкладахОстатки 109 секунд

Второй раз 0.3 секунды

(3) 109 секунд - результат выполнения запроса или выполнения и вывода?

ты берешь текущие итоги. откуда выигрышь может быть?

(6) какой сделать запрос чтобы были не текущие?

Остатки(&Дата) - за прошлый период

(3) Перейти на клиент-сервер :-)

(8) Старая база сделала запрос за 1 секунду, новая за 303. Повторные запросы обе за 1.
Так и не могу понять, какой вариант оставить.

(9) Чет мне подсказывает, что ничего не измениться.

(10) за какой период брал?

Ну а первый раз всегда медленно - ибо разогрев кэша

(12) 01.01.2018

(0) А кто тебе обещал, что расчет итогов "ускорит базу"? Покажи нам этого человека.

Текущие итоги, которые выбираются в твоем примере, поддерживаются вне независимости от периода рассчитанных итогов.

(15) Позже он указал, что взял остатки не текущие, а на 01.01.2018г.

(0) Конечно разницы не будет. Да, Анатолий.

Разница будет при проведении документов.

(17)
"Да, Анатолий" - > это к (8), (12)

(16) Вполне могли посчитаться от текущих итогов "назад".

(15) "А кто тебе обещал, что расчет итогов "ускорит базу"? Покажи нам этого человека. "

Я тут!

Разница будет при записи в регистр, не при "чтении".

"Есть 25gb файловая база ут 10.3"

Екстремалы.

(17) Зависит от документов.

(21) ну да, но самая большая таблица регсведений 2gb, второt место движения партии 1.2 gb

(0) Автор, не боисся, что база аукнется? И, если в SQL варианте, есть неиллюзорные перспективы спасти шкурку, то тут все - ты корм для рыб, и тебе крупно повезет, что к тебе спустится ангел-восстановитель vde69

(21) ну да, но самая большая таблица регсведений c фотками 2gb, второt место движения партии 1.2 gb

(20) При записи в регистр это интересно. Поясни пожалуйста, в какую сторону и за счет чего.

(22) Ну да, пишут или не пишут в регистр.

(26) Ну так все итоги надо обновить.

(26) Особенно интересно становиться, если у тебя в базе объявиться документ от 01.01.0001. Главное, 1С от этого никак не защищается.

(29) И что будет?

(30) 24000 месяцев пересчета итогов при каждом проведении дока.

(29) А надо защищаться?

(31) Ну а если его никто не будет проводить

(33) Ты не поверишь. Всё будет хорошо.

(17) Проведение реализации старая база/новая 0,135535/0,140327

Значит что то не учли.

(36) Вообщем итог эксперимента сделать свертку.

Так и запишем: найти причину не осилил.

(38) Запишем: где логика?

(37) Во-первых, свёртка сама по себе - одна из самых бессмысленных и идиотский операций, относящихся к разряду мифических серебряных пуль, которых, как известно, не существует. Реальная потребность (по различным причинам) в свёртке и какие-то положительные результаты, соответствующие ожиданиям, возникают в 5-10%% случаев.
Во-вторых, вывод о необходимости свёртки вообще никак не связан с темой ветки.

Что касается периода хранения итогов, то в зависимости от условий и особенностей работы я бы установил период хранения итогов - с начала предыдущего года по предыдущий месяц. То есть с 01.2017 по 06.2018. При условии, что более старые данные (до 2017-го года) дёргаются редко и только в отчётах, когда заказчик может и потерпеть минутку-другую, пока отчет формируется. Если же документы в закрытых периодах вообще не трогаются, а для текущих отчетов достаточно актуальных данных, то можно период итогов установить вообще 01.2018-06.2018.

(0) давайте от обратного. Что именно вы хотите? Ускорить базу.
Почему? Что-то (тормозит) не устраивает? Что именно?

(41) Автору уже ничего не нужно :-)

(25) у них картинки в базе O_o! В ФАЙЛОВОЙ БАЗЕ!!!

(43) А файловая база на диске! На жёстком диске!
Чего сказать-то хотел?

(7) Когда в "Остатки" не указываешь дату, запрос берет на дату 01.01.3999(вроде так), когда указываешь конкретную дату, например: 03.07.18, то запрос возьмет остатки на 30.06 и юнионом добавит движения до 03.07.
Так вот, время выполнения запроса без даты будет примерно одинаково до пересчета итогов и после. А вот если указать на какую дату нужно получить остатки, то тут добавится время на расчет движений до 03.07 с момента расчета итогов.
Как-то так.., может что-то упустил, можете добавить

(44) все что хотел сказать этим - сказал!

(46) Человек дождя, штолле?

(47) Нет не угадал, продолжай!

(48) Это был риторический вопрос. Даже - риторический ответ, я так скажу

(45) > может что-то упустил

Конечно упустил. Вот тут:
> запрос возьмет остатки на 30.06 и юнионом добавит движения до 03.07.

Запрос возьмет остатки на 31.07 и вычтет из них движения за период с 3.07 по 31.07.
Именно из-за того, что итоги на конкретную дату считают "задним ходом" от ближайших рассчитанных итогов, у автора ветки не было особой разницы при получении остатков на 01.01.2018года. Потому что при отсутствии итогов система считала остатки на 01.01, отнимая (вычитая) движения от актуальных итогов (на 1.01.3999). А при наличии рассчитанных итогов брала сразу готовые. Но, по всей видимости, объем самих движений за период с 1.01 по дату актуальности невелик, то и разницу по времени выполнения запроса он не увидел.

(50) да, забыл немного уж.., но сути не меняет, что оно рассчитывает от итого