Пересчет бухгалтерских итогов в 1с 8.3. Проверки и режимы

В настоящее время значительная часть баз данных на основе 1С-Предприятие 8.3 используется в режиме «Управляемое приложение». В том числе в этом режиме происходит и процесс регламентного обслуживания, такой, например, как открытие следующего периода.

Рассмотрим процесс открытия очередного периода подробнее. Как всем известно регистры накопления и регистру бухгалтерии построены из нескольких таблиц. Для простоты понимания мы будем рассматривать только основные две:

• Основная таблица: таблица движений для регистра накопления или таблица проводок для бухгалтерского регистра.
• Таблица итогов: хранит итоги по периодам. Служит для ускорения построения различных отчетов и выборок за периоды кратные периоду хранения итогов (месяц).

Итоги необходимо иметь по всем регистрам за все периоды, которые могут быть востребованы пользователями для отчетов. Исходя из специфики работы базы данных - необходимый период итогов может различаться. Например, для регистров накопления, используемых в торговле требуется одни параметры, которые могут сильно различаться в зависимости от специфики работы предприятия. В то же время для бухгалтерии намного более стандартизированные требования для хранения итогов. В частности типичная ситуация, когда идет в текущем году построение отчета ОСВ или ОСВ по счету поквартально, по полугодиям, либо целиком за прошедший год.

А теперь рассмотрим такую часто встречающуюся ситуацию. Прошел месяц, требуется провести открытие следующего периода. Идем в меню управления итогами. По умолчанию открывается форма «Управление итогами - часто используемые возможности». На самом деле будет открываться форма в том режиме, в каком мы ее закрыли последний раз, это либо краткий, либо полный режим. Но нас интересует именно «Управление итогами - часто используемые возможности». Это очень простая форма. Нам тут нужна кнопка «Установить период рассчитанных итогов». Если прочитать текст, то можно понять, что система все автоматически определила и предлагает открыть правильные периоды для регистров накопления и регистров бухгалтерии:

Нажимаем кнопку «Установить период рассчитанных итогов;», пребывая в полной уверенности, что мы открыли следующий месяц, без ущерба для уже существующих итогов.

По состоянию до нажатия кнопки итоги были рассчитаны за 2016 год с января по декабрь. То что хотелось бы видеть - это расчет итогов по текущий момент включительно, собственно, как и предлагалось в описании к кнопке. Посмотрим, так ли это. Для этого нам необходимо переключиться в режим полных возможностей.

А теперь смотрим на скриншот с результатом и попытаемся интерпретировать его:

Мы видим, что регистры накопления рассчитаны не так как ожидалось, с 01.01.2016 по 30.04.2017, а за совершенно другой период: с 01.04.2016 по 30.04.2016. Аналогично бухгалтерский регистр рассчитан не с 01.01.2016 по 31.05.2017, а с 01.05.2016 по 31.05.2017. Неизвестно, подойдет ли такой период для функционирования торговли, но вот насчет бухгалтерии абсолютно точно будет потенциально очень серьезная проблема производительности при построении отчетов за 2016 год по следующим периодам: первый квартал, первое полугодие, год. Причем проблема производительности будет прямо пропорционально количеству проводок, проводимых базой в месяц, так как при отсутствии рассчитанных итого данные в запросе будут получаться из таблицы движений за данный период.

Почему это получается? Неизвестно с какого момента это началось, с какого релиза платформы, но, по всей видимости 1С решила прибегнуть к такому решению с точки зрения оптимизации размеров базы данных. Типовые конфигурации достаточно большие, в том числе структура регистров содержит много измерений, видимо в какой-то момент было принято решение, что итоги нужны за текущий месяц и плюс за предыдущий год. Ведь именно так и рассчитываются итоги в «простом» режиме, если администратор базы данных вручную не указывает правильный период, пользуясь «полным» режимом.

Для исправления ситуации мы воспользуемся кнопкой «Установить период итогов...».

В открывшемся диалоге введем требуемые начальные даты отдельно для итогов регистров накопления и отдельно для бухгалтерии. У меня дата начала года подставилась туда автоматически. Нажмем кнопку «ОК». Смотрим, что получилось:

