1с обновить конфигурацию базы данных на сервере
Программные продукты 1С технически состоят из двух частей:
- Программная платформа — 1С:Предприятие 8.1, 1С:Предприятие 8.2, 1С:Предприятие 8.3
- Прикладные конфигурации — 1С:Бухгалтерия, 1С:Управление торговлей и пр.
Регулярные обновления выпускаются фирмой 1С для обоих частей, т.е. обновлению подлежат и платформа и конфигурация.
Обновления типовых конфигураций 1С и форм отчетности мы предоставляем нашим клиентам для самостоятельного применения в своих информационных базах.
Внимание! Последние версии обновлений некоторых конфигураций (в частности 1С:Бухгалтерии 3.0) требуют для своего применения версии платформы 1С:Предприятие 8.3 и не доступны для платформы версии 8.2.
Поэтому перед применением обновления информационную базу необходимо перевести на использование платформы 1С:Предприятие 8.3. Данная процедура описана в инструкции по переводу информационной базы на платформу 1С:Предприятие 8.3.
Перед обновлением конфигурации
Создание резервной копии
Резервную копию можно создать одним из следующих способов:
- Вариант А) Простым копированием файла 1СV8.1CD в отдельный каталог.
- Вариант Б) Используя режим выгрузки информационной базы. Для этого:
- запустите 1С:Предприятие в режиме «Конфигуратор»;
- в меню «Администрирование» выберите пункт «Выгрузить информационную базу»;
- в открывшемся диалоге укажите имя файла, в который будут записаны данные.
Остановка регламентных и фоновых заданий
Во время обновления конфигурации не должны выполняться регламентные и фоновые задания.
Если в базе существуют задания, выполняемые по расписанию, необходимо запретить их выполнение на время обновления конфигурации. Для этого нужно завершить работу программы - планировщика заданий.
Если в конфигурации выполнялись доработки, вызывающие запуск фоновых заданий, следует запретить их выполнение на время обновления конфигурации.
После обновления конфигурации выполнение заданий можно вновь разрешить.
Обновление конфигурации
Запустите 1С:Предприятие 8:
Откройте вашу информационную базу в режиме Конфигуратора (режим Конфигуратора доступен пользователю 1С с полными правами доступа).
В интерфейсе конфигуратора необходимо открыть конфигурацию вашей базы. Для этого используйте пункт меню "Конфигурация → Открыть конфигурацию".
Для запуска процедуры обновления конфигурации используйте пункт меню "Конфигурация → Поддержка → Обновить конфигурацию".
В открывшемся диалоге обновления конфигурации выберите пункт "Поиск доступных обновлений" и нажмите кнопку "Далее".
На следующем экране снимите галку с пункта "Искать обновления в каталоге" (должен остаться выбранным только пункт "Искать в текущих каталогах шаблонов и обновлений") и нажмите кнопку "Далее".
В списке доступных обновлений выберите нужное вам и нажмите "Готово".
На экране с описанием обновления нажмите кнопку "Продолжить обновление".
На следующем экране окончательно подтвердите запуск процедуры обновления, нажав на кнопку "ОК". Начавшийся процесс обновления конфигурации может занять несколько минут.
После окончания обновления конфигурации появится диалог подтверждения обновления базы данных. Для обновления вашей информационной базы нажмите кнопку "Да".
После обновления необходимо открыть вашу базу в обычном режиме использования (режим 1С:Предприятие) от лица пользователя 1С с полными правами. Вам будет предложено прочитать условия распространения обновлений программ 1С:Предприятие. Для начала работы выберите пункт "Я подтверждаю легальность получения обновления в соответствии с вышеизложенными условиями" и нажмите кнопку "Продолжить".
Любите ли Вы динамическое обновление конфигураций так, как люблю его я? Обожаю что-нибудь с его помощью пропатчить на продакшене! Особенно в пятницу! Вечером! Перед майскими праздниками! Без предупреждения!
На самом деле нет! Динамическое обновление с одной стороны выглядит отличным механизмом платформы 1С, который позволяет вносить изменения в конфигурации "на лету". Главное, чтобы изменения не затрагивали структуру базы данных, в противном случае придется выполнять обновление монопольно и "выгонять" пользователей.
Согласитесь, при появлении ошибки в коде после очередных изменений просто берешь и обновляешь базу "на горячую" и никаких проблем! Главное всем, кому нужны были эти изменения, перезапустили сеанс и изменения вступят в силу!
С другой стороны может что-то пойти не так и Вы найдете небольшую, но весомую порцию багов у себя.
И никакие отговорки, что это были изменения для ТОП-менеджеров Вам не помогут!
Но как же так! Вы пользуетесь динамическим обновлением и у Вас нет никаких проблем? Коллеги рассказывают страшные истории, но Вы им не верите? "Просто они плохие 1Сники!", думаете Вы?
Как работает динамическое обновление
Наверное это странный вопрос, ведь ответ лежит на поверхности - это механизм позволяет обновить конфигурацию базы данных без остановки ее работы, внося изменения не требующие модификации на уровне базы данных. В официальной документации на ИТС есть информация в каких случаях платформа позволяет провести динамическое обновление. Вроде все просто. Но что если пойти дальше.
В любой информационной базе есть таблицы "Config" и "ConfigSave". Назначение этих таблиц также известно:
- Config - содержит основную конфигурацию информационной базы, которая соответствует актуальной структуре базы данных и используется активными сеансами.
- ConfigSave - содержит сохраненную конфигурацию. Ту самую, которую Вы редактируете в конфигураторе. Как только Вы нажимаете "Сохранить", все измененные объекты и связанная информация записывается именно сюда. После запуска обновления информационной базы все изменения из этой таблицы переносятся в таблицу Config. Если же выполнить команду "Конфигурация -> Конфигурация базы данных -> Вернуться к конфигурации БД", то вся информация об изменениях в этой таблице удалится.
Все просто, не так ли? Но пойдем еще дальше. Посмотрите на структуру таблиц для хранения данных конфигурации.
Структура таблиц идентична.
Описание полей такое:
- FileName - строка длиной 128, используется для хранения имени "файла", это некоторая часть конфигурации.
- Creation - дата создания записи.
- Modified - дата модификации записи.
- Attributes - целое число, назначение которого сейчас нет смысла рассматривать (на самом деле я точно не могу утверждать, только предполагаю зачем оно нужно. Но если Вы знаете, то напишите в комментариях).
- DataSize - размер данных в байтах, хранящийся в поле "BinaryData"
- BinaryData - непосредственно данные конфигурации.
- PartNo - номер части. Иногда размер данных объекта метаданных может быть очень большим и платформа его разбивает на части.
То есть конфигурация хранится некоторыми блоками. Вообще, структура хранения конфигурации в таблице базы соответствует тому, как устроена внутренняя структура форматом файлов CF. Подробнее об этом Вы можете узнать в отличной статье "Описание формата файлов конфигурации (CF, EPF, ERF)" от Андрея Овсянкина.
Со структурой таблиц и их назначением понятно. Пойдем дальше.
Когда Вы начинаете процесс обновления информационной базы, на первом этапе платформа 1С выполняет множество служебных действий, останавливаться на которых сейчас особо нет смысла. Самое интересное начинается после того, как Вы нажимаете заветную кнопку "Обновить динамически".
Среди множества служебных действий, платформа переносит данные об объектах из таблицы ConfigSave в Config:
В следующий раз, когда информационная база будет обновляться в обычном режиме, записи об объектам, созданных при динамическом обновлении, будут удалены и останутся только основные записи с актуальными данными конфигурации.
Это очень поверхностное описание и сам процесс имеет множество особенностей как со стороны работы БД, так и со стороны работы клиентских приложений платформы 1С. Но суть должна быть понятной.
Подробный пример динамического обновления
Для того, чтобы детальней погрузиться в происходящее при таком обновлении, рассмотрим все действия платформы 1С, до которых можно добраться законым способом. То есть мы не будем влазить в модули работы самой платформы и открывать то, за что можно получить повестку в суд. Мы лишь посмотрим что делает платформа на стороне базы данных. И этого нам будет достаточно!
В нашем примере есть некоторая конфигурация на базе БСП (хотя это и не важно), в которой добавлен очень важный общий модуль "ДляДинамическогоОбновления".
Модуль полностью клиентский, имеет в своем составе только одну функцию.
На первом шаге мы вносим изменения в модуль и нажимаем "Сохранить конфигурацию". При этом изменения в конфигурации сохранены, но не применены к информационной базе.
На этом шаге платформа 1С делает записи в таблицу "ConfigSave", некоторое промежуточное хранилище, из котого потом измененные элементы конфигурации должны будут перенесены в основную таблицу конфигурации "Config".
Вот вся история операций в таблице "ConfigSave" после сохранения конфигурации. Здесь подробная информация обо всех действия практически на физическом уровне, поэтому некоторые операции "INSERT" разделены на две (INSERT и UPDATE), а операция UPDATE может быть выделена как операции DELETE и INSERT. Но эти особенности сейчас не играют роли.
Кроме этого в таблице есть дата операции (Period) и идентификатор транзакции (__$start_lsn). По факту все эти действия выполняются в разных транзакциях, лишь некоторые из действий в таблице выполняются в единой транзакции.
Вся операция, как уже упоминалось выше, делится на два этапа:
- Записываем в таблицу информацию об изменениях конфигурации , в частности нашего общего модуля "ДляДинамическогоОбновления". Кстати, на скрине выше видно, что его идентификатор "cb327a01-e9cc-44e6-af31-5f30c88faeca", отсюда и эти названия похожие. Имена содержат суффикс "new", что говорит о промежуточной записи объектов.
- На следующем шаге промежуточные записи преобразовываем в нормальные , просто исключив "new" из имен элементов конфигурации.
Тут все достаточно просто, идем к следующему шагу. Вы нажимаете кнопку "Обновить информационную базу", но так как в базе есть сеансы, а изменения касаются только модулей, то платформа 1С предлагает выполнить динамическое обновление без завершения сеансов.
В этот момент платформа 1С сделала два действия:
- Скопировала записи из таблицы "ConfigSave" в таблицу "Config" с суффиксом "new", почти все действия выполнены в одной транзакции.
- Затем было обнаружено, что обновление невозможно продолжить из-за наличия активных сеансов. Был показан диалог для динамического обновления, а ранее добавленные записи удалены из таблицы "Config" в одной транзакции.
Изменений в таблице "ConfigSave" в этот момент не выполнялось.
И вот мы добрались до последнего шага - запуска динамического обновления. Соглашаемся с этой операцией и получаем следующее.
- В таблице "Config" сначала добавляются новые записи с суффиком "new" для последующих операций с ними. Примерно такие же действия мы видели в самом начале в таблице "Config", перед тем как было предложено выполнение динамического обновления. Но в этот раз также сделаны служебные записи "commit", "dynamicCommit" и "dbStruFinal", которые относятся непосредственно к динамическому обновлению (частично о них было упомянуто выше).
- Предварительные записи с суффиксом "new" теперь платформа преобразовывает в нормальные записи, также добавляет записи с форматом "_dynupdate_", плюс вставляет флаг динамического обновления "DynamicallyUpdated".
- Из таблицы "ConfigSave" удалены все сохраненные ранее записи. Все в одной транзакции.
- И напоследок из таблицы "Config" удаляются служебные данные "commit", "dynamicCommit" и "dbStruFinal".
Заметьте, каждый этап - почти всегда разные транзакции, это важно.
После этого конфигурация успешно обновлена динамически, база работает. Чтобы клиентам получить новые изменения достаточно перезапустить сеанс. Вроде все хорошо.
На самом деле это не все действия платформы 1С, т.к. еще обновляются данные в таблице "Params" и некоторые другие. Но мы это рассматривать сейчас не будем.
Разработчики ликуют и со словами "Я же говорил" продолжают убеждать коллег, что динамическое обновление это нормально!
Что может пойти не так
Весь процесс динамического обновления мы рассмотрели, но что же может случиться?
Представим простую ситуацию: что, если все обновление прошло успешно, кроме последнего этапа? Например, во время выполнения запросов на удаление служебных данных соединение с базой данных почему-то "отпало":
- Сбой сети.
- Регламентные работы на сервере, внезапно.
- Обслуживание базы, которое завершило блокирующий сеанс, опять же внезапно!
- Конфигуратор вылетел из-за ошибки внутренней.
- Разработчик 1С был странным и завершил сеанс конфигуратора во время обновления.
- И еще сотни причин, которые лень добавлять.
Чтобы такое проще было представить, можно добавить в базу данных триггер, который при попытке удаления служебной записи о динамическом обновлении упадет в ошибку.
Попытаемся теперь выполнить динамическое обновление и столкнемся с ошибками:
- Сначала во время обновления в конфигураторе поймаем ошибку.
- А при попытке зайти в конфигуратор повторно мы словим ошибку.
- При попытке повторить обновление мы уйдем в бесконечную ошибку вида.
Все, конфигуратор нам больше недоступен! Чистите кэш, пытайтесь выполнить обновление ИБ, удаляйте сеансовые данные! Все бесполезно! Можете еще взять бубен, но и он бесполезен!
После этого проблема будет полностью исправлена в 99% случаев.
И это все?
Такая ошибка вас не остановит? Говорите, что ну и ладно, что в конфигуратор не вошли, зато клиенты работают, а с конфигуратором бы разобрались? Ведь решения есть на просторах интернета!
Хорошо, а как вам такой же "обрыв" соединения на этапе обновления данных в таблице "Params". Сделаем другой триггер (отключите только предыдущий):
При попытке обновления записи "DynamicallyUpdated" в таблице "Params" мы получим падение. Конфигуратор закроется системной ошибкой. Не страшно, скажите Вы! Но в этот же момент все клиентские соединения также вылетят, причем с разными ошибками. Например, с такой.
А при попытке перезапустить клиентский сеанс, также будут происходить различные ошибки. Никто не сможет работать с информационной базой!
Но и тут не все потеряно!
Клиентские сеансы не могут зайти в базу, их всех выкинуло и так далее! Но мы все еще можем в большинстве (но не во всех) случаев зайти в конфигуратор! И при повторном обновлении также в большинстве (но не во всех) случаях мы восстановим работу информационной базы!
Итог, все вылетели из базы, мы словили адреналина, и восстановили работу после штатного повторного обновления. Вас и это не убедило, что динамическое обновление очень опасно?
Вы поистине яркий человек
Если Вам и этого мало, то как Вы думаете, что будет, если оба этих случая будут комбинированы? В этом случае Вы "выкинете" всех пользователей из информационной базы, а потом еще и не сможете войти в конфигуратор повторно. Пойдете после этого вручную очищать таблицу "Config" от служебны записей динамического обновления и надеяться, что это в этот раз поможет.
Вы удивительный человек!
А ведь есть еще проблемы другого рода:
- Повреждение сеансовых данных сервера. Возникают из-за какого-то особого поведения платформы 1С, меняется от релиза к релизу, сложно прогнозируемые и сложновоспроизводимые ошибки.
- Повреждение клиентского кэша, которое приводит к:
- Ошибкам запуска клиентского приложения при входе в информационную базу
- Случайным ошибкам во время работы приложения, таким как "Тип неопределен" или подобные.
Ниже есть ссылки на примеры различных проблем и их решение. Для воспроизведения таких проблем мне пришлось бы откопать код приложений платформы 1С, но это не очень правильно.
Это весело
Вы все еще считаете, что динамическое обновление это хорошо? Что нет ни единой причины, чтобы отказаться от него? Что все описанные ошибки, которые даже можно воспроизвести прямо на свежих версиях платформы (от 8.0 до 8.3.20), не являются критичными? Может вы еще и бэкапы не делаете?
Кстати, описанные выше проблемы аткуальный как для платформы 1С версии 8.0, так и для всех более новых версий, вплоть до 8.3.20.*. И это только вершина айсберга!
Надеюсь, информация из статьи поможет кому-то хотя бы задуматься над тем, что Вы делаете!
P.S. А Вы задумывались над тем, что установка расширений тоже может приводить к подобным проблемам? :)
Произвольная таблица (регистр, документ, справочник) в произвольной базе данных 1С, 100 млн строк, 60 Гб места на жестких дисках.
Требуется:
1. Добавить 1 произвольный реквизит (измерение).
2. Добавить индекс по уже существующему реквизиту (измерению).
3. Удалить 1 или несколько существующих реквизитов (измерений).
В режиме обычного обновления платформа по каждому из этих пунктов будет действовать следующим образом:
- создание копии исходной таблицы с новой структурой колонок;
- select из старой таблицы insert в новую;
- переименование новой таблицы, truncate старой таблицы.
И все это в транзакции.
Понятно, что для таких действий со 100 млн строк потребуется безумно много времени и весьма немало места.
Наш любимый вендор 1С наконец-таки пошел навстречу крупным компаниям, использующим платформу для промышленных решений и серьезной автоматизации. Начиная с версии 8.3.11 появился новый механизм реструктуризации, более "интеллектуальный", чем описанный выше.
Как он отработает?
1. Для любой таблицы будет выполнена инструкция alter table. Выполняется мгновенно. Без копирования строк из старой таблицы в новую. Будет добавлена колонка в таблицу БД с указанным Вами типом. Если тип, к примеру, ссылочный - значение колонки во всех строках будет вида "ПустаяСсылка" (16-ричное число 0x00000000000000000000000000000000).
2. Для добавления индекса сразу будет запущена инструкция create index. Без копирования строк из старой таблицы в новую. Если индексов несколько - команды create выполняются параллельно. На таблице 100 млн строк индексы по 3 реквизитам добавились за 30 минут (реальный живой тест не на самом мощном ПК с обычным жестким диском, не SSD).
3. В случае с реквизитом будет также выполнена инструкция alter. А вот в случае с удалением измерения из регистра накопления (например) - все несколько сложнее. Платформе придется выполнить "свертку" (group by) по новому составу измерений и записать новые данные в новую таблицу. Также это вызовет и перезапись таблицы итогов.
Таким образом, за счет устранения копирования строк из старой таблицы в новую достигнут существенный прирост скорости обновления больших таблиц.
1. Таблица табличной части документа, 80 млн строк, добавлены индексы по 3-м реквизитам ТЧ. Отработало за 35 минут.
2. Таблица периодического регистра сведений (ЦеныНоменклатуры), у 3-х измерений установлено свойство "ведущее". 100 млн. строк. Индексы построились за 1 час 20 минут.
При всех операциях лог-файл "распухал" вполне прогнозируемо относительно исходного размера таблицы в мегабайтах.
Как запустить обновление в новом режиме?
2. На сервере БД 1С, для службы агента sql обязательно должны быть разрешены подключения по TCP/IP (настраивается в диспетчере конфигурации SQL). Драйвер JDBC использует подключение tcp/ip для выполнения запросов t-sql.
3.1 Пакетный запуск
Текст скрипта для PowerShell (файлы .ps1)
Start-Sleep -Seconds 3
Get-WMIObject Win32_Process|where|%Start-Sleep -Seconds 1
Start-Process -FilePath "C:\Program Files (x86)\1cv8\8.3.12.1529\bin\1cv8.exe" -ArgumentList " CONFIG /S localhost\bd_test /N UpdateRobot /P 123456 /UC 123456789 /UpdateDBCfg -Server -v2 "В БД 1С должен быть создан пользователь UpdateRobot, с одной единственной ролью, с одним единственным правом доступа "Обновление конфигурации базы данных". Все остальные права доступа (администрирование, администрирование данных) - не нужны.
В таком режиме ход обновления можно отслеживать только через консоль администрирования кластера 1С и с помощью инструментов сервера БД (MS SQL Studio).
3.2 Настройка файла conf
Смотрим, что написано в файле conf
C:\Program Files (x86)\1cv8\8.3.12.1529\bin\conf
Ка правило, путь в нем указан так: ConfLocation=C:\Program Files (x86)\1cv8\conf
Правим указанный файл так, чтобы он содержал строку: UpdateDBCfg=v2
Далее, чтобы обновиться в режиме v2:
Конфигуратор - конфигурация БД - обновить конфигурацию БД на сервере.
Тесты проводились: платформа 8.3.12.1529 (клиент-сервер, 32 бит), сервер БД MS SQL 2012.
Буквально недавно в нашей организации таким образом было успешно обновлено 14 баз данных 1С размером от 500 Гб до 1 Тб.
ВАЖНО (выдержка с ИТС):
"2-я версия механизма реструктуризации работает только для клиент-серверного варианта работы информационной базы в том случае, если в качестве СУБД используется Microsoft SQL Server или PostgreSQL. Если планируется использование 2-й версии механизма реструктуризации совместно с СУБД Microsoft SQL Server, то сервер «1С:Предприятия» для соединения с СУБД должен использовать сетевой протокол TCP/IP (в терминах СУБД). Работа 2-й версии механизма реструктуризации не поддерживается в том случае, если сервер «1С:Предприятия» подключается к СУБД Microsoft SQL Server с использованием сетевых протоколов Разделяемая память или Именованные каналы."
UPD 14.06.2019
ВАЖНО: Если обновление по v2 падает с ошибкой - одна из причин может быть в том, что в вашей БД есть индексы, отличные от стандартных платформенных (добавленные вручную) - их необходимо физически удалить (именно удалить, а не отключить) перед запуском обновления.
UPD 10.09.2019
Если обновление v2 падает с ошибкой вида:
При работе механизма реструктуризации второй версии возникла ошибка. Код возврата: 1. Операция: prepare.
одна из возможных причин может быть следующей:
- вы добавили реквизит в документ/справочник/регистр и после добавления отсортировали список реквизитов по имени/синониму;
В этом случае java падает в зацикливание. Решение: сначала просто добавить реквизит, выполнить реструктуризацию по v2, затем уже отсортировать реквизиты и выполнить обновление по v1.
UPD 13.04.2022
На свежих релизах платформы (начиная с какой версии - не подскажу, не проверял, но точно старше 8.3.12) для включения настройки обновления v2 нужно редактировать "клиентский" conf.cfg, то есть файл на ПК, где физически открыт конфигуратор.
Специальные предложения
это к последнему апдейту
ВАЖНО: Если обновление по v2 падает с ошибкой - одна из причин может быть в том, что в вашей БД есть индексы, отличные от стандартных платформенных (добавленные вручную) - их необходимо физически удалить (именно удалить, а не отключить) перед запуском обновления.
(1) Ирония в том, что в старом механизме реструктуризации указание MAXDOP=0 используется по умолчанию, она добавлена в качестве опции в запросе на создание индекса.
А вот в новом механизме, который описан в данной статье, разработчики почему-то забыли эту опцию включить в запрос и если в настройках сервера MAXDOP равен 1, то реструктуризация будет медленнее чем хотелось бы . Возможно следует в статье 4-м пунктом добавить, что включение на сервере MAXDOP=0 на время реструктуризации, дополнительно ускорит этот процесс.Двойственные чувства.
С одной стороны слава тебе Господи, наконец-то 1С сподобилась взяться за то, что куча народа ждало еще со времён 7.7. С другой стороны тут и Java, тут и Powershell… А сплясать в водолазном костюме в гамаке не надо?Somebody1; Smallrat; user790708; starik-2005; NoRazum; TeMochkiN; user774630; Glebis; Kinestetik; VitusBering; Antonov.AV; blackjack666; CodeNull; Brawler; Krio2; insurgut; manlak; memb3r; babys; sm.artem; Silenser; monkbest; Yakud3a; alest; Gang031; o.nikolaev; Ta_Da; djam_arttek; comol; Boulala; roman77; ilialin; zqzq; user747571; frkbvfnjh; LavinVladik; DrAku1a; slawanix; + 38 – Ответить
(4) аналогичные чувства. только обрадоваться хотел, но остался вопрос, почему нельзя сделать это всё прямо из платформы, по кнопке «сделать всё хорошо»?
(4) Java - это отголоски наработок по платформе 1C 8.4. Развитие этой версии идет медленно и новостей давно не слышно, но ее наработки постепенно появляются в 8.3. На Java никто писать не заставляет, а представить машину без JRE сейчас сложно. И судя по всему с Java придется дружить всё больше - EDT, сервер взаимодействия и т.д.
Powershell для примера же приведен. Там кроме команды запуска 1С с параметрами "UpdateDBCfg -Server -v2" и нет ничего, одна консольная команда. Не внешнюю же обработку для выполнения одной консольной команды писать.
представить машину с JRE при нормальном админе сейчас сложно. Я про Win конечно.
Просто Java программистов "как грязи" и 1С решили подбирать весь мусор и писать на том подо что есть программисты. На Java не пишут системное ПО нормальные люди конечно, просто C++ ника нормального попробуй найди
(21) я на java драйвера для фискальных регистраторов пишу, очень удобно, т.к. один код работает под виндой, линуксом и андроидом. Что я делаю не так? С++ я тоже умею.
(32) библиотеки работы с com/usb готовые, драйвера мои что-то типа.
@Override
public ByteBuffer getCommand() <
ByteBuffer data = ByteBuffer.allocate(12 + cashier.length() + cashierFiscalId.length());
data.order(ByteOrder.LITTLE_ENDIAN);
data.putShort((short) 2); // отчет об открытии смены
data.putShort((short) (4 + cashier.length() + 4 + cashierFiscalId.length()));
data.putShort((short) 1021);
data.putShort((short) cashier.length());
data.put(cashier.getBytes(Charset.forName("IBM866")));
data.putShort((short) 1203);
data.putShort((short) cashierFiscalId.length());
data.put(cashierFiscalId.getBytes(Charset.forName("IBM866")));setData(data);
return super.getCommand();
>(21) Ну при всей моей нелюбви к Джаве, я бы все-таки не стал называть ее мусором :) Тот же Apache Kafka на ней написан и шустр до безобразия.
(7)
Вот такое у меня сейчас. Ковыряемся. Ради спортивного интереса хочу докопаться до причин.
Да что то очень похожее.
Причем все базы кроме нужной реструктурировались новым методом нормально.
Но там было не к спеху, и я просто сделал по старинке.
Изменений очень много было, может в этом была проблема?Появилась возможность в меню Конфигурация, Конфигурация базы данных, Обновить конфигурацию базы данных на сервере. Как это работает и для чего это?
(4) Написано-то всё шикарно! Но, мля, многое не пашет. Даже из стандартного. Я уж не говорю про глючную работу конфигуратора как IDE.
(6) +1! :-))Данный пункт меню означает, что операция обновления конфигурации базы данных будет производиться полностью на сервере (имеет смысл только для клиент-серверного варианта работы ИБ).
в чем преимущества такого способа обновления (вероятно это быстрее)?
Данная возможность может использоваться для ускорения процесса обновления конфигурации БД, а также для использования в рамках распределенной ИБ: для того чтобы пользователю, не имеющему административных прав, но обладающему правом "Обновление конфигурации базы данных", дать возможность обновления конфигурации БД, после получения изменений конфигурации от корневого узла.
(11) попробовал обновить (изменил типы реквизитов) так с юзерами в базе, но при повторном входе в базу она все равно осталась не обновленной, в этом случае юзеров по любому надо выгонять
(12)а при чем тут одно к другому? ты наверное конфигурацию базы данных не обновил, но ИМХО к обновлению на сервере это имеет весьма отдаленное отношение.
Обновление конфигурации на сервере работает и на 8.1.
Посмотрите параметры пакетного режима. Есть параметр - server(12) >> в этом случае юзеров по любому надо выгонять
Ну да. А разве кто-то обещал, что обновление с реструктуризацией данных на сервере можно сделать с работающими пользователями?
А зачем вообще нужно изначально было делать обновление с клиента, чтобы к 1000-ному релизу наконец-то сделать обновление на сервере?
(23)еще раз - нет. обе конфигурации в клиент-серверном варианте хранятся на сервере базы данных (чаще всего - в МССкуле).
(21) но ведь оно еще и с файловым вариантом работать должно было изначально. :-)(22) а чем тогда отличается Обновить конфигурацию базы данных от Обновить конфигурацию базы данных на сервере?
(26) в теории понятно, а на практике (не с РБД) смысла не вижу, обновляется на сервере а потом еще и просит Обновить конфигурацию
Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле 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.
На текущий момент мы оптимизировали реструктуризацию не всех объектов конфигурации, а только основных:
- Планов обмена,
- Справочников,
- Документов,
- Журналов документов,
- Планов видов характеристик,
- Планов счетов,
- Регистров сведений,
- Регистров накопления,
- Регистров бухгалтерии.
Для перечисленных объектов (кроме регистров) оптимизированы любые их изменения. Для регистров мы оптимизировали реструктуризацию движений и реструктуризацию таблиц регистрации изменений. Операции пересчёта итогов и пересчёта срезов для регистра сведений мы пока не оптимизировали. Однако, несмотря на это, использование нового механизма уже даёт существенное ускорение всего обновления регистров в целом.
Мы рассматриваем возможность увеличения охвата операций и расширения состава объектов конфигурации, реструктуризация которых оптимизирована в новом механизме.
Читайте также: