База на SQL. Добавляю в документ новую ТЧ. Колонки ТЧ не содержат ссылочных данных, только типы Число и Строка. При сохранении конфигурации получаю реструктуризацию на 1 час+. Чем это вызвано и что с этим можно сделать, если вообще можно? По сути в SQL просто появляется еще одна пустая таблица.

(0) включи реструктуризацию V2

(0) >> получаю реструктуризацию на 1 час+. В SQL просто появляется еще одна пустая таблица.

Значит не "просто".
Чудес не бывает.
Попробуй на копии. Поменяй какой-нибудь маленький справочник (Оганизации, Склады, Валюты), чтобы инициировать реструктуризацию. Добавь какое-нибудь поле, например. Потом удалишь.
Может вы ни разу реструктуризацию не делали за последние несколько лет, но при этом, например, обновляли версию платформы?

(2) На копии попробую. Конфа дорабатывается постоянно, обслуживается ежедневно. Еще интересный момент, точно такую ТЧ добавлял в другой документ, реструктурировалось все около минуты.

(3) чудес не бывает.

(1) У нас не КОРП, да и это не столько решение проблемы, сколько ее отправка в фон.

(5) при чем тут корп ?

И это решение проблемы с реструктуризацие любой, в принципе.
Там альтер тэйбл, заместо сопи-инсерт-делете

(0) Просто открой текущие активности сиквела и посмотри какие операции на каких таблицах делаются. А потом уже спиритические сеансы устраивай.

(2) Добавил строковый реквизит в Справочник.Склады. Реструктуризация прошла влет.

(8) А где конкретно в скуле это глянуть?

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

(10) Да, нашел, интересный инструмент. Даже планы запроса показывает. Сейчас буду разбираться. Тут хоть реально видно, что происходит. Спасибо.

В итоге получается такая ситуация. Как только я меняю метаданные в этом документе (Добавляю реквизит, ТЧ и т.д.) начинается полная реструктуризация этого объекта, что и приводит к такому длительному зависанию. Само зависание вызывала реструктуризация ТЧ Товары, в которой было 48 млн строк. Почему вышло так, что не смотря на то, что меняются данные не относящиеся к ТЧ Товары, а реструктурируется всеравно она, то предположу, что, когда-то что-то с этой базой наворочили (это к слову копия, для теста и доработок) и, видимо, прервали какую-то реструктуризацию. "Флаг", что реструктуризация не закончилась остался и теперь при любом изменении данного объекта начинается полная его реструктуризация, ну или та, которая была прервана. Иными словами, это частный случай и чудес не бывает. Всем спасибо, особенно fisher, за отличный инструмент скуля.

(13) включи v2 и твои 48 млн прпожует минут за 5-10

Или, если есть полная уверенность, что ТЧ товары не нуждается в реструктуризации, то в сскуле переименовываешь табличку, далее пкм на ней - задание на основе Create table - новый скрипт, в нём меняешь на имя как было, создаешь пустую табличку. далее в 1с реструктуризация за 5 сек, далее в скуле переименовываешь старую табличку на как и было, а пустышку дропаешь. Усё.

(14) как её включить?

нашел
https://infostart.ru/1c/articles/934237/

(3) других документов 100 штук в базе а этих 200 000.
например.

а как понять - по какой версии идет реструктуризация? поставили джаву, указал флаг UpdateDBCfg=v2 ?
как было 30 минут, так и осталось

(19) кластер серверов надо перезапустить(службу). Потом в пофигураторе конфа- обновить -на сервере.

Если не вклюае протокол tcp илиинет жабы,то напишет тебе об этом.

(20) вроде все так и не пишет ничего - но по времени разницы нет

(13) обмены и этот документ среди них? :)

(22) внизу в окошке сообщений должен писать что оптимизированный механизм бла бла бла..

Службу перезапущал?

(24) во ... а если не пишет - то не оптимизированный? тогда почему?

(25) да - два раза ..

Единственный минус, эту хрень не остановить. Она не предолжит потом как при v1 тебе окошко с изменениями.

пишет Обновляет конфигурацию базы данных и производит её реструктуризацию на сервере

(26) tcp включен в протоколах скуля?

(300 да

(30) где смотреть?

https://ibb.co/Drs6qfc

https://docs.microsoft.com/ru-ru/sql/relational-databases/sql-server-configuration-manager?view=sql-server-ver15

Полезная тема. В закладки.

(0) в чем проблема реструктуризации в течении часа? Это мелочь

(13) нет, это всего-лишь стандартная реструктуризация 1с. Платформа создаёт все новые пустые таблички объекта (шапка+ТЧ), с учетом изменений в метаданных, потом делает insert из старых табличек в новые, в конце грохает старые таблички

(33) в какой хоть файл прописал ...v2= ?

https://ibb.co/pJsDg4v

C:\Program Files\1cv8\conf - на сервере где 1С

(40) путь верный..
у меня вот так в нём
SystemLanguage=RU
DisableUnsafeActionProtection=.*;
UpdateDBCfg=v2

Это, версия платформы какая хоть ?

1С:Предприятие 8.3 (8.3.20.1549)

(43) ну не знаю..ради чистоты эксперимента, рестартани сервак целиком, что ле..

(33) Если сервер 1С стоит на этом же серваке: по shared memory не работает, нажимать обновить конфигурацию базы данных на сервере.

(45) наеборот же, работает

(46) https://its.1c.ru/db/v8320doc#bookmark:adm:TI000000376
● v2 ‑ оптимизированный механизм реструктуризации. Работает только для клиент-серверного варианта работы информационной базы в том случае, если в качестве СУБД используется Microsoft SQL Server или PostgreSQL. Если планируется использование оптимизированного механизма реструктуризации совместно с СУБД Microsoft SQL Server, то сервер «1С:Предприятия» для соединения с СУБД должен использовать сетевой протокол TCP/IP (в терминах СУБД). Работа оптимизированного механизма реструктуризации не поддерживается в том случае, если сервер «1С:Предприятия» подключается к СУБД Microsoft SQL Server с использованием сетевых протоколов Разделяемая память или Именованные каналы.

(47) вот, а отключить Shared Memory - не вариант

(47) ага, только на практике это не так.

(49) предлагаешь попробовать?

(49) Давай нажалуюсь :)

(50) отключи шаред мемори, рестартани скуль, проверь, есть ли v2, включи.
У меня v2 потом работало и с 2-мя включенными протоколами

(47) Странно. То есть предполагается, что java-приблуда будет переиспользовать соединение сервера. А такое возможно вообще? Может, достаточно чтобы tcp/ip был в разрешенных протоколах подключения?

(53) я не проверял shared memory, может в (52) сервер не перезагружали (как вариант)

при v2 если не включен tcp он напишет об этом.

(55) ну, судя по комментариям в (17) много ошибок, возможно и это пропустили

(55) Что v2 нужен tcp/ip - это понятно. Вопрос - поднимает ли v2 свое соединение или переиспользует соединение сервера. По контексту (47) предполагается что переиспользует серверное соединение. Если это так, тогда v2 на подключении shared memory подключиться не сможет физически. Но мне почему-то кажется, что на самом деле v2 поднимает свое соединение.

все перезагрузил - один фиг

https://ibb.co/phYpTck

Можно вот таким запросиком глянуть реальные протоколы соединений:

select program_name, net_transport
from sys.dm_exec_sessions as t1
left join sys.dm_exec_connections AS t2 ON t1.session_id=t2.session_id
where not t1.program_name is null

Ну и в профайлере видно.

(59) - везде TCP

(60) Ты над включением v2 бьешься? Сам не включал, но я бы проверил доступность java из командной строки под пользователем сервера 1С, ее версию и поставку.

java - vertion выполняет и показывает

(62) Что именно показывает?
Реструктуризацию запускаешь Конфигурация – Конфигурация базы данных – Обновить конфигурацию базы данных на сервере?
Если обычное F7, то как я понял всегда v1 будет.

(63) - см (58)

(64) в строке сообщения че пишет потом ?..он там подумает подумает и напишет что идёт реструктуризация с помощью оптимизированного механизма бла бла бла..

(65) не, про "опти" нет ни одного слова

(65) и как бы по F7 и по "Конфигурация – Конфигурация базы данных – Обновить конфигурацию базы данных на сервере" - одно время

Обновление конфигурации базы данных
Обработка структуры базы данных...
Сбор служебной информации...
Объект изменен: Документ.
Принятие изменений...
Обновление конфигурации базы данных успешно завершено

(68) не, это не то

во
после нескольких рестартов ...

В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине:
При попытке запуска Java в оптимизированном механизме обновления конфигурации базы данных возникла ошибка.
Путь к Java: C:\Program Files\Java\jre1.8.0_191\bin\java.exe
Действие: prepare

(70) о! уже более похоже на правду..

Самая ж..па, что оно потом всегда v2 будет делать..
:))

(72) и по F7?

ага - вижу , так ... как починить? что бы хоть что-нибудь заработало?

F7 - тоже "оптимизированный"

(73) не, по f7 старый метод, но тоже чегой-то иногда жабу хочет

(76) по F7 - он мне такую же ошибку выплюнул

(70) короче..если качал последнюю жабу, надо разрешить старый протокол

ща..

и похоже на V2 влияет конфиг локальный
когда прописал у себя на машине - начало ошибку выдавать
поставил
UpdateDBCfg=v1
стало обновлять по v1 хотя на сервере прописано v2

(80)

Go to folder C:\Program Files (x86)\Java\jre1.8.0_291\lib\security In file java.security find option jdk.tls.disabledAlgorithms and delete TLSv1

вот эту хрень сделай для своей версии жаба

должно вот так остаться

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, \
    DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
    include jdk.disabled.namedCurves

(81) Может лучше нормальную жабу взять с сайта 1С.

Мне интересно что там с режимом совместимости. Новая возможность появилась в 8.3.11
У меня сейчас 8.3.18 с режимом совместимости 8.3.10 - Будет работать или нет?

(70) в (17) в конце статьи написано про prepare: добавлен реквизит и произведена сортировка

(86) не - я ж ТЕСТИРУЮ
открыл док - изменил тип реквизита - запустил обновление - обновилось по v1

тот же реквизит вернул тип - перезапустил все - ничего не сортировал - получил ошибку

т.е. у меня в базе изменился ТОЛЬКО тип ОДНОГО реквизита - больше после последнего обновления с реструктуризацией ничего не изменял

(83) не помогло

В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка
по причине:
При попытке запуска Java в оптимизированном механизме обновления конфигурации базы данных возникла ошибка.
Путь к Java: C:\Program Files\Java\jre1.8.0_191\bin\java.exe
Действие: prepare

надо будет попробовать жабу с сайта 1С все-таки

и не понятно - почему на "оптимизированный" режим влияет конфиг не сервера, а клиентской машины

(0) Смириться и делать реструктуризацию в нерабочее вермя. Или плясать с бубнами. Вариантов много: от V2 до убийства 1С в процессе реструктуризации и последующего шаманства с реструктуризируемыми таблицами и таблицей config.

(88) у меня стоит jre1.8.0_311

(90) если просто добавить реквизит куда либо и запустить v2 , работает ?

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

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

(95) тогда меняй тип числового реквизита, просто уменьшив разряд, например

добавил реквизит - строка 10
реструктуризация (быстрая без обхода таблицы) - v1
включил v2 в локальном конфиге
поменял тип на число
F7 - критическая ошибка

включил v1
удалил реквизит
обновил
включил v2
добавил реквизит
F7 - критическая


в общем танцы с бубном отложим до версии жабы от 1С ... или 311