О, какие новости подвезли!
https://wonderland.v8.1c.ru/blog/uproshchenie-migratsii-mezhdu-subd/

Надо тестить

Это без остановки БД?

Мне нравится :-)
(2) Могли бы и так сделать, но это несколько сложнее.

(2) без остановки не будет консистентности.
Ибо же селект - инсерт

(4) без остановки делается через снимок и добивки по логу

Может кто реальную пользу по данному механизму расписать? Как бы вы его использовали на практике? Один раз, чтобы миграцию на другую субд сделать?

(6) попробуй мегрировать скуля например на постгри при размере базы 0.5 терабайта

(7) Я про это и говорю, это разовый инструмент, там где dt не вывозит, либо оочень долго

(7) пожалуй единственное применение

(7) а какое еще применение если именно эта задача и была?

(10) ну вот какая задача была - одному Борису известно, а вот на деле что получилось то получилось)

(11) задача переход с мс на постгре всзязи с ситуацией

(12) вы посвящены в истинные планы 1с?

(13)+ или вы занимались постановкой задачи для 1с?

Больше нечем заняться разрабам? Миграция между базами - крайне редко происходит - можно и подождать денек.

(6)Б удет поддерживаться как миграция между СУБД одного типа (например, из MS SQL Server в MS SQL Server),
т.е. копия для тестов и разработки же, или для поиска проблем

(13) это же очевидно

(16) так вроде в новую версию скуль итак дает мигрировать, а вот даунгрейд это да. Но вопрос, смысл на предприятии держать 2 версии скуля, если куплена новая версия?

(15) в дт иногда просто нельзя выгрузить никак

(16) а mdf ldf уже не копируются по простому, надо обязательно новый механизм? ))

а если разработка происходит в изолированной среде, то как туда сделать replicate?

(21) тогда веди разработку на тестовых примерах

(22) или просто сделать дт и передать аутсорсникам?)

(22) и что сб такое разрешает?

Постепенно ibcmd начинает жить собственной жизнью.
Потом(когда-нибудь), на этой основе сделают непрерывную и многопоточную репликацию, не зависящую от СУБД, приоденут в легкий, симпатичный GUI, по многочисленным просьбам трудящихся... Еще и продавать будут отдельно )

(24) смотря как договор оформлен и там же и бумажка есть по нераспространению и т.д. А еще базу можно обезличить перед тем как передавать. В общем решение есть, если очень хочется.

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

Есть конторы, которые практически полностью на аутсорсе, целый штат программистов может работать на контору.

(27) не всегда. Иногда даже сервера нет у разработчика, так как на внедрение будет покупаться новое железо и т.д. Я как-то внедрял для одного мед учреждения конфу, начальный этап работы был полностью во фране. Была передана обезличенная база, подписаны все бумажки о нераспространении. Когда уже более менее рабочий вариант был разработан, то уже доработки шли у клиента.

(25) >>приоденут в легкий, симпатичный GUI,
и лет через ... можно будет выполнять команду "copy 1Cv8.1cd"

(30) Именно. Руководствуясь подсказками ИИ.

(0) Это нужно большим конторам. Не представляю, кто из них захочет рискнуть, получив убитую таким переносом базу.

(7) >>попробуй мегрировать скуля например на постгри при размере базы 0.5 терабайта

Решаемая задача, но через область каловой проктологии: ты сначала катишь cf, потом первоначально настраиваешь базу по образу и подобию, потом через универсальную загрузку/выгрузку небольшими, подобранными эмпирическими значениями делишь выгрузку на куски и так грузишь. Так можно делать если есть технологическое окно. Если нет - придется возюкатся с РИБом и регой всего на узле.

То что предлагается, безусловно, давно ожидалось.

(33) через выгрузку/загрузку ты будешь месяц переносить большую базу, и скорее всего получишь на выходе невалидные данные

(33) Действительно решение каловое. Что мешает напрямую выгружать и загружать XML?

(35) речь о прямых sql запросах