Как видно, теперь мы получили то, на что рассчитывали изначально. Какой из этого можно сделать вывод? Только тот, что процедуру открытия периода в управляемых формах следует проводит с использованием режима «Управление итогами - полные возможности» и никак иначе, в противном случае возможно получить серьезную проблему производительности. Соответственно нужно понимать, какие даты следует ставить в поле для начальной и конечной даты и контролировать корректность этих дат. Тогда ошибки и связанной с ней проблемы производительности можно будет избежать!



) а разработчики платформы тут не причем, это довольно известное архитектурное решение, не удалять "нулевые" записи. Я бы даже сказал что это давняя "священная война".

Тут самое главное понять что запись с нулевым количеством в итоге, совершенно не означает что эта запись не нужна.

При проектировании реляционных СУБД считается (считалось) что операции CRUD (Create, Read, Update, Delete) по затратам ресурсов распределяются следующим образом

1. Легкие: Read, Update
2. Средние: Create
3. Тяжелая: Delete

И исходя из логики поведения объекта Регистр, который меняется часто; и из-за больших затрат на удаление записей, существует позиция что:

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

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

И вот тут я могу сказать что разработчики платформы слегка "недочлись" (от слова "недочет") - дело в том что согласно вышеописанному архитектурному решению явно становится понятно, что:

Удалять записи с нулевым итогом нужно по тем ключам (комплектам измерений), по которым длительное время не было операций UPDATE. А этого функционала в платформе нет - есть только глобальный пересчет. В крупных конторах это решается SQL Job"ом выполняющем примерно следующую работу:

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

обычно данный Job запускается раз в 10 секунд, выбирается TOP 1 чтобы уменьшить время блокировки на затратную операцию удаления. Естественно в такие базы уже встроены и планы обслуживания по пересчету статистики и перестроению дефрагментированных индексов. В случаях когда таких "ненужных" записей очень много - то обычно уменьшают период запуска Job, либо отказываются от Регистра Итогов - потому что если у вас много ключей уходит в "ноль" и больше не используется, скорее всего у вас по данным ключам 2 операции движения "пришел" и "ушел" - зачем хранить такую информацию в регистре итогов совершенно не ясно.

Ну и про статистику тут тоже все изъезжено - масcовые операции CREATE И DELETE, а также UPDATE ключевого столбца ведут к нарушению дерева поиска по индексу (диапазона распределений ключа по страницам данных) - ну то есть в поисковом диапазоне 1..10 вполне себе может оказаться ключ со значением 23 - так SQL было удобней, потому страница данных была рядом со страницей ключа 7, а ключ 6 заместо которого встал ключ 23 окажется в диапазоне 100..134 - что тоже было удобней исходя из страниц данных. Пример на пальцах - но думаю суть отражает.

Вообще про статистику в момент массовых операций удобно понять следующее: когда вы делается массовую вставку данных SQL пытается вам помочь и оперирует близостью страниц данных для оптимизации вставки и совершенно забывает про оптимизацию операций чтения, где параметром является статистика (диапазоны поиска ключа в таблице - распределение ключа), поэтому чтобы после массовых вставок операции чтения были тоже быстрыми - необходимо восстановить работоспособность инструмента оптимизации чтения выполнив UPDATE STATS.

Да и еще забыл сказать - массовое удаление ведет к массовому возникновению фантомных записей: запись числится удаленной но место занимает - такая ситуация ведет к снижению производительности операций выборок типа SCAN (просмотр).

Anikrion; Albert_2008; Niberu; ser6702; MarchTomCat; olezhe; user598655_ilia-bers; klaus38; LordKim; lmnlmn; spenser123; Monte Carlo; acanta; zaharknyaz; Aggressorak; vesd; Ilya$n; Waanneek; SkyJack; letarch; aegoncharov; user777757; [email protected]; mytg; Gang031; ice-net; Goga1979; ChessCat; RegrZ; 1cprogr_nsk; Irwin; Paradise.87; KAV2; корум; Roman100; for_questions; ragimi; EugeneMIPT; kai nk; kitaevay; crosby; Noxie41; Alex_grem; nixel; new_user; tdml; NeviD; RimidalV; reboot; denis_aka_wolf; Flashill; marchenko.y; freya-khv; asg.aleks; denis13; adm134; TIS_08; mtv:); soulsteps; shalimski; Anesk; pisarevEV; Silenser; kwazi; engineer74; vadimlp77; Артано; dgolovanov; pchela751; aexeel; artbear; jif; Dmitryiv; Rego1337h; slavap; WizaXxX; IvanBoychuk123; fishca; Evil Beaver; Dach; RodinMax; sanches; mdmdvd; zakakvo; Krio2; jacksonp; adeich; afedor; MaximStav; DoctorRoza; Serg0FFan; sanfoto; kinazarov; Bukaska; theshadowco; oitnur; JesteR; detec; audion; laeg; morok1983; krv2k; Di-dog; sparklemal; awa; KAPACEB.AA; Chif13; sa1m0nn; CratosX; AllexSoft; galich; vlad.frost; igorynets; tormozit; vasiliy_b; vladir; meuses; Poopkeen; Andreynikus; Prad2002; dicwork; JohnyDeath; An-Aleksey; It-developer; rgrisha; Bronislav; 7o2uYXg; HolodZar; адуырщдв; AzagTot; Рамзес; DenisCh; PONOM; rеd80; w-divin; metmetmet; CheBurator; PressaLod; Diversus; sevushka; Aleksey.Bochkov; yuraos;

В этой статье мы рассмотрим данную системную утилиту «Тестирование и исправление информационной базы» в 1С 8.3 и особенности её использования.

Перед проведением любых операций необходимо !

Тестирование и исправление информационной базы 1С

Режим тестирования и исправления вызывается в конфигураторе системы 1С 8.3 выбором меню Администрирование — Тестирование и исправление.

Проверки и режимы

В этом окне указывается список необходимых проверок и режимов, которые будут произведены в результате работы утилиты. Рассмотрим каждую галочку подробнее:

Получите 267 видеоуроков по 1С бесплатно:

• Реиндексация таблиц информационной базы — если установлен этот флаг, будет произведена реиндексация таблиц. Реиндексация — полное перестроение индексов для заданных таблиц. Реиндексация существенно повышает производительность системы в целом. Данная процедура никогда не будет лишней и увеличивает производительность системы.
• Проверка логической целостности информационной базы — система умеет проверять логическую и структурную целостность базы данных, находить ошибки в организации данных (например, страниц в файле).
• Проверка ссылочной целостности информационной базы — подпункт логической проверки, проверяет информацию в базе данных на наличие «битых» ссылок. «Битые» ссылки появляются в базе из-за некорректной обработки информации разработчиком, чаще всего при непосредственном удалении данных или неправильно настроенном обмене данных. При нахождении ошибок можно выбрать 3 варианта действий: Создавать объекты — система создает элементы-заглушки, которые можно потом заполнить необходимой информацией, Очищать ссылки — «битые» ссылки будут очищены, Не изменять — система только покажет Вам ошибки.
• Пересчет итогов — в платформе 1С в и есть понятие итогов. Итоги — таблица подсчитанных результатов, данные из которой получить быстрее, чем анализировать весь регистр сведений. Как правило, пересчет итогов увеличивает производительность системы.
• Сжатие таблиц информационной базы — если установлен этот флаг, будет сжата и уменьшится в объеме. Связанно это с тем, что при удалении данных из базы данных, 1С не удаляет физически эти объекты, а лишь «помечает» их на удаление. Т.е. пользователь не видит их, а они есть:). Вот именно сжатие базы данных и удаляет такие записи окончательно. Также такого эффекта можно достичь выгрузкой и загрузкой файла базы данных (*.dt).
• Реструктуризация таблиц информационной базы — процесс, с помощью которого система осуществляет пересоздание таблиц баз данных, обычно эта процедура вызывается при внесения изменений в структуру метаданных конфигурации. Реструктуризация всей БД — процесс долгий, будьте внимательны.

Если по каким-то причинам тестирование и исправление не помогает или у вас нет доступа в конфигуратор, воспользуйтесь утилитой .