Реструктуризация базы 1с что означает

Оптимизация реструктуризации базы данных

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.

Мы разработали новый механизм реструктуризации базы данных, который позволяет ускорить обновление конфигурации в среднем в 3-4 раза, а в отдельных случаях на порядки. Ускорение достигается за счёт минимизации манипуляций над данными и максимального их переноса на уровень системы управления базой данных (СУБД).

Что такое реструктуризация?

Реструктуризация это изменение структуры и состава таблиц базы данных, и перенос имеющихся данных в изменённые таблицы. Обычно реструктуризация выполняется в тот момент, когда вы нажимаете Обновить конфигурацию базы данных в Конфигураторе. Но выполняется она не каждый раз.

Реструктуризация выполняется тогда, когда изменения конфигурации требуют появления новых колонок или таблиц в базе, или когда меняется тип существующей колонки. Например, вы добавили реквизит к справочнику, добавили документ, или изменили тип имеющегося реквизита с Число на Строка. В этих случаях потребуется реструктуризация.

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

«Традиционная» реструктуризация

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

Анализ его изменений;
Создание новых таблиц в базе данных, которые соответствуют новой структуре объекта;
Перенос данных.

Из этих трёх шагов перенос данных занимает наибольшее количество времени. При этом сами операции переноса данных могут быть простыми и сложными.

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

Все остальные операции являются сложными, могут занимать длительное время, и для их выполнения требуется участие Конфигуратора (или серверной части платформы, если обновление выполняется на сервере). Потому что процесс переноса данных может сопровождаться различными вспомогательными действиями, обусловленными спецификой 1С:Предприятия.

Например, может потребоваться удаление ссылок на несуществующие объекты, изменение предопределённых данных, предварительная фильтрация данных (для удаления движений, соответствующих удаляемым регистраторам), проверка уникальности номеров и кодов, проверка количества уровней вложенности справочника и корректности его иерархии, и другие.

Новый механизм реструктуризации

Главное изменение заключается в том, что оптимизация реструктуризации достигнута не за счёт локальных изменений «традиционного» механизма, а за счёт создания полностью нового механизма реструктуризации.

Это непростая и трудоёмкая задача, потому что механизм реструктуризации должен обеспечивать транзакционность изменений, то есть надежность и целостность базы данных во всех случаях. Механизм должен быть готов к тому, что процесс реструктуризации может прерваться в любой момент (в результате сбоя, например), и при этом система должна остаться в консистентном состоянии. То есть либо в виде старой версии, либо в виде новой версии. Старый механизм для этого создавал новые версии изменённых таблиц, и заполнял их. А потом подменял все старые версии на новые.

Новый механизм тоже обеспечивает транзакционность, но более сложным способом.

Кроме этого новый механизм основан на ряде идей, которые позволили получить значительное ускорение:

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

На основе этих идей мы достигли максимальной оптимизации на тех изменениях конфигурации, которые приводят к следующим операциям с данными:

Добавление или удаление столбцов таблиц. Эти операции проводятся теперь на текущих таблицах (раньше создавались новые таблицы и в них переносились данные). Необходимость добавления или удаления столбцов возникает, например, при добавлении или удалении реквизитов, при изменении некоторых свойств объекта конфигурации (иерархия справочника и столбец _ParentID) и др.
Добавление или удаление индексов. Просто создаётся новый индекс, без создания новых таблиц и переноса данных. Эти операции выполняются, если вы установили индексирование у реквизита, например.
Изменение существующих индексов. Также выполняется без создания таблиц и переноса данных. Например, кластерный индекс регистра сведений меняется тогда, когда вы добавляете измерение.

В других операциях перенос данных требуется как и раньше, но практически всегда (в большей части операций) он осуществляется на уровне СУБД. Данные переносятся единым запросом. Это может быть INSERT для новых таблиц, или UPDATE существующих таблиц.

Конечно, существуют такие изменения, которые всё равно проходят обработку на сервере с выгрузкой данных построчно. Например, преобразование строки в число, или в дату. Такие операции нецелесообразно делать на уровне СУБД, к тому же они довольно редко встречаются. Но наиболее частые изменения проводятся всё же на уровне СУБД, одним запросом на одну таблицу.

В среднем ускорение достигает 4 раз. Это, конечно, зависит от конкретной конфигурации, от конкретных изменений, и даже конкретных данных. В отдельных случаях ускорение может быть до 20 раз. Такое возможно, например, при удалении реквизита в большой таблице, или если изменения затрагивают маленькие таблицы, но сам объект при этом является довольно большим.

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

Мы провели несколько сравнительных экспериментов на реальных информационных базах, и получили следующие результаты:

Добавление реквизитов к документам и измерений к регистрам сведений. База 400 Гб. Новый механизм позволяет ускорить реструктуризацию с 2 часов до 15 минут.
Изменение режима совместимости с 8.2.19 на 8.3.6. База 6 Тб. Ускорение с 5 дней до 12 часов.

Особенности текущей реализации

Новый механизм реструктуризации мы планируем включить в версию 8.3.11 в статусе бета. Он реализован только на сервере, причём на сервере должна быть установлена Java 8.

Чтобы использовать новый механизм реструктуризации, вы можете запустить Конфигуратор в пакетном режиме. Кроме этого в файле conf.cfg вы также можете указать необходимость использования нового механизма. Тогда новая реструктуризация будет выполняться при нажатии Конфигурация – Конфигурация базы данных – Обновить конфигурацию базы данных на сервере. Если никаких специальных действий не предпринимать (просто установить новую платформу), то стандартно будет использоваться старый механизм.

Пока поддерживаются только две СУБД: MS SQL Server и PostgreSQL.

На текущий момент мы оптимизировали реструктуризацию не всех объектов конфигурации, а только основных:

Планов обмена,
Справочников,
Документов,
Журналов документов,
Планов видов характеристик,
Планов счетов,
Регистров сведений,
Регистров накопления,
Регистров бухгалтерии.

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

Мы рассматриваем возможность увеличения охвата операций и расширения состава объектов конфигурации, реструктуризация которых оптимизирована в новом механизме.

Ускорение реструктуризации таблиц

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

Итак. Программисты 80lvl скорее всего знают все и даже больше, чем описано в статье, поэтому эта публикация будет ориентирована в первую очередь на новичков. А так как у новичка скорее всего ни репутации и стартмани — все скрипты я не буду прикреплять, а выложу в статье.

Поехали. Предположим в вашей конфигурации есть некий документ, с 5 табличными частями. В СУБД (в нашем примере PosgreSQL, но все ниже сказанное справедливо и других СУБД) такой документ предстанет в виде 6 таблиц

Предположим вам необходимо добавить реквизит в табличную часть _document39_vt415, узнать какая именно табличная часть можно либо специальными обработками, либо просто посмотрев несколько записей из таблицы в самой СУБД. Что произойдет далее, точнее что сделает платформа 1С, она создаст копии всех 6 (!) таблиц документа и начнет копирование в них данных из старых таблиц — начнется реструктуризация. Процесс этот, мягко говоря, не быстрый. Почему я вообще пишу эту статью, потому что в моем случаи: количество документов (записей в _document39 было 1М) и записей в табличных частях 25М, процесс реструктуризации документа средствами 1С занял 48 часов. Так вот мы попытаемся обмануть платформу.

Продолжаем, добавляем реквизит в табличную часть в конфигураторе, у меня это число длинной 10, точность 0 (во время всех манипуляций его можно не закрывать), сохраняем, но не обновляем. Переименовываем все таблицы документа в pgAdmin или чем вы там пользуетесь (у меня это пара pgAdmin и EMS SQL Manager PostgreSQL), например _document39 в _document39_src

И создаем копии наших переименованных таблиц (пустые) с первоначальными именами, в нашем примере делаем пустую копию _document39_src с именем _document39.

Копии я создавал в EMS SQL Manager лишь потому, что в нем это проще, но можно и в pgAdmin. В нем надо в контекстном меню таблицы выбрать Скрипты — CREATE и в окне SQL редактора изменить имя таблицы на новое.

Если посмотреть в предприятии, у нас нет ни одного документа.

Теперь, когда 1С считает, что у нас нет документов, в конфигураторе жмем обновить, реструктуризация проходить мгновенно (если возникнут ошибки, жмем обновить еще раз, до тех пор, пока не появится окно о принятии изменений).

Смотрим какое имя получила новая колонка таблицы, которая соответствует новому реквизиту.

У меня это _fld1097. Возвращаемся к нашей исходной таблице, которую мы переименовали в _document39_src, добавляем новую колонку в нее

Ставим значение по умолчанию, здесь 0 и жмем ОК. Весь процесс занял около 1 часа (в 48 раз быстрее). После того как колонка создана, стираем значение по умолчанию и переименовываем таблицу обратно (у нас в _document39)

Запускаем предприятие и проверяем. Радуемся или плачем.

Итак, это мы добавили реквизит, рассмотрим теперь случай, если нам надо изменить тип реквизита, например, было число (5, 2), надо число (10, 4), или добавить индексов.

Тут есть два варианта.

Вариант первый. Создаем копии таблиц и заливаем в них данные из основной таблицы

SELECT * INTO _document39_copy FROM _document39; SELECT * INTO _document39_vt415_copy FROM _document39_vt415; SELECT * INTO _document39_vt431_copy FROM _document39_vt431; SELECT * INTO _document39_vt434_copy FROM _document39_vt434; SELECT * INTO _document39_vt437_copy FROM _document39_vt437; SELECT * INTO _document39_vt444_copy FROM _document39_vt444;

После этого очищаем исходные таблицы, т.е. доходим до момента, когда 1С думает, что у нас нет записей в таблицах документ. Делаем все необходимые изменения в конфигураторе и обновляем. Теперь нам надо вернуть данные назад

NSERT INTO _document39( _idrref, _version, _marked, _date_time, _numberpfix, _number, _posted, _fld556, _fld392rref, _fld393rref, _fld394, _fld395, _fld579, _fld396, _fld397, _fld398rref, _fld399, _fld400, _fld401rref, _fld1018rref, _fld403, _fld402rref, _fld404rref, _fld405, _fld538rref, _fld406, _fld407, _fld408rref, _fld409rref, _fld410rref, _fld411rref, _fld412rref, _fld413, _fld414) select * from _document39_copy; —

60min (1.5 M records) INSERT INTO _document39_vt431( _document39_idrref, _keyfield, _lineno432, _fld433rref) select * from _document39_vt431_copy; INSERT INTO _document39_vt434( _document39_idrref, _keyfield, _lineno435, _fld436rref) select * from _document39_vt434_copy; INSERT INTO _document39_vt437( _document39_idrref, _keyfield, _lineno438, _fld439rref, _fld440rref, _fld441, _fld442rref) select * from _document39_vt437_copy; INSERT INTO _document39_vt444( _document39_idrref, _keyfield, _lineno445, _fld446rref) select * from _document39_vt444_copy; —3 min INSERT INTO _document39_vt415( _document39_idrref, _keyfield, _lineno416, _fld426rref, _fld423, _fld419rref, _fld421, _fld420, _fld536, _fld425, _fld418, _fld422, _fld428rref, _fld427rref, _fld417rref, _fld429, _fld424) select * from _document39_vt415_copy; —16588297 строк, 18.5 h

Запускаем предприятие и проверяем. Радуемся или плачем.

Вариант второй. Кто-то считает, что INSERT INTO работает медленно, поэтому можно использовать следующие скрипты, работающие не с копиями таблицы а с файлами на диске

COPY BINARY _document39 TO ‘e:/_document39’; COPY BINARY _document39_vt431 TO ‘e:/_document39_vt431’; COPY BINARY _document39_vt434 TO ‘e:/_document39_vt434’; COPY BINARY _document39_vt437 TO ‘e:/_document39_vt437’; COPY BINARY _document39_vt444 TO ‘e:/_document39_vt444’; COPY BINARY _document39_vt415 TO ‘e:/_document39_vt415’;

где ‘e:/_document39’ это файл в корне диска е.

Скрипт загружающий данные обратно

COPY BINARY _document39 FROM ‘e:/_document39’; COPY BINARY _document39_vt431 FROM ‘e:/_document39_vt431’; COPY BINARY _document39_vt434 FROM ‘e:/_document39_vt434’; COPY BINARY _document39_vt437 FROM ‘e:/_document39_vt437’; COPY BINARY _document39_vt444 FROM ‘e:/_document39_vt444’; COPY BINARY _document39_vt415 FROM ‘e:/_document39_vt415’;

На этом, пожалуй все.

Как видно, процесс это все равно долгий (около 18 часов у меня). Что мы получили, около 19 часов против 48 при изменении типа реквизита и добавлении индексов, и около 1 часа против 48 часов при добавлении реквизита.

PS. У меня есть подозрение, что на других СУБД реструктуризация средствами платформы будет быстрей. К тому же у меня стоял старый PosgresSQL, еще 8.2.4-3.1

Тестирование и исправление базы 1С 8.3

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

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

Запускаем информационную базу 1С в режиме Конфигуратор и заходим в пункт меню Администрирование — Тестирование и исправление .

Стоит помнить, что перед любыми действиями с информационной базой 1С необходимо выполнить ее резервное копирование.

В открывшемся окне несколько пунктов выбора вариантов проверки и режимов, и чтобы правильно установить параметры тестирования 1С и правильно установить галочки, нам нужно понимать суть происходящего. Рассмотрим, что означает каждый пункт и для чего он предназначен.

Тестирование базы 1С, проверка на ошибки