(35) объемы данных мешают

(6) по мне так миграция из mssql в mssql не понятно зачем нужна, ведь репликацию сам сервер умеет или через бекап, а вот в посгрес действительно нужно, потому как в дт не всегда можно выгрузить

Остается в эту репликацию еще добавить правила РИБ и будет гм

(39)+ под правилами подразумевается условия переноса и синхронизации

(39)+ Хотя им придется это делать изначально.
Ведь в случае многопоточности надо как то понимать эта запись в таблице уже перенесена (в другом потоке) или еще нет.

Хорошая тема, а то на некоторых базах не такие большие тех.окна.
Перенести можно, но через планы обмена или подобные костыли с дозагрузкой данных.

(35) Типовая выгрузка-загрузка XML без допилов на большой таблице сожрет ОЗУ на сервере 1С и подвесит сервак.

(42) эээ сейчас прекрасно через sql бэкап можно переносить

(44)+ подразумевается выгрузка в текстовом формате аля "sql insert"

А такая миграция не подвесит сервак? Если 500 Гб базу попытаться перевести?
В ДТ-шник как то оно надежнее. А тут - хз крутится или нет. Сколько еще будет? Хз.

(46) дт не всегда выгружается

(47) если в DT уже не выгружается значит базе жопа настала и пора лечить

(47) а когда ДТ не выгружается? Может в этом случае надо бить тревогу и восстанавливать базу?

(41) скорее всего 1 поток = 1 таблица объекта. Вряд ли заморочились делить более детально

(38) у нас есть база которая крутится на последней версии SQL,

перенести на наши сервера SQL (более низкого релиза) мы не можем..... нам пришлось поднимать триальный сервер....

(50) слишком кривое решение
имхо задействовали встроенные средства субд
по типу first_row/last_row из bcp

(7) Пробовали УПП 850 Гб выгружать/загружать. 30 часов заняло, за выходные успели.
Зато механизм проверен временем и можно быть уверенным, что если распаковалось без ошибок, то скорее всего заработает.

Если механизм из (0) не позволяет реплицировать на горячую, то область применения не оч понятна.

(53) без горячей можно через бэкап

Без остановки базы только через планы обмена можно. Или нужно полноценную репликацию мастер слейв делать. Что явно не про этот инструмент

(6) ну я так понимаю, это сделали для текущих нужд, типа, будет волна миграций с вражеского MSSQL на православный Postgres Pro. И нужно чтобы процесс шел быстро :)

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

К этой теме нужна голосовалка и я бы тыкнул во что-нибудь что бы похвалить 1сников за движение в правильном направлении. Хотя как и все изменения, нужны они не каждому.

(57) Много кратно плюсую, 2 суток уже идет выгрузка базы весом около 1ТБ в файл DT, а потом еще грузить ....

(57) Вы уверены, что терабайт выгрузится в DT ?

(60) а почему нет? Я знаю лишь проблемы разворачивания такого ДТ в файловую базу

(0) как мало надо 1снику для счастья, всего лишь дать инструмент 10-летней давности и он уже писается под себя от шастя

(62) Ты сам внедряешь в большинстве случаев то, что уже придумано 10-20-30 лет назад в другой программе другими людьми, только писаются от счастья - клиенты. Что в этом такого? Если в ладу добавят круиз контроль и кондёр это не сделает эти изобретения менее полезными, хотя их придумали 50 лет назад.

(63) так я и не спорю, бро. 1С настолько "щедра" к разработчикам, что даже кость с барского плеча - удача.

(64) ты странный паря... Ты ж со всего этого кормишься, какой смысл срать там где ешь? Ну не нужен тебе этот инструмент - не пользуйся, всего и делов...

Как раз под импортозамещение.

Хоть какое-то движение со стороны 1С.

(63) Ты не поверишь, в Ладе круиз-контроль есть как минимум с 14-го года, а кондер появился уже на "десятках" точно, а может и раньше. Что за привычка вредная хаить все нашенское.