Есть рабочая база ERP 8.3.10, и ее копия для разработки и тестирования. Периодически возникает необходимость подгрузить новые данные из боевой в копию. Можно конечно полностью накатить сверху, но тогда надо будет отключать регламентные задания, подключать к хранилищу и т.д. что долго и не по канонам. Хотелось бы скриптом раз в неделю по ночам обновлять данные

Есть ли готовый рецепт для решения этой проблемы?

Обе базы на MS SQL, но на разных серверах

Написать скрипт по отключению регламентных, подключению к хранилищу и т.д.

Сделай РИБ с односторонней передачей данных )))

(3) И напиши скрипт по постоянному превращению его в ЦБ для разработки и обратно... (:

нифига не понял. причем тут регламентные? Они в базе для разработчиков и так отключены постоянно

(0) если в консоли 1С выключить рег задания 1 раз, больше не придется это делать

(1) почитай книжки по скл. есть такая штука как зеркалирование

(7) +1

(7), (8)
Как зеркалирование поможет в решении этой задачи? Т.е. настроил я зеркалирование, зашел в "копию" и грохнул все документы. Данные ушли в рабочую базу. Иначе это не зеркалирование.

Второй неприятный момент, это ограничение на создание новых справочников, доков, регистров, ПВХ. При создании будет ошибка типа:
Операция не может быть выполнена для базы данных "test", так как она участвует в сеансе зеркального отображения или группе доступности. Некоторые операции недопустимы для баз данных, участвующих в сеансе зеркального отображения или группе доступности.

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

Зеркалирование это raid-1 из мира дисков. Т.е. мы обращаемся не к конкретной базе, а к кластеру. И при выходе из строя одной базы юзеры ничего не заметят и начнут спокойно работать с зеркалом

(9) https://habrahabr.ru/post/126134/

В боевую ничего не попадёт, зеркалирование идёт из боевой

(11) это я читал, но не нашел там ни слово о том что "В боевую ничего не попадёт,"

(0) регламентые в разработческих базах должны быть отключены на уровне кластера. И - разработку на продуктивном кластере ведут только отъявленные мудаки. Создай отдельный для разработки, вот так:

sc create "ragent-dev@1641" binPath= "\"C:\Program Files\1cv8\8.3.blah-blah-blah\bin\ragent.exe\" /srvc /agent /regport 1640 /port 1641 /range 1660:1690 /d \"p:\ath\to\ragent\home\" /debug" start= auto obj=USR1CV8 password=pass displayname="Сервер 1С:Предприятия для разработки"  depend= Dnscache/Tcpip/Tcpip6/lanmanworkstation/lanmanserver

убедись отдельно, что на папку p:\ath\to\ragent\home\ у USR1CV8 есть полные права, иначе не запустится.


Постоянная потребность в свежих данных - нонсенс. Изобретать для этого что-то - тоже.

(13) для поиска методов устранения ошибок.

Ну допустим пришел бух и говорит, у меня в декларации по НДС нет номеров фактур. Вот тут и нужны актуальные данные чтобы с отладчиком посидеть понять откуда данные тянуться и накидать обработку по заполнению движения документа без перепроведения. А ведь еще эту обработку проверить надо. Не на боевой же проверять

(14) у нас еженощно делается (автоматически скриптом) копия боевой базы именно для таких целей

(0) Готового рецепта нет.
Для тестирования и отладки на боевых данных проще иметь отдельную базу для тестирования и периодически перезаливать её целиком средствами СУБД. Подключать её к хранилищу смысла нет.
В базе для разработки иметь актуальные данные нафиг не надо. А раз в квартал можно потратить час для того, чтобы перезалить базу свежими данными и переподключить к хранилищу.
Если написать для это скрипт, то можно делать это без отрыва от производства во внерабочее время.

(0) Рекомендую использовать две базы. Одну базу для разработки, вторую для анализа ошибок текущей версии.
Синхронизировать базу разработки и рабочую чревато проблемами с разработкой.
Пример.
Ведешь разработку и меняешь структуру данных. Приходит обращение что в рабочей базе ошибка на тех объектах метаданных по которым как-раз ведется разработка. И как синхронизировать базы?
У нас для поддержки база всегда ночью синхронизируется с рабочей путем развертывания бэкапа. Заодно и бэкап тестируется на работоспособность.

(16) (17) две базы тоже вариант. Спасибо за идею

(14) во-первых, это не отменяет всего, что я написал. Во-вторых, ежедневно такие вещи не происходят. ИЛи даже - часто.

А если обмен между ними настроить?

Кот-то может сказать "Он фанат РИБ" - и будет не совсем прав. Просто это удобный инструмент в данном конкретном случае.

Рабочая база выступает как центральная база, копия - в роли подчинённой базы.  ЦБ "накапливает" все изменения, но то, что именно передавать в ПБ - решает программист (удаляя "ненужные" регистрации изменений перед обменом). Одноноправленный обмен тоже легко реализуется - удалением всех регистраций изменений в ПБ перед обменом. Отличия от "обычного" РИБ, только в том, что не надо настраивать автообмен - всё вышесказанное нужно реализовать без внесения изменений в конфигурацию, - во внешней обработке (которая, собственно говоря, и будет вызывать сам сеанс обмена).

куерга на ровном месте

тестовая среда отдельно, база с подключением к хранилищу - отдельно

(22) Встретив несколько раз ошибки в боевой среде, которые не выявлялись в тестовой, - можно и мнение поменять :)

(23) нет таких ошибок.

а придумав обмен не обусловленный реальными потребностями - вы их создаете на ровном месте

Сейчас уже сложно найти, но пару раз было такое, что ошибка возникала только если база была подключена к хранилищу.

>ошибка возникала только если база была подключена к хранилищу

продакшен к хранилищу подключают только .удаки...

создание проблем "сами себе"

в "больших" средах на крупных проектах пограммисты вообще доступа к продакшену не имеют

По поводу (24)
Мне в принципе не интересно, где именно тестирует свои обработки Господин ПЖ, - я то их тестирую на актуальной копии.

(27) "в больших средах на крупных проектах" - это ключевые слова. А что делать тем, коих большинство, кого некоторые презрительно называете "ларёчниками"? :)