Новый режим реструктуризации (обновление базы данных на сервере в режиме v2)
База данных - HighLoad оптимизация
Дано:
Произвольная таблица (регистр, документ, справочник) в произвольной базе данных 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 минут.
При всех операциях лог-файл "распухал" вполне прогнозируемо относительно исходного размера таблицы в мегабайтах.
Как запустить обновление в новом режиме?
1. На сервере 1С обязательно должен быть установлен runtime Java 8. Разрядность Java обязательно должна совпадать с разрядностью сервер 1С. Для 32 бит качаем 32 бит, для 64 - 64. Скачать можно здесь: https://java.com/ru/download/
2. На сервере БД 1С, для службы агента sql обязательно должны быть разрешены подключения по TCP/IP (настраивается в диспетчере конфигурации SQL). Драйвер JDBC использует подключение tcp/ip для выполнения запросов t-sql.
3.1 Пакетный запуск
Текст скрипта для PowerShell (файлы .ps1)
Start-Sleep -Seconds 3
Get-WMIObject Win32_Process|where{$_.name -eq '1cv8.exe' -and $_.getowner().user -eq $env:UserName}|%{stop-process $_.ProcessId}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
Пример:
SystemLanguage=System
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 с использованием сетевых протоколов Разделяемая память или Именованные каналы."
https://its.1c.ru/db/v8311doc#bookmark:adm:TI000000376
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, то есть файл на ПК, где физически открыт конфигуратор.
Database Compression Tool
Инструмент для свертки и сжатия баз данных 1С
Доступна демо-версия с прогнозом результата
Вступайте в нашу телеграмм-группу Инфостарт
реструктуризация обновление баз данных
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
HighLoad оптимизация Разработчик 1С 8.3 1С:ERP Управление предприятием 2 Бесплатно (free)
Использование оператора «В» для полей или данных составного типа (например, Регистратор) может приводить к неочевидным проблемам.
10.11.2025 15875 ivanov660 48
HighLoad оптимизация Разработчик 1С:Предприятие 8 1C:ERP Бесплатно (free)
Приведем примеры использования различных в динамических списках и посмотрим, почему это плохо.
18.02.2025 16481 ivanov660 39
HighLoad оптимизация Системный администратор Разработчик 1C:ERP Бесплатно (free)
Не всегда индексирование с дополнительным упорядочиванием полезно.
04.02.2025 15127 ivanov660 21
HighLoad оптимизация Разработчик Россия Бесплатно (free)
А вы знали, что сервер 1С при соединении с базой на сервере PostgreSQL самостоятельно устанавливает некоторые параметры? Это важно знать при настройке сервера и отладке долгих запросов. Предлагаю разобраться.
27.08.2024 10386 soulner 10
HighLoad оптимизация Технологический журнал Системный администратор Разработчик Бесплатно (free)
Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.
24.06.2024 19116 ivanov660 13
HighLoad оптимизация Разработчик 1С:Предприятие 8 Бесплатно (free)
Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.
06.06.2024 24973 Evg-Lylyk 73
HighLoad оптимизация Механизмы платформы 1С Системный администратор Разработчик Стажер 1С:Предприятие 8 Бесплатно (free)
Сравним «Регистры сведений» с «Сервисами интеграции» и узнаем, кто быстрее!
28.03.2024 14625 dsdred 27
HighLoad оптимизация Разработчик 1С:Предприятие 8 1C:Бухгалтерия Бесплатно (free)
Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.
13.03.2024 14608 spyke 29
это к последнему апдейту
А вот в новом механизме, который описан в данной статье, разработчики почему-то забыли эту опцию включить в запрос и если в настройках сервера MAXDOP равен 1, то реструктуризация будет медленнее чем хотелось бы . Возможно следует в статье 4-м пунктом добавить, что включение на сервере MAXDOP=0 на время реструктуризации, дополнительно ускорит этот процесс.
С одной стороны слава тебе Господи, наконец-то 1С сподобилась взяться за то, что куча народа ждало еще со времён 7.7. С другой стороны тут и Java, тут и Powershell… А сплясать в водолазном костюме в гамаке не надо?
Powershell для примера же приведен. Там кроме команды запуска 1С с параметрами "UpdateDBCfg -Server -v2" и нет ничего, одна консольная команда. Не внешнюю же обработку для выполнения одной консольной команды писать...
Просто Java программистов "как грязи" и 1С решили подбирать весь мусор и писать на том подо что есть программисты. На Java не пишут системное ПО нормальные люди конечно, просто C++ ника нормального попробуй найди
@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();
}
Мне вывело сообщение ошибка и на какой то внутренний модуль.
Гугл сказал что ничего не светит. я сказал ок и по старому за 6 часов обновился.
Обидно конечно.
Вот такое у меня сейчас. Ковыряемся. Ради спортивного интереса хочу докопаться до причин.
В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине:
Критическая ошибка работы Java-процесса.
Путь к Java: C:\Program Files\Java\jre1.8.0_181\bin\java.exe
Действие: prepare
Process ID: 22296
Код возврата: 1
Ошибка: Exception in thread "main" java.lang.IllegalStateException: Duplicate key ae4a0c5e-f97b-4cf4-96d8-c040bf8e222b
at java.util.stream.Collectors.lambda$throwingMerger$0(Unknown Source)
at java.util.HashMap.merge(Unknown Source)
at java.util.stream.Collectors.lambda$toMap$58(Unknown Source)
at java.util.stream.ReduceOps$3ReducingSink.accept(Unknown Source)
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(Unknown Source)
at java.util.stream.AbstractPipeline.copyInto(Unknown Source)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.ReferencePipeline.collect(Unknown Source)
at com._1c.dmf.v8.converters.parameters.documentjournal.GraphContent.<init>(GraphContent.java:24)
at com._1c.dmf.v8.cli.modelparsing.ConfigurationModelParser.deserializeGraphContent(ConfigurationModelParser.java:352)
at com._1c.dmf.v8.cli.modelparsing.ConfigurationModelParser.deserializeValue(ConfigurationModelParser.java:208)
at com._1c.dmf.v8.cli.modelparsing.ConfigurationModelParser.deserializeParameter(ConfigurationModelParser.java:172)
at com._1c.dmf.v8.cli.modelparsing.ConfigurationModelParser.deserializeAttributeParameter(ConfigurationModelParser.java:155)
at com._1c.dmf.v8.cli.modelparsing.ConfigurationModelParser.deserializeEntityParameters(ConfigurationModelParser.java:139)
at com._1c.dmf.v8.cli.modelparsing.ConfigurationModelParser.deserializeParameters(ConfigurationModelParser.java:112)
at com._1c.dmf.v8.cli.modelparsing.ConfigurationModelParser.parse(ConfigurationModelParser.java:92)
at com._1c.dmf.v8.internal.integration.Arguments.getOldModel(Arguments.java:84)
at com._1c.dmf.v8.internal.integration.DmfService.prepareMigration(DmfService.java:64)
at com._1c.dmf.v8.cli.Migration.run(Migration.java:90)
at com._1c.dmf.v8.cli.Migration.main(Migration.java:65)
Да что то очень похожее.
Причем все базы кроме нужной реструктурировались новым методом нормально.
Но там было не к спеху, и я просто сделал по старинке.
Изменений очень много было, может в этом была проблема?
У нас база 3 Тб
При том, что на все итоги и индексы, целостность которых якобы гарантирует платформа, существуют процедуры SQL, выполняющие пересчеты.
При возникновении сбоя на втором этапе часть данных в базе может стать некорректной, но всегда есть возможность скопировать файлы из NewStru и завершить процесс реструктуризации вручную. Исходили из положения что бакап и изменение структуры в процессе работы с DBF по-горячему сделать невозможно, а программист, обслуживающий конфигурацию не полезет в dbf и работу платформы, но точно знает основы работы с файлами в файловом менеджере.
В SQL есть возможность добавить колонку в таблицу в процессе работы. Немонопольно. Это не проблема для SQL, это проблема конфигуратора, который не умеет работать одновременно с разными версиями данных (до и после) какой то реструктуризации.
У меня возникла ошибка
В процессе обновления конфигурации базы данных при работе механизма реструктуризации второй версии произошла критическая ошибка
по причине:
При работе механизма реструктуризации второй версии возникла ошибка. Код возврата: 1. Операция: execute.
Версия платформы 8.3.13.1513
В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине:
Критическая ошибка работы Java-процесса.
Путь к Java: C:\Program Files (x86)\Java\jre1.8.0_221\bin\java.exe
Действие: prepare
Process ID: 2660
Код возврата: 1
Ошибка: Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
Критическая ошибка работы Java-процесса.
Путь к Java: C:\Program Files (x86)\Java\jre1.8.0_221\bin\java.exe
Действие: prepare
Process ID: 3392
Код возврата: 1
Ошибка:
Если режим совместимости версии 8.2.13 и выше то работает.
В режиме совместимости 8.1 выдает ошибку:
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Ожидается FIELD, INDEX или TABLE (pos=402)
В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине:
Не определен путь до каталога установки Java.
Где 1С-ка пытается найти и не находит путь ?
Из файла conf.cfg удалена строка UpdateDBCfg=v2.
Запуск обновления конфигурации выполняется через стандартную команду - F7.
Кэш клиента - очищен
Кэш сервера - очищен
Ошибка нового механизма появляется при обновлении любой базы на кластере
В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине:
Критическая ошибка работы Java-процесса.
Путь к Java: C:\Program Files (x86)\Java\jre1.8.0_144\bin\java.exe
Действие: execute
Process ID: 11096
Код возврата: 1
Ошибка: Exception in thread "main" com._1c.dmf.sqlframework.SqlExecutionException: An error occurred during execution of the sql operator
SQL reason: Cannot ins ert the val ue NULL into column '_Fld15210_NO', table 'AlkKrcTrade_test.dbo._Document11188_VT11194'; column does not allow nulls. UPD ATE fails.
SQL state: 23000
SQL: UPDATE __alias1 WITH(TABLOCK) SE T _Fld15210_NO = __alias2._Fld15210 FROM (_Document11188_VT11194 AS __alias1 LEFT JOIN _Document11188_NO AS __alias2 ON ((0x00002BB4 = 0x00002BB4) AND (__alias1._Document11188_IDRRef = __alias2._IDRRef)))
полный текст ошибки во вложении.
В таблицах SQL вижу, что в документах была создана колонка _Fld15210, а в ТЧ документов была создана колонка _Fld15210_NO и заполнены эти колонки нулями. Но UPDATE не проходит потому ,что нет таблицы _Document11188_NO? такой таблицы нет в базе данных. Подскажите, пожалуйста, как бороться с этим?
Платформа 8.3.18.1208
Конфигурация самописная, режим совместимости 8.3.11
Прописал в conf
ConfLocation=C:\Program Files\1cv8\conf
SystemLanguage=System
UpdateDBCfg=v2
Выходит ошибка:
Ошибка при выполнении операции с информационной базой
Запись не найдена в менеджере имен базы данных
Если удалить строки
SystemLanguage=System
UpdateDBCfg=v2
То Конфигуратор - конфигурация БД - обновить конфигурацию БД на сервере. запускается, но уже в обычном режиме. База не типовая 740Г
com.microsoft.sqlserver.jdbc.SQLServerException: This driver is not configured for integrated authentication. ClientConnectionId:9c149f85-00df-4bcd-8fe0-e6f123a96579
В чём может быть причина кто-то может подсказать?
Полный текст сообщения во вложении
"Caused by: java.lang.UnsatisfiedLinkError: no sqljdbc_auth in java.library.path:"
Вы либо используете MS SQL Server Express (а он не умеет в trusted connection через jdbc), либо у вас пакет с java "битый".
Как вариант, можно попробовать скачать библиотеку для авторизации и положить ее в папку java/bin
А Developer Edition умеет?
Добавление 2х реквизитов документа |
|---|
| ALT ER TABLE _Document106 ADD _Fld3663_NO NVARCHAR(40) NOT NULL DEFAULT CAST(N'' AS NVARCHAR(40)), _Fld3664_NO NUMERIC(10, 0) NOT NULL DEFAULT CAST(0 AS NUMERIC(10, 0)), _Fld3665_NO BINARY(1) NOT NULL DEFAULT 0x00 |
Ошибка: Exception in thread "main" com._1c.dmf.sqlframework.SqlExecutionException: An error occurred during execution of the sql operator
SQL reason: The transaction log for database '1C_T_ERP_ABI_2' is full due to 'LOG_BACKUP'.
SQL state: S0002
Может кто сталкивался, как исправить?
В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине:
Скрытый текст |
|---|
| Критическая ошибка работы Java-процесса.
Путь к Java: C:\Program Files (x86)\Java\jre1.8.0_271\bin\java.exe Действие: prepare Process ID: 12696 Код возврата: 1 Ошибка: Exception in thread "main" com._1c.dmf.sqlframework.SqlExecutionException: При выполнении запроса возникла ошибка SQL reason: ERROR: column __alias3.adsrc does not exist Позиция: 303 SQL state: 42703 SQL: SEL ECT __alias1.relname AS table_name, __alias2.attname AS column_name, __alias2.attnum AS column_index, format_type(__alias2.atttypid, NULL) AS type, __alias2.atttypmod AS type_specific_data, __alias2.attstorage AS type_storage, __alias2.attnotnull AS not_nullable, __alias2.atthasdef AS has_default, __alias3.adsrc AS default_value FR OM (((pg_catalog.pg_attribute AS __alias2 INNER JOIN pg_catalog.pg_class AS __alias1 ON ((__alias1.OID = __alias2.attrelid) AND (__alias1.relkind = 'r'))) INNER JOIN pg_catalog.pg_namespace AS __alias4 ON ((__alias1.relnamespace = __alias4.OID) AND (__alias4.nspname = 'public'))) LEFT JOIN pg_catalog.pg_attrdef AS __alias3 ON ((__alias3.adrelid = __alias2.attrelid) AND (__alias3.adnum = __alias2.attnum))) WHERE ((NOT __alias2.attisdropped) AND (__alias2.attnum > 0)) ORDER BY __alias1.relname, __alias2.attnum at com._1c.dmf.internal.sqlframework.SqlRowSet.<init>(SqlRowSet.java:80) at com._1c.dmf.internal.sqlframework.SqlRowSetFactory.createSqlRowSet(SqlRowSetFactory.java:23) at com._1c.dmf.internal.sqlframework.SqlConnection.executeQuery(SqlConnection.java:228) at com._1c.dmf.internal.sqlframework.postgresql.PostgresqlDatabaseIntrospection.getTables(PostgresqlDatabaseIntrospection.java:90) at com._1c.dmf.v8.internal.integration.Arguments.isFilePartMode(Arguments.java:234) at com._1c.dmf.v8.internal.integration.Arguments.getFile(Arguments.java:150) at com._1c.dmf.v8.internal.integration.Arguments.getOldModel(Arguments.java:84) at com._1c.dmf.v8.internal.integration.DmfService.prepareMigration(DmfService.java:64) at com._1c.dmf.v8.cli.Migration.run(Migration.java:90) at com._1c.dmf.v8.cli.Migration.main(Migration.java:65) Caused by: org.postgresql.util.PSQLException: ERROR: column __alias3.adsrc does not exist Позиция: 303 at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2310) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2023) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:217) at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:421) at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:318) at org.postgresql.jdbc.PgStatement.executeQuery(PgStatement.java:281) at com._1c.dmf.internal.sqlframework.SqlRowSet.<init>(SqlRowSet.java:65) ... 9 more |
Никакие индексы не менялись и вообще никакие манипуляции ни разу через PG выполнялись, так что 1С не потянул
Последовательность следующая :
1. Отключаем режим #UpdateDBCfg=v2
2. Запускаем обновление в обычном режиме.
На стадии реструктуризации (так как у меня процесс заваливался именно на данной стадии), через диспетчер задач убить процесс 1cv8.
3. Включаем режим V2 UpdateDBCfg=v2
4. Запускаем и ждём.
После этого процесс завершился успешно.
Установил Java
В конфиг.-файле прописал UpdateDBCfg=v2
Уточните пожалуйста:
Нужно ли в строке запуска службы (в реестре) добавлять какие либо параметры?
Нужно ли перезапускать службу сервера 1С? Или так сразу будет работать?
8.3.20.1613
Microsoft SQL Server 2012 (SP1) - 11.0.3156.0 (X64)
May 4 2015 18:48:09
Copyright © Microsoft Corporation
Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине:
Критическая ошибка работы Java-процесса.
Путь к Java: C:\Program Files (x86)\Java\jre1.8.0_311\bin\java.exe
Действие: prepare
Process ID: 5640
Код возврата: 1
Ошибка: Exception in thread "main" com._1c.dmf.v8.cli.ApplicationException: com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "The server selected protocol version TLS10 is not accepted by client preferences [TLS12]".
остальной текст ошибки |
|---|
| ClientConnectionId:0227df9a-55eb-48ed-a111-9458b5b1e677
at com._1c.dmf.v8.cli.jdbc.mssql.MsSqlDataSourceFactory.getYearOffset(MsSqlDataSourceFactory.java:105) at com._1c.dmf.v8.cli.jdbc.mssql.MsSqlDataSourceFactory.create(MsSqlDataSourceFactory.java:51) at com._1c.dmf.v8.cli.Migration.run(Migration.java:81) at com._1c.dmf.v8.cli.Migration.main(Migration.java:65) Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "The server selected protocol version TLS10 is not accepted by client preferences [TLS12]". ClientConnectionId:0227df9a-55eb-48ed-a111-9458b5b1e677 at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:2435) at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1816) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:2022) at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:1687) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectInternal(SQLServerConnection.java:1528) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:866) at com.microsoft.sqlserver.jdbc.SQLServerDataSource.getConnectionInternal(SQLServerDataSource.java:968) at com.microsoft.sqlserver.jdbc.SQLServerDataSource.getConnection(SQLServerDataSource.java:69) at com._1c.dmf.v8.cli.jdbc.V8DataSource.getConnection(V8DataSource.java:36) at com._1c.dmf.v8.cli.jdbc.mssql.MsSqlDataSourceFactory.getYearOffset(MsSqlDataSourceFactory.java:86) ... 3 more Caused by: javax.net.ssl.SSLHandshakeException: The server selected protocol version TLS10 is not accepted by client preferences [TLS12] at sun.security.ssl.Alert.createSSLException(Unknown Source) at sun.security.ssl.Alert.createSSLException(Unknown Source) at sun.security.ssl.TransportContext.fatal(Unknown Source) at sun.security.ssl.TransportContext.fatal(Unknown Source) at sun.security.ssl.TransportContext.fatal(Unknown Source) at sun.security.ssl.ServerHello$ServerHelloConsumer.onServerHello(Unknown Source) at sun.security.ssl.ServerHello$ServerHelloConsumer.consume(Unknown Source) at sun.security.ssl.SSLHandshake.consume(Unknown Source) at sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at sun.security.ssl.TransportContext.dispatch(Unknown Source) at sun.security.ssl.SSLTransport.decode(Unknown Source) at sun.security.ssl.SSLSocketImpl.decode(Unknown Source) at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1753) ... 11 more |
Пробовал решить так -
- но не помогло (конфигуратор перезапускал)
Пробую обновить MSSQL....
Если понаблюдать в мониторе текущих процессов в MS Studio, во время обновления по v2 - коннект к СУБД идет jdbc-драйвера, явно ведь он не из клиентского конфигуратора открыт.
Ну все ж логично и очевидно.
"смог выяснить" - г-н Шерстобитов у себя на курсе про разработку EDT ляпнул, что "на клиенте" и все за ним повторяют как попугаи
Но, возможно, Вы правы, а я мог ошибиться, из-за того, что сервер 1С у нас тоже 32хбитный... Проверю
если жмете "обновить конфу БД на сервере" - то conf.cfg на сервере
если жмете f7 ("синий бочонок") - то conf.cfg на клиенте
Но Java должна стоять на сервере 1С. Читаем ИТС:
UpdateDBCfg
Указывает, какая версия механизм реструктуризации информационной базы будет использоваться в том случае, если это явно не указано.
Параметр может принимать следующие значения:
● v1 ‑ 1-я версия механизма реструктуризации. Единственный вариант реструктуризации в «1С:Предприятии» версии 8.3.10 и младше.
● v2 ‑ 2-я версия механизма реструктуризации. Работает только для клиент-серверного варианта работы информационной базы в том случае, если в качестве СУБД используется Microsoft SQL Server или PostgreSQL. Если планируется использование 2-й версии механизма реструктуризации совместно с СУБД Microsoft SQL Server, то сервер «1С:Предприятия» для соединения с СУБД должен использовать сетевой протокол TCP/IP (в терминах СУБД). Работа 2-й версии механизма реструктуризации не поддерживается в том случае, если сервер «1С:Предприятия» подключается к СУБД Microsoft SQL Server с использованием сетевых протоколов Разделяемая память или Именованные каналы.
Добрый день!
Скажите, пожалуйста, а есть где то официальная информация, о том что v2 не работает при наличии объектов или их частей (реквизитов, таб. частей) в активном расширении конфигурации? И особенно если добавляем изменяем какие то реквизиты таб. части в расширение? Или v2 одинаково быстро работает при реструктуризации объектов основной конфигурации и объектов расширения?
(106)
UpdateDBCfg
Указывает, какая версия механизм реструктуризации информационной базы будет использоваться в том случае, если это явно не указано.
Параметр может принимать следующие значения:
● v1 ‑ 1-я версия механизма реструктуризации. Единственный вариант реструктуризации в «1С:Предприятии» версии 8.3.10 и младше.
● v2 ‑ 2-я версия механизма реструктуризации. Работает только для клиент-серверного варианта работы информационной базы в том случае, если в качестве СУБД используется Microsoft SQL Server или PostgreSQL. Если планируется использование 2-й версии механизма реструктуризации совместно с СУБД Microsoft SQL Server, то сервер «1С:Предприятия» для соединения с СУБД должен использовать сетевой протокол TCP/IP (в терминах СУБД). Работа 2-й версии механизма реструктуризации не поддерживается в том случае, если сервер «1С:Предприятия» подключается к СУБД Microsoft SQL Server с использованием сетевых протоколов Разделяемая память или Именованные каналы.
Значение по умолчанию: v1.
Используется в конфигурационном файле на компьютере, где запускается конфигуратор.
сегодня буквально разбирались с этим
На более старых релизах работало так, как написано здесь в статье. То есть, если нажимали "синий бочонок" в конфигураторе на клиенте - анализировался клиентский conf.cfg. Если нажимали "конфигурация БД - обновить на сервере" - анализировался на сервере.
С какого-то релиза платформы ее разработчики отдали приоритет в рамках этого механизма клиентскому conf.cfg. И теперь неважно, что нажимать: "бочонок" или "обновить на сервере" - анализируется клиентский conf.cfg
Но так работало не всегда, на 8.3.12, на которой я впервые этот механизм попробовал - при "обновить конфигурацию на сервере" анализировался именно "серверный" conf.cfg
Релиз, с которого поведение стало соответствовать описанию на ИТС (кстати, возможно и описание поправили вместе с изменением) - не подскажу, надо проверять, тестировать.
Либо, как чаще всего и бывает, нуралиеву сотоварищи вложат ума крупные компании, и именно поэтому самые адские косяки будут относительно оперативно устранены))
На компьютере, где обновлял сделал все по инструкции, при обновлении базы вылетела ошибка Java.
Открыл базу в конфигураторе на другом компьютере (java не установлена, настроек в conf.cfg нет). Пытаюсь обновить, но возникает ошибка "Не обнаружена Java".
Как вернуться к первоначальному механизму реструктуризации?
В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине:
Критическая ошибка работы Java-процесса.
Путь к Java: C:\Program Files\Java\jre1.8.0_311\bin\java.exe
Действие: revert
Process ID: 23764
Код возврата: 1
Ошибка: Exception in thread "main" com._1c.dmf.migrator.MigratorException: Migration table has no rows
at com._1c.dmf.internal.migrator.PersistenceManager.loadMigration(PersistenceManager.java:94)
at com._1c.dmf.internal.migrator.Migrator.loadMigration(Migrator.java:115)
at com._1c.dmf.internal.migrator.Migrator.revertMigration(Migrator.java:93)
at com._1c.dmf.v8.internal.integration.DmfService.revertMigration(DmfService.java:126)
at com._1c.dmf.v8.cli.Migration.run(Migration.java:99)
at com._1c.dmf.v8.cli.Migration.main(Migration.java:65)
Пробовал разные версии Java, удалить расширения из базы, ошибка не меняется. платформа 8.3.18.1661
В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине:
Критическая ошибка работы Java-процесса.
Путь к Java: C:\Program Files\Java\jre1.8.0_321\bin\java.exe
Действие: prepare
Process ID: 7848
Код возврата: 1
Ошибка: Exception in thread "main" java.lang.IllegalArgumentException: expected one element but was: <com._1c.dmf.v8.converters.entities.parameterholders.EntityAssociatedQueryRowSourceParameterHolder$RowSourceItemW ПоказатьНе указал в своём вопросе видимо самое важно, это была реструктуризации при обновлении конфигурации с версии 2.4.14 на 2.5.7. Поэтому да, изменений очень много.
Обычная реструктуризации проходила без ошибок, но занимала по времени порядка 6 часов.
Отменить изменения по одному, в данном случае, не представлялось возможным, да и не целесообразным.
На сколько я понял, эта реструктуризации не переваривает любые сортировки метаданных, в типовых, я думаю, такое бывает.
Смотрим, что написано в файле conf
C:\Program Files (x86)\1cv8\8.3.12.1529\bin\conf
Ка правило, путь в нем указан так: ConfLocation=C:\Program Files (x86)\1cv8\conf
Правим указанный файл так, чтобы он содержал строку: UpdateDBCfg=v2
А где прописывать? На клиенете или на самом сервере?
А кто-нибудь знает можно ли как-то включить этот новый механизм обновления при записи из режима предприятия?
Суть в следующем: переводим бух проф на корп, так вот при первом запуске, когда выполняются процедуры обновления происходит отключение учёта по подразделениям для всех счетов (где учёта по подразделениям не было в проф). И при записи счета неявно вызывается процедура обновления всего регистра бухгалтерии (также как это происходит при обновлении в режиме v1 из конфигуратора), сейчас основная проблема в том, что этот оооочень долгий update таблицы регистра бухгалтерии выполняется в цикле по каждому счету (в конфигураторе это хотя бы за один раз для всех счетов происходит даже в режиме v1, а тут вообще беда получается). Если бы при записи из режима предприятия можно было бы использовать режим v2 это был бы выход.
но вообще(если разработчики 1С читают инфостарт): такой механизм в типовой это просто классика того, чего казалось бы нельзя делать: оочень тяжелый запрос на update всей таблицы без отбора вызывается в цикле несколько сотен раз...для больших баз этот процесс растянется на дни...
Использую новую версию механизма реструктуризации ИБ (платформа 8.3.18.1289, конфа в режиме совместимости 8.3.12), и на этапе обработки структуры БД вываливается ошибка:
Трассировка стека |
|---|
| В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине: Критическая ошибка работы Java-процесса. Путь к Java: C:\Program Files\Java\jre1.8.0_333\bin\java.exe Действие: prepare Process ID: 1452 Код возврата: 1 Ошибка: Exception in thread "main" java.lang.IllegalArgumentException: Multiple entries with same key: vtTable=vtTable:null and vtTable=vtTable:null at com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:150) at com.google.common.collect.RegularImmutableMap.checkNoConflictInBucket(RegularImmutableMap.java:104) at com.google.common.collect.RegularImmutableMap.<init>(RegularImmutableMap.java:70) at com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:254) at com.google.common.collect.Maps.uniqueIndex(Maps.java:1166) at com.google.common.collect.Maps.uniqueIndex(Maps.java:1140) at com._1c.dmf.model.configuration.ParameterCollection.<init>(ParameterCollection.java:36) at com._1c.dmf.model.configuration.ParameterCollection.<init>(ParameterCollection.java:21) at com._1c.dmf.model.configuration.ParameterCollection$ParameterCollectionBuilder.build(ParameterCollection.java:89) at com._1c.dmf.model.configuration.ConfigurationModel$ConfigurationModelBuilder.build(ConfigurationModel.java:145) at com._1c.dmf.v8.cli.modelparsing.ConfigurationModelParser.parse(ConfigurationModelParser.java:101) at com._1c.dmf.v8.internal.integration.Arguments.getOldModel(Arguments.java:86) at com._1c.dmf.v8.internal.integration.DmfService.prepareMigration(DmfService.java:64) at com._1c.dmf.v8.cli.Migration.run(Migration.java:90) at com._1c.dmf.v8.cli.Migration.main(Migration.java:65) |
Смысл джавовского экзепшена понятен ☹️, но хотелось в сообщениях конфигуратора увидеть более детальную информацию в терминах 1С (имя проблемной сущности, метаданного и прочее).
Куда копать?
Может, тех журнал 1С (если конечно туда вообще что-то попадает из java-процесса)?
В conf.cfg есть параметр JavaOpts, с помощью которого можно вроде как настроить подключение java-отладчика. Кто-то этот параметр использовал для целей отладки?
В режиме v1 все ок.
Process ID: 10456
Код возврата: 1
Ошибка: Exception in thread "main" java.lang.IllegalStateException: Duplicate key _InfoRg105003_1(TARGET)
Возникает, если из типов первого измерения регистра сведений удаляю один документ. Записей в регистре с документом такого типа в базе нет.
На базе-пустышке воспроизвел ситуацию
Для получения ошибки нужно убрать из типа первого измерения "ДокументДвижения" регистра РегистрСведений1 тип "Документ3".
Ошибка: Exception in thread "main" com._1c.dmf.v8.cli.ApplicationException: com.microsoft.sqlserver.jdbc.SQLServerException: The TCP/IP connection to the host lpc:server1c, port 1433 has failed. Error: "lpc:server1c. Verify the connection properties. Make sure that an instance of SQL Server is running on the host and accepting TCP/IP connections at the port. Make sure that TCP connections to the port are not blocked by a firewall.".
Из описания: "Работа 2-й версии механизма реструктуризации не поддерживается в том случае, если сервер «1С:Предприятия» подключается к СУБД Microsoft SQL Server с использованием сетевых протоколов Разделяемая память или Именованные каналы.""
В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине:
Критическая ошибка работы Java-процесса.
Путь к Java: C:\Program Files\Java\jre1.8.0_171\bin\java.exe
Действие: prepare
Process ID: 1676
Код возврата: 1
Ошибка: Exception in thread "main" java.lang.IllegalArgumentException: Multiple entries with same key: d4a4009b-a066-44cf-b07a-41e678aa990b=com._1c.dmf.v8.converters.parameters.predefineddata.PredefinedData$PredefinedDataRow@d0acc098 and d4a4009b-a066-44cf-b07a-41e678aa990b=com._1c.dmf.v8.converters.parameters.predefineddata.PredefinedData$PredefinedDataRow@9e196fa6
at com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:150)
at com.google.common.collect.RegularImmutableMap.checkNoConflictInBucket(RegularImmutableMap.java:104)
at com.google.common.collect.RegularImmutableMap.<init>(RegularImmutableMap.java:70)
at com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:254)
at com.google.common.collect.Maps.uniqueIndex(Maps.java:1166)
at com.google.common.collect.Maps.uniqueIndex(Maps.java:1140)
at com._1c.dmf.v8.converters.parameters.predefineddata.PredefinedData.<init>(PredefinedData.java:47)
at com._1c.dmf.v8.cli.modelparsing.ConfigurationModelParser.deserializePredefinedData(ConfigurationModelParser.java:625)
at com._1c.dmf.v8.cli.modelparsing.ConfigurationModelParser.deserializeValue(ConfigurationModelParser.java:226)
at com._1c.dmf.v8.cli.modelparsing.ConfigurationModelParser.deserializeParameter(ConfigurationModelParser.java:172)
at com._1c.dmf.v8.cli.modelparsing.ConfigurationModelParser.deserializeEntityParameters(ConfigurationModelParser.java:131)
at com._1c.dmf.v8.cli.modelparsing.ConfigurationModelParser.deserializeParameters(ConfigurationModelParser.java:112)
at com._1c.dmf.v8.cli.modelparsing.ConfigurationModelParser.parse(ConfigurationModelParser.java:92)
at com._1c.dmf.v8.internal.integration.Arguments.getNewModel(Arguments.java:92)
at com._1c.dmf.v8.internal.integration.DmfService.prepareMigration(DmfService.java:65)
at com._1c.dmf.v8.cli.Migration.run(Migration.java:90)
at com._1c.dmf.v8.cli.Migration.main(Migration.java:65)
Archlinux (клиент и сервер), 8.3.21.1508, Postgresql 14.4-1.1C, Bellsoft JDK 11.0.15
Проблем с 11 версией Java не было?
Просто много раз проверял на 11, 17 и 19 версиях Liberica и Axiom, всегда ошибка обновления. Работает только на версии 8.
Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
at com.microsoft.sqlserver.jdbc.SQLServerConnection.sendLogon(SQLServerConnection.java:4061)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.logon(SQLServerConnection.java:3157)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.access$100(SQLServerConnection.java:82)
at com.microsoft.sqlserver.jdbc.SQLServerConnection$LogonCommand.doExecute(SQLServerConnection.java:3121)
at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:7151)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:2478)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:2026)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:1687)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectInternal(SQLServerConnection.java:1528)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:866)
at com.microsoft.sqlserver.jdbc.SQLServerDataSource.getConnectionInternal(SQLServerDataSource.java:968)
at com.microsoft.sqlserver.jdbc.SQLServerDataSource.getConnection(SQLServerDataSource.java:69)
at com._1c.dmf.v8.cli.jdbc.V8DataSource.getConnection(V8DataSource.java:36)
at com._1c.dmf.v8.cli.jdbc.mssql.MsSqlDataSourceFactory.getYearOffset(MsSqlDataSourceFactory.java:86)
at com._1c.dmf.v8.cli.jdbc.mssql.MsSqlDataSourceFactory.create(MsSqlDataSourceFactory.java:51)
at com._1c.dmf.v8.cli.Migration.run(Migration.java:81)
at com._1c.dmf.v8.cli.Migration.main(Migration.java:65)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.DatatypeConverter
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
... 17 more
Но у меня такой ошибки не было, возможно дело в более новой платформе и там переписали использование этого класса?
Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter если на сервере (у меня он же - станция для разработки) установлена последняя на данный момент Liberica 11 Full JDK 11.0.18+10 требующаяся для работы 1C:Enterprise Development Tools
Как вариант - попробовать добавить туда же в conf.cfg строчку
JavaOpts="--add-modules java.xml.bind"Либо в переменные окружения добавить JDK_JAVA_OPTIONS с тем же содержимым
Но у меня это привело только к изменению ошибки на другую, то есть саму проблему с новым механизмом реструктуризации не решило
Выполнение одного или нескольких заданий завершилось с ошибкой Ошибка СУБД:
Microsoft SQL Server Native Client 10.0: Invalid object name 'dbo._AccumRg55154NG'.
HRESULT=80040E37, SQLSrvr: SQLSTATE=42S02, state=1, Severity=10, native=208, line=1
Версия платформы: 8.3.22.1750
- В регистре сведений ничего не изменилось, но добавлен флажок "Разрешить итоги: срез первых/последних" на вкладке "Прочее".
- Такая ситуация (многабукв):
Скрытый текст |
|---|
| В состав типов плана видов характеристик СтатьиРасходов входит перечисление
ВидыОбязательногоСтрахованияСотрудников. При обновлении 2.5.8.402 – 2.5.8.410 было удалено одно значение этого перечисления: ВзносыПоЕдиномуТарифу. Именно это приводит к реструктуризации лишних таблиц. Если через сравнение-объединение конфигураций восстановить значение этого перечисления, то V2-реструктуризация проходит без ошибки. |
Об ошибке я месяц назад сообщил разработчикам, и они приняли ее, но пока результатов нет.
Ссылка на багборд (но описания там нет)
Такая же ошибка на платформе 8.3.22.2239
Началось всё совершенно внезапно с ошибки при обновлении конфигурации БД после добавления нового реквизита
В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка по причине:
Критическая ошибка работы Java-процесса.
Путь к Java: C:\Program Files\BellSoft\LibericaJDK-11-Full\\bin\java.exe
Действие: revert
Process ID: 21220
Код возврата:1
Ошибка: Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
...Поначалу я вообще не понял - чего она вообще, в 1С-то ничего не менялось?! Только постфактум понимаю, что причиной послужила установка Liberica 11 Full JDK 11.0.18+10, которая требовалась для запуска 1C:Enterprise Development Tools. А уже она переписала переменную окружения JAVA_HOME на путь к своей версии Java.
Дальнейшее исследование вывело на статью, в которой рассказывалось, что этот самый пакет java.xml.bind, который зачем-то хочет 1С, был успешно выпилен в 11-й версии Java, и предлагался вариант решения, который я описал в (129). Но как я и сказал, у меня это привело только к пропаданию этой ошибки, и появлению новой:
В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка по причине:
При попытке запуска Java в оптимизированном механизме обновления конфигурации базы данных возникла ошибка
Путь к Java: C:\Program Files\BellSoft\LibericaJDK-11-Full\\bin\java.exe
Действие: revert
А дальше начались танцы с бубном:
Не работает 11-я Java? Поставим 8-ю!
Скачал-установил jre-8u371.
Не помогло.
Окей, раньше всё работало, но что-то сломалось - может в новой платформе уже исправили? И я поставил вместо 8.3.21.1393 самую последнюю 8.3.23.1688.
Не помогло.
Заодно выяснилось, что последняя платформа - глючное г...но, жрущее как не в себя процессор. Не, ну то есть загрузка процессора процессом 1С на 4-5% это вроде и не страшно, но не тогда, когда у тебя на RDP сидит 20+ пользователей. Загрузка процессора 5%*20шт - и сервер встаёт колом.
Откатился на 8.3.22.1923.
С ней, кстати, в комплекте идёт своя Java (Liberica JRE)
Дальше были эксперименты с JavaHome в conf.cfg и JAVA_HOME в переменных окружения.
conf.cfg |
|---|
| А вы знали, что conf.cfg есть не только в C:\Program Files\1cv8\conf\, но и в C:\Program Files\1cv8\8.3.xx.yyyy\bin\conf?
И смотрит 1С в оба файла, сначала в тот что в папке платформы, потом в общий. А потом еще проверяет наличие файла в папке пользователя C:\Users\<user>\AppData\Local\1C\1cv8\conf\conf.cfg |
Путь к Java в сообщении об ошибке успешно менялся (требуется перезапуск сервера 1С), сама ошибка - нет.
Отдельной головной боли добавляло то, что на другой базе добавление реквизита/предопределенного элемента (чтобы вызвать реструктуризацию) этой ошибки почему-то не вызывало.
Более того, попытки засунуть UpdateDBCfg=v1 вместо установленной однажды из любопытства v2 в оба конфига (по очереди и одновременно), как и полное удаление этой строки из конфигов (с перезапуском сервера 1С после каждого изменения) не меняли вообще ничего. 1С почему-то всё так же пыталась обновиться "по новому" и выдавала ошибку.
Информации в тексте ошибки 0. Информации в Интернете по тексту ошибки 0. В технологическом журнале только тот же самый текст, что и в ошибке. Хочется сказать отдельное спасибо разработчикам за их заботу о пользователях и админах!
Последняя идея - попытаться посмотреть, куда же 1С всё-таки обращается, когда решает обновляться по v2 вместо v1 привела к неожиданному открытию. Procmon показал, что несмотря на то, что 1С пишет мол "путь к java - тот, что идет в комплекте с платформой (а значит гарантированно работоспособной)", реально она всё так же ломится к LibericaJDK-11!
В общем снёс EDT, удалил и 8-ю Java от Oracle и 11-ю Java от 1С (она за собой удалила JAVA_HOME из переменных окружения), вручную добавил JAVA_HOME=C:\Program Files\1cv8\8.3.22.1923\bin\jre и наконец-то всё заработало!
Путь был тернист и запутан, а 1С всё так же почему-то использует новый механизм реструктуризации конфигурации БД с древней Java 8, при том что для запуска EDT требуется 11-я.
Теперь, не понимая зачем вообще нужен conf.cfg (наверное чтобы было что писать в тексте ошибки), попробую заново установить LibericaJDK-11 и 1C:EDT, и уже в её опциях указать путь до нужной ей версии Java 11, оставив системный путь до Java 8 нужной конфигуратору. Но это будет уже совсем другая история.
Добавление реквизита
Оптимизированный вариант работает в 2 раза медленнее, чем обычный.
При удалении реквизита аналогично.
Пробовал нажимать f7 а так же "Обновить конфигурацию базы данных на сервере".
Может кто объяснить, почему так?
СУБД MSSQL 2019.
Во вложении ошибка.
Пробовал скачать pgJDBC v42.6.0 и положить в папку bin нужной версии Java. Не помогает.
Может что-то нужно еще настроить? Если верить документации с ИТС - должно работать и с PostgreSQL.
PostgreSQL 14.4. Платформа 8.3.19.1522
Самое интересное, поле Fld36980 на которое ругается, не нашёл в полях таблицы, есть похожее _Fld36980RRef
Текст ошибки под спойлером
Текст ошибки |
|---|
| В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине: Критическая ошибка работы Java-процесса. Путь к Java: C:\Program Files\BellSoft\LibericaJRE-8-Full\\bin\java.exe Действие: prepare Process ID: 1544 Код возврата: 1 Ошибка: Exception in thread "main" com._1c.dmf.comparator.ComparatorException: Конвертер com._1c.dmf.v8.converters.attributes.typedfield.TypedFieldConverter@117159c0 определил объект "Document36954.Fld36980" как некорректный at com._1c.dmf.internal.comparator.ConverterManager.lambda$getConverters$1(ConverterManager.java:80) at java.util.stream.ReferencePipeline$11$1.accept(ReferencePipeline.java:439) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at java.util.Spliterators$IteratorSpliterator.tryAdvance(Spliterators.java:1812) at java.util.stream.StreamSpliterators$WrappingSpliterator.lambda$initPartialTraversalState$0(StreamSpliterators.java:295) at java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.fillBuffer(StreamSpliterators.java:207) at java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.doAdvance(StreamSpliterators.java:162) at java.util.stream.StreamSpliterators$WrappingSpliterator.tryAdvance(StreamSpliterators.java:301) at java.util.Spliterators$1Adapter.hasNext(Spliterators.java:681) at com._1c.dmf.internal.comparator.AttributeComparisonContext.orderConverters(AttributeComparisonContext.java:132) at com._1c.dmf.internal.comparator.AttributeComparisonContext.createConvertEx * pression(AttributeComparisonContext.java:109) at com._1c.dmf.internal.comparator.AttributeComparisonContext.getConvertEx * pression(AttributeComparisonContext.java:90) at com.google.common.collect.Maps.toMap(Maps.java:1119) at com.google.common.collect.Maps.toMap(Maps.java:1097) at com._1c.dmf.internal.comparator.ComparisonProcess.processEntity(ComparisonProcess.java:150) at java.lang.Iterable.forEach(Iterable.java:75) at com._1c.dmf.internal.comparator.Comparator.compare(Comparator.java:35) at com._1c.dmf.v8.internal.integration.DmfService.prepareMigration(DmfService.java:67) at com._1c.dmf.v8.cli.Migration.run(Migration.java:90) at com._1c.dmf.v8.cli.Migration.main(Migration.java:65) |
sudo dpkg-reconfigure locales
# выбрать en_US.UTF-8
# оставить выбранной ru_RU.UTF-8
# затем перезапустить postgres:
sudo /opt/pgpro/1c-15/bin/pg-setup service stop
sudo /opt/pgpro/1c-15/bin/pg-setup service start
Иначе 1С (вернее JAVA 8) выдает ошибку
Caused by: org.postgresql.util.PSQLException: ОШИБКА: неверное значение для параметра "lc_messages": "en_US.UTF-8"
Process ID: 10368
Код возврата: 1
Ошибка: Exception in thread "main" java.util.NoSuchElementException: Сущность "ReferenceChngR58055" не имеет разделителя с идентификатором 6df2bb92-558c-4453-9de4-e4176e8f93dc
Полный текст |
|---|
| В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине: Критическая ошибка работы Java-процесса. Путь к Java: C:\Program Files\BellSoft\LibericaJRE-8-Full\bin\java.exe Действие: prepare Process ID: 10368 Код возврата: 1 Ошибка: Exception in thread "main" java.util.NoSuchElementException: Сущность "ReferenceChngR58055" не имеет разделителя с идентификатором 6df2bb92-558c-4453-9de4-e4176e8f93dc at com._1c.dmf.model.entities.Entity.getSeparator(Entity.java:227) at com._1c.dmf.v8.converters.entities.SeparatorUtils.lambda$createSeparatorColumns$0(SeparatorUtils.java:35) at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) at java.util.Iterator.forEachRemaining(Iterator.java:116) at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:566) at com._1c.dmf.v8.converters.entities.SeparatorUtils.createSeparatorColumns(SeparatorUtils.java:37) at com._1c.dmf.v8.converters.entities.changerec.ChangeRecUtils.newChangesForDataExchange(ChangeRecUtils.java:176) at com._1c.dmf.v8.converters.entities.changerec.ChangedOrDeletedPredefinedChangeRecRegisterConverter.lambda$createRowSources$0(ChangedOrDeletedPredefinedChangeRecRegisterConverter.java:63) at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1384) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:566) at com._1c.dmf.v8.converters.entities.changerec.ChangeRecUtils.createNewChangesSource(ChangeRecUtils.java:191) at com._1c.dmf.v8.converters.entities.changerec.ChangedOrDeletedPredefinedChangeRecRegisterConverter.createRowSources(ChangedOrDeletedPredefinedChangeRecRegisterConverter.java:63) at com._1c.dmf.internal.comparator.ComparisonProcess.lambda$processEntity$0(ComparisonProcess.java:135) at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:269) at java.util.stream.ReferencePipeline$11$1.accept(ReferencePipeline.java:440) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) at java.util.Iterator.forEachRemaining(Iterator.java:116) at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:566) at com._1c.dmf.internal.comparator.ComparisonProcess.processEntity(ComparisonProcess.java:136) at java.lang.Iterable.forEach(Iterable.java:75) at com._1c.dmf.internal.comparator.Comparator.compare(Comparator.java:35) at com._1c.dmf.v8.internal.integration.DmfService.prepareMigration(DmfService.java:67) at com._1c.dmf.v8.cli.Migration.run(Migration.java:109) at com._1c.dmf.v8.cli.Migration.main(Migration.java:84) |
ВАЖНО: Если обновление по v2 падает с ошибкой - одна из причин может быть в том, что в вашей БД есть индексы, отличные от стандартных платформенных (добавленные вручную) - их необходимо физически удалить (именно удалить, а не отключить) перед запуском обновления.
Скорее всего сделаны неверные выводы. Из имени таких индексов необходимо удалить символ тире "-", который SMSS включает в имя индекса для отделения даты/времени при ручном добавлении индекса. С подобной ошибкой можно встретиться и при обычном обновлении v1, но там она тоже завуалирована.
Вводные: 1С платформа 8.3.24.1738, MS SQL, установлены рекомендуемые настройки, база порядка 660 Гб.
Удалилась таблица БД, которая имела суффикс X1. Таблицы с суффиксом X1 появляются тогда, когда объект добавлен в расширение, и в расширении ему добавлен новый реквизит и т.д. Могу предположить, что X – от слова extension (расширение). Т.е. не все расширения так влияют на наименования таблиц.
Так вот, в нашем случае был такой объект, документ Заказ клиента. При обновлении по новой схеме в конце обновления после принятия изменений выдало ошибку:
“Ошибка СУБД
Microsoft OLE DB Driver for SQL Server: Either the parameter @objname is ambiguous or the claimed @objtype (object) is wrong. HRESULT=80040E14. SQLSrvr: SQLSTATE=42000, state=1, Severity=B, native=15248, line=419”.
Нажал “Перезапустить”. При повторном входе в конфигуратор всё было нормально, как будто всё обновилось.
Запустили пользовательский режим. Началось обновление на новый релиз. В конце обновления выдало ошибку:
“Ошибка СУБД:
Microsoft OLE DB Driver for SQL Server: Invalid object name ‘dbo._Document541X1’.
HRESULT=80040E37, SQLSrvr: SQLSTATE=42S02, state=1, Severity=10, native=208, line=1”
Обработка “Структура хранения БД” выдавала, что Заказ клиента всё так же ссылается на эту таблицу (_Document541X1). Но при прямом просмотре таблиц в SQL была найдена только таблица без X1, т.е. dbo._Document541 (включая табличные части). Решено было в качестве теста просто переименовать, т.е. добавить нужный суффикс.
В пользовательском режиме обновление было завершено. Ошибок не было. НО! Как и ожидалось, данных в этой таблице не было. И везде вместо ссылок было “Объект не найден”.
Т.е. мы для себя сделали ввод, что по новой схеме 1С не умеет корректно работать с таблицами объектов, которые расширялись в расширениях.
После настройки нового режима реструктуризации при попытке обновления вылетала ошибка:
В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине:
Критическая ошибка работы Java-процесса.
Путь к Java: C:\Program Files\Java\jre1.8.0_431\bin\java.exe
Действие: prepare
Process ID: 9908
Код возврата: 1
Ошибка: Exception in thread "main" com._1c.dmf.sqlframework.SqlConnectionException: При создании соединения возникла ошибка
at com._1c.dmf.internal.sqlframework.SqlDataSource.getSqlConnection(SqlDataSource.java:57)
at com._1c.dmf.v8.internal.integration.Arguments.getFile(Arguments.java:175)
at com._1c.dmf.v8.internal.integration.Arguments.getOldModel(Arguments.java:97)
at com._1c.dmf.v8.internal.integration.DmfService.prepareMigration(DmfService.java:65)
at com._1c.dmf.v8.cli.Migration.run(Migration.java:109)
at com._1c.dmf.v8.cli.Migration.main(Migration.java:84)
Caused by: org.postgresql.util.PSQLException: ОШИБКА: неверное значение для параметра "lc_messages": "en_US.UTF-8"
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2310)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2023)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:217)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:421)
at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:318)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:310)
at com._1c.dmf.v8.cli.jdbc.postgresql.PostgresqlConnectionInitializer.init(PostgresqlConnectionInitializer.java:26)
at com._1c.dmf.v8.cli.jdbc.V8DataSource.getConnection(V8DataSource.java:39)
at com._1c.dmf.internal.sqlframework.SqlDataSource.getSqlConnection(SqlDataSource.java:53)
... 5 more
У меня Postgres стоит на Ubuntu 22.04.
Вылечил установкой требуемой локали в Ubuntu
решение взял из
Установить:
sudo locale-gen en_US.UTF-8
sudo locale-gen ru_RU.UTF-8
sudo update-locale LANG=ru_RU.UTF8
sudo dpkg-reconfigure locales
В окне нажать ОК (новые языки уже с галочками) в следующем окне язык системы выбрать тот который был (у меня ru_RU.UTF-8)
Перезагрузить сервер или postgres чтобы СУБД узнала о новой локали.
Настройка UpdateDBCfg в conf.cfg используется в конфигурационном файле на компьютере, где запускается конфигуратор
В руководстве разработчика не указывается обязательная установка Java.
Как то это можно победить?
В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине:
Критическая ошибка работы Java-процесса.
Путь к Java: C:\Program Files\1cv8\8.3.27.1719\bin\jre\bin\java.exe
Действие: prepare
Process ID: 22532
Код возврата: 1
Ошибка: Exception in thread "main" com._1c.dmf.migrationbuilder.MigrationBuilderException: Different named row source have same name newPredefinedExtDims_3796bdf5-5d0b-4232-b22e-6d2cd8beb488
at com._1c.dmf.internal.migrationbuilder.dbspacebuilders.TemporaryTablesBuilder$NamedRowSourceCollector.visit(TemporaryTablesBuilder.java:138)
at com._1c.dmf.internal.migrationbuilder.dbspacebuilders.TemporaryTablesBuilder$NamedRowSourceCollector.visit(TemporaryTablesBuilder.java:101)
at com._1c.dmf.model.visitor.AbstractExpressionVisitor.visit(AbstractExpressionVisitor.java:158)
at com._1c.dmf.model.visitor.AbstractExpressionVisitor.lambda$visit$2(AbstractExpressionVisitor.java:379)
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:566)
at com._1c.dmf.model.visitor.AbstractExpressionVisitor.visit(AbstractExpressionVisitor.java:380)
at com._1c.dmf.model.visitor.AbstractExpressionVisitor.visit(AbstractExpressionVisitor.java:368)
at com._1c.dmf.internal.migrationbuilder.dbspacebuilders.TemporaryTablesBuilder$NamedRowSourceCollector.visit(TemporaryTablesBuilder.java:148)
at com._1c.dmf.internal.migrationbuilder.dbspacebuilders.TemporaryTablesBuilder$NamedRowSourceCollector.collect(TemporaryTablesBuilder.java:112)
at java.lang.Iterable.forEach(Iterable.java:75)
at com._1c.dmf.internal.migrationbuilder.dbspacebuilders.TemporaryTablesBuilder.build(TemporaryTablesBuilder.java:70)
at com._1c.dmf.internal.migrationbuilder.PreparedMigrationBuilder.buildMigration(PreparedMigrationBuilder.java:51)
at com._1c.dmf.internal.migrationbuilder.MigrationBuilder.buildMigration(MigrationBuilder.java:50)
at com._1c.dmf.v8.internal.integration.DmfService.prepareMigration(DmfService.java:71)
at com._1c.dmf.v8.cli.Migration.run(Migration.java:109)
at com._1c.dmf.v8.cli.Migration.main(Migration.java:84)
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 934237
Создание 31.10.18 15:06
Обновление 13.04.22 18:38
Просмотры 127034
Загрузки 0
Рейтинг
268
Комментарии 152
Код открыт Да
Рубрики HighLoad оптимизация
Кому
Системный администратор
,
Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