Реиндексация таблиц информационной базы 1С: что это

При работе с программой 1С 8.3 вся информация (заполнение справочников, создание документов и т.п.) записывается в таблицы. Кроме основных таблиц существуют вспомогательные таблицы, в которых эти данные сортируются по заданным полям, для ускорения поиска, что увеличивает быстродействие программы 1С — это таблицы индексирования.

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

Для исправления такого рода ошибок в базе 1С устанавливаем галочку Реиндексация таблиц информационной базы .

При тестировании и исправлении в 1С реиндексируются все таблицы. И хотя данный пункт занимает длительное время, он помогает решить большую часть проблем.

Проверка логической целостности информационной базы 1С

При создании новых объектов в информационной базе 1С 8.3 создаются новые таблицы, связанные с другими таблицами. Ошибки нарушающие логическую целостность могут возникнуть вследствие некорректного обновления программы 1С, выключения компьютера в момент создания или записи документа (или любого другого элемента программы), сбоя в работе сети.

При этом программа 1С может работать, но ошибка будет возникать при обращении к тому документу (или объекту) в момент создания которого произошел сбой.

При тестировании и исправлении и установке данной галочки будет произведена проверка логических ошибок в структурах таблиц информационной базы.

Проверка ссылочной целостности информационной базы 1С

В ходе работы с программой 1С могут возникнуть ссылки на несуществующие или разрушенные объекты, так называемые битые ссылки. Они могут в результате сбоя или непосредственного удаления объекта. В случае, если в ходе проверки будет такой объект найден, необходимо в настройке дополнительно галочками указать, какие действия с ним производить.

При тестировании и исправлении и обнаружении ссылок на несуществующие объекты в 1С предлагается три варианта действия — создать объект, очистить ссылку или не изменять, при обнаружении частично потерянных данных объекта — создать, удалить объект, или не изменять его. При выполнении действия:

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

Пересчет итогов

Иногда в отчетах могут отражаться неверные данные. Мы исправляем, перепроводим документы, а они не меняются… Видим цифру, открываем карточку счета — документа нет. В чем может быть проблема? Все просто — сбились итоги.

Для удобства работы в программе 1С 8.3 существуют вспомогательные таблицы, которые хранят данные об уже просчитанных итогах. Они нужны, чтобы при обращении к необходимой информации она не выбиралась из общих таблиц, а получалась из таблицы итогов. Это значительно экономит время обработки информации.

Например, данные из таблицы итогов по регистру Остатки материалов , позволяют нам быстро определить их остатки на складах на определенную дату. Установив галочку при тестировании — Пересчет итогов , будут пересчитаны итоги во всей информационной базе 1С и заново занесены в таблицы итогов.

Сжатие таблиц информационной базы 1С

При удалении объектов в информационной базе 1С (документов, справочников и т.п.) они не удаляются физически, эти записи остаются в таблицах, но пользователь их не видит. В результате накопления таких объектов, увеличивается объем информационной базы 1С, что приводит к замедлению работы.

Сжатие таблиц в 1С 8.3 — это физическое удаление записей, которые ранее были помечены на удаление и удалены из программы, информация о них удаляется полностью из информационной базы, в результате таблицы базы становятся меньше. Такого же эффекта можно достичь путем выгрузки и загрузки файла информационной базы через Конфигуратор (*.dt).

Реструктуризация таблиц информационной базы 1С

Это создание заново структуры информационной базы, создание новых таблиц, и перенос старых данных в новые таблицы. Реструктуризация также происходит при обновлении информационной базы. В результате этих действий также возможно исправление некоторого рода ошибок программы 1С.

Обращаем внимание на переключатель, который задает что делать при тестировании — выполнять Только тестирование (в этом случае будет выведена только информация об ошибках) или Тестирование и исправление ошибок .

После установки параметров тестирования, нажимаем кнопку Выполнить и ждем результат.

В строке состояния отображается информация о ходе тестирования.

По окончании тестирования 1С будет выведена информация об ошибках и их исправлении.

Если в ходе тестирования возникли какие то проблемы, можно восстановить информационную базу из резервной копии, созданной до начала тестирования.

См. также:

Если Вы еще не являетесь подписчиком системы БухЭксперт8:

Активировать демо-доступ бесплатно →

или

Оформить подписку на Рубрикатор →

После оформления подписки вам станут доступны все материалы по 1С Бухгалтерия, записи поддерживающих эфиров и вы сможете задавать любые вопросы по 1С.

Помогла статья?

Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно

Обсуждение (3)

В какой последовательности лучше выставлять режимы проверки? Ведь устанавливать все флаги сразу не совсем правильное решение?