Внешняя обработка для быстрой реструктуризации клиент-серверной базы данных.
Способ ускорения реструктуризации - замена таблиц большого объема пустыми копиями перед проведением обновления БД и возврат к исходным таблицам после обновления с предварительной корректировкой их структуры.
Полностью автоматизировано создание и выполнение всех требуемых скриптов SQL. Представлены версии обработки для обычных форм (1С:Предприятие 8.2 (8.2.19.130)) и управляемого приложения (1С:Предприятие 8.3 (8.3.9.1818)).
(1) не вижу проблемы: пункт 65 и предложенная идея не связаны друг с другом.
да и вообще, относитесь к этим пунктам с долей критичности, а не к реально действующему механизму.
поясню: некоторые пункты технически не реализованы, но прописаны. К примеру, при установке доп.лицензии платформа ее определяет как полноценную лицензию и не различает, что основной лицензии нет в локальной сети. То есть на второй компьютер ставите доп.лицензию, и платформа+конфигурация запустится, не проверив наличие лицензии основной поставки.
пункт 65 и предложенная идея не связаны друг с другом.
Ну как же не связаны, если в явном виде написано, что нельзя обращаться к данным таблиц СУБД и их структурам прямыми запросами и необходимо использовать только штатные средства платформы 1С, лукавите ;)
(13) идея предложенного метода заключена в том, чтобы делать копию типовых таблиц, например, типовой таблицы "Файлы". Типовую таблицу "Файлы" после копирования в другую таблицу надо очистить, чтобы она осталась пустой.
Далее провести обновление и далее скопировать (вернуть) данные в типовую таблицу.
Это вот такая идея.
Сама идея никаких правил лицензирования не нарушает.
А вот способы реализации - пусть каждый сам выбирает - на свой страх и риск поломать базу - тут фирма -разработчик ответственности не несет и предупреждает, что все что не документировано, то использовать нельзя.
Уж не знаю какие мотивы были так написать: то ли перестраховать себя от нежелательных возможных дальнейших разбирательств со стороны клиентов, то ли реально будут наказывать (хотя это процессуально сделать не реально)...
Относитесь к этим пунктам лицензирования критично - то есть с долей скепсиса, а вот к проблемам обновления из-за подобных типовых таблиц "Файлы", когда они наполнены данными - более серьезно. Я сталкивался с подобным. Но только с файловой базой.
(24) Ну Вы же понимаете, что очистка и копирование данных в таблицы - это чтение и изменение данных таблиц БД, о которых и идет речь в этом пункте лицензирования, поэтому это есть нарушение этих правил, но я ни в коем случае не говорю о том, что их следует придерживаться в убыток бизнесу или же тем более в случае отсутствия какого-либо другого альтернативного решения возникшей проблемы, приводящей к невозможности нормального ведения бизнеса.
(27) в пункте написано хитро "что не задокументировано, то использовать нельзя"...
есть пункты (про доп.лицензии например), которые задокументированы, но на уровне платформы технически не доработаны...
значит ли это, что остальные пункты (в том числе ваш) утрачивают силу?
речь идет о том, что платформа не доработана таким образом, что часть функций нельзя сейчас задокументировать, поэтому это использовать сейчас нельзя, но в будущем обязательно все задокументируют, когда платформу доработают....
и тогда можно будет использовать .... так может и сейчас можно?!
(28) Там написано не хитро, а довольно прямо указано следующим текстом:
Нельзя обращаться к данным информационной базы напрямую, минуя уровень объектов работы с данными "1С:Предприятия", например при помощи средств СУБД или при помощи внешних компонент, которые реализуют прямой доступ к СУБД.
То бишь работать с ИБ 1С при помощи прямых SQL-запросов правилами запрещается, другое дело на сколько эти правила соответствуют реалиям
и тогда можно будет использовать .... так может и сейчас можно?!
Можно и сейчас использовать, только не факт, что это использование в будущем не приведет к негативным последствиям, допустим, при переходе на новую версию платформы или изменений в используемых конфигурациях
Данное ограничение необходимо для обеспечения стабильности работы механизмов системы, осуществления поддержки и возможности перехода на новые версии "1С:Предприятия".
(11) Вы между строк читаете?
Читая и изменяя таблицы СУБД напрямую тот, кто использует сей механизм нарушает лицензионное соглашение. Об этом как минимум надо предупреждать, чтобы те, кто не хочет, чтобы 1С отказалась от поддержки их компаний при их следующем обращении в саппорт, подумали, перед тем как использовать такие манипуляции.
(14)
1. Вы обращались в саппорт 1С? Если да, то как часто и по каким вопросам? И каков результат?
2. Чем плоха реструктуризация средствами SQL, если после нее все работает?
3. Вы пробовали большие таблицы(>50Гб хотя бы) реструктуризировать новым механизмом? Думаю, что нет.
Представьте себе компанию, которая работает 24/7 и как Вы думаете, позволит бизнес технологическое окно часов в 8? Сколько будет стоить такое окно?
И да, судя по отзывам коллег, которые пробовали новый механизм, остались недовольны. Приплюсуйте сюда стоимость потери базы и восстановления ее из бэкапа
(15)
1. Конечно. Крайне положительно. Особенно КОРП поддержка.
2. Работает и работает с гарантией вендора - это разные вещи.
3. Конечно, в т.ч. террабайтные базы.
4. 8 часов - это очень много. Фоновая реструктуризация столько не требует, потому что на то она и фоновая, что не прерывает работу пользователей в процессе реструктуризации базы. См. документацию https://its.1c.ru/db/v8316doc#bookmark:dev:TI000000063
Фоновая реструктуризация выполняется в несколько фаз:
1. Фаза обработки (пользователи могут работать с информационной базой)
2. Фаза актуализации (пользователи могут работать с информационной базой)
3. Фаза принятия изменений (пользователи не могут работать с информационной базой)
Фоновое обновление может выполняться с закрытым конфигуратором.
Можно даже сервер погасить и поставить обновление на паузу, а потом продолжить.
(17)Хочется верить, но почему то не покидает ощущение, что Вы теоретик.
Особенно: "Крайне положительно"
И особенно, что Вы реструктуризировали не только большие базы, но в первую очередь большие таблицы новой методикой. Вот коллеги мне рассказали, что новые веяния крайне сырые. И я им верю, потому что а) обманывать им незачем б) мы периодически обмениваемся новыми знаниями
Ну да ладно, спор бесполезен, удачи и целых таблиц.
(33)только вот разработчик платформы может и не знать БСП. Да и я так и не понял, причем тут БСП? При обновлении/реструктуризации код 1С вообще не исполняется. Работают только платформенные механизмы, которые шлют СУБД запросы для изменения структуры таблиц
(17) хорошо, что мнения разные. картина мира тоже у всех своя. напишите, пож-та , в каком городе вы работаете, какие конфигурации на ИТС-сопровождении? Какой франчайзи 1с вас обслуживает?
(14)Зачастую, конфигурации, с которыми приходится работать - существенно измененные под нужды предприятия типовые, либо вовсе самописные. Их перевод на новую платформу, как правило, достаточно длительный и трудоемкий процесс. Запускать многомесячный проект переезда на другую платформу ради ускорения возможной реструктуризации - не самое рациональное решение.
(2) " в последних версиях платформы"? интересно посмотреть на человека, который работает с последними версиями платформы. Я так привык, что последнюю версию на сегодняшний день я начинаю тестить не ранее чем через год-два.... и то благодаря типовой БП 3.0, и то "не испытываю", а просто ставлю...
Фоновая реструктуризация в старых версиях платформы часто (более одного раза точно) приводила к очистке таблиц. Вот была таблица с примерно лярдом файлов (может даже два лярда - да, и такое бывает), а потом она внезапно оказалась пустой. Реструктуризация этого всего (файлы не хранятся в базе - они отдельно, а реструктуризация из-за того, что тип владельца меняется - новый справочник появился или документ, к которому можно крепить файлы) - две недели. Что он там делает - хрен положить, но для бизнеса, который работает 24/7 на 1С (да, это ошибка - ежу понятно) ждать доступность таблицы с файлами в районе 2-х недель - это как-то бредово звучит, ч учетом того, что абсолютно ничего не меняется в таблице - тупая 1С читает, удаляет и записывает ровно одно и то же.
Так вот после такого ни один здоровый умственно человек не будет даже смотреть в сторону идиотского 65-го пункта соглашения с непонятно какими санкциями, а просто возьмет и сделает как настоящий мужик - переименует таблицу, создаст пустую, запустит реструктуризацию, после чего переименует таблицу назад.
То, что 1С-неги в последних версиях платформы с этим что-то сделали - это радует. Давно пора.
(21) и документы гораздо прогнозируемее реструктуризировать отбросив табличные части. Никогда не понимал фишки, зачем трогать табличные части, если изменения только в шапке
(22) это не в понимании дело - это в трактовке согласованности из ACID: читаем объекты целиком, меняем из в соответствии со схемой миграции (изменений) и записываем целиком в транзакции взад. Но, видимо, прхитехтор букву закона про согласованность выучил, тест сдал, а подумать забыл - вот и реализуется подобная схема целиком (чтобы не нарушать отчетности принципа ACID). Думать на курсах, к сожалению не учат.
Начиная с платформы версии 8.3.11.2867 1С оптимизировала типовой алгоритм реструктуризации, поэтому разработка наиболее актуальна для более ранних версий 8.3 и 8.2.
Доброе время суток. Насколько я понимаю типовой механизм реструктуризации был оптимизирован только для КОРП лицензий? Таким образом ваша обработка актуальна для обычных лицензий?
Работает, удобно.
В обработке для обычных форм кнопка "Завершить реструктуризацию" не привязана ни к одной процедуре. Собственно процедуры завершения тоже нет. Создать её проблем никаких, но лучше поправить.
есть проблема с реструктуризацией журналов.
делаю копии таблиц обработкой, при обновлении конфигуратор начинает реструктуризацию, запросом вижу, что заполняет пустые таблицы записями. 112 млн (((
платформа 8.3.16.1063.
Дмитрий, подскажите, а удаление реквизитов (столбцов таблиц) можно проводить с помощью вашей обработки?.
У меня, при удалении реквизитов выдает ошибку о ссылках на данную колонку.
"Не удалось завершить реструктуризацию:
ALTER TABLE DROP COLUMN _Fld33997RRef failed because one or more objects access this column."