Подготовка копии рабочей базы для разработчика

1. o.nikolaev 214 07.02.22 12:37 Сейчас в теме
Коллеги, подскажите пожалуйста, кому-то приходилось заниматься задачей подготовки "урезанной" копии информационной базы "для разработчика".

Дано:
- очень большая информационная база 1С на SQL Server (~5Тб).

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

Ключевые требования:
- контроль ссылочной целостности;
- скорость подготовки копии, сейчас копия готовится несколько суток, требуется большая оперативность - хотя бы несколько часов.

Приходилось кому-то решать подобную задачу? Можете посоветовать материалы для изучения? Может быть в eng сегменте есть какие-то статьи или обсуждения (к сожалению ничего внятного найти не смог).
По теме из базы знаний
Вознаграждение за ответ
Показать полностью
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
41. gybson 10.02.22 17:45 Сейчас в теме
(1)Через КД2 сгенерить правила обмена и выгрузить несколько документов явно, а остальное по ссылкам в них.
Ну и там константы, еще что-то допилить. В целом должно быть не сложно.
o.nikolaev; +1 Ответить
42. o.nikolaev 214 11.02.22 12:24 Сейчас в теме
(41) Спасибо! Да, этот вариант тоже прорабатывается.
2. MazhutkoAV 07.02.22 12:43 Сейчас в теме
В моём понимании основной объём базы от регистров. 5 Тб в SQL это скорее всего с какими то логами?! Я как то наблюдал, что база выгруженная средствами 1С и загруженная в новое место теряла в весе больше 90%.

Мне кажется можно существенно сократить базу если выгрузить базу без регистров накопления, без бухгалтерских регистров.

А что за конфигурация?
o.nikolaev; +1 Ответить
4. o.nikolaev 214 07.02.22 12:57 Сейчас в теме
(2) 1С:Управление холдингом.
Логи предварительно очищаются и некоторые другие вспомогательные данные тоже, но все равно, оставшихся данных очень много и подход delete from where занимает очень много времени и, самое главное, не реализует сейчас условие по ссылочной целостности.
36. gybson 09.02.22 22:53 Сейчас в теме
(4)В УХ нет лишнего. Там вся инфа в нескольких регистрах сведений. Она по сути своей и тому, как она сделана, проблема. Большая проблема. Архитектура УХ не следует вообще никаким правилам и стандартам. Это разгул фантазии и бескомпетентности. Оторвать и выбросить.

Смиритесь.

Серьезно. Ужасная поделка с нарушениями всех норм.
o.nikolaev; +1 Ответить
37. o.nikolaev 214 10.02.22 14:46 Сейчас в теме
(36) Спасибо! Ваше мнение видимо очень выстрадано :)
40. o.nikolaev 214 10.02.22 14:50 Сейчас в теме
(36) Мне УХ-а нравится между прочим :) Хотя конечно в ней много чего можно улучшить :)
3. starjevschik 07.02.22 12:54 Сейчас в теме
Я бы, пожалуй, сделал кучку правил обмена для разных наборов данных и выгружал бы за какой-то ограниченный промежуток времени документы.
Идея вырезать из базы кусок без части объектов метаданных и ничего не порушить выглядит утопично.
o.nikolaev; +1 Ответить
6. o.nikolaev 214 07.02.22 13:00 Сейчас в теме
(3) Спасибо за ответ!

Да, этот вариант тоже рассматривается. Проблема: придется постоянно поддерживать актуальность правил обмена - структура метаданных меняется достаточно часто. Также - в том случае, если допустим требуется подготовить "почти полную копию" - для целей НТ (нагрузочного тестирование) то потребуется перегонять слишком большой объем данных, в этом случае представляется что оптимальнее будет удалить ту часть данных которая не нужна.
5. dehro 5 07.02.22 12:58 Сейчас в теме
(0) Там файлов небось много сохранено.

В копии разработчика должно быть максимум 10 документов каждого типа.

Я бы сделал так: По конфигурации создал бы пустою базу. Перенёс бы константы, "настроечные" регистры сведений и пользователей с правами.
Выгрузил бы в dt для возможности разворачивания новой копии.
Всё.

Если нужно какой-то особенный документ в копии: через КД2 генерим автоматические правила, Переносим из рабочей с сохранением зависимостей.
o.nikolaev; +1 Ответить
7. o.nikolaev 214 07.02.22 13:03 Сейчас в теме
(5) Файлы хранятся на внешних томах.

>> В копии разработчика должно быть максимум 10 документов каждого типа.

Требования бывают разные, спасибо за замечание - не анализировали пока "профиль базы" в зависимости от подсистемы.

>> Если нужно какой-то особенный документ в копии: через КД2 генерим автоматические правила,
>> Переносим из рабочей с сохранением зависимостей.

Желательно чтобы процесс был автоматизирован: условно говоря - разработчик создает "задание" (описывает данные которые ему потребуются в базе, система выполняет подготовку базы с данными нужного состава).
10. ishelper 07.02.22 13:12 Сейчас в теме
(7)
Желательно чтобы процесс был автоматизирован: условно говоря - разработчик создает "задание" (описывает данные которые ему потребуются в базе, система выполняет подготовку базы с данными нужного состава).
Каким образом представляете себе описание задания? Не в Word'е же?

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

У вас есть разработчики, которые могут/будут этим заниматься? Или конфигурация должна внезапно появиться сама по себе, как джин из бутылки?
11. o.nikolaev 214 07.02.22 13:14 Сейчас в теме
(10) Спасибо за ответ!

>> Для этого нужно создавать специальную программу (например, конфигурацию 1С), а потом долго ее допиливать и перепиливать, по мере конкретизации исходных общих пожеланий и появления новых хотелок.

Да, все верно - планируется разработка инструмента вида "сервис подготовки базы для разработчика".
12. nomad_irk 76 07.02.22 13:17 Сейчас в теме
(11)В таком случае могу предложить использовать функционал https://infostart.ru/public/1125435/ в качестве отправной точки для реализации.
14. o.nikolaev 214 07.02.22 13:19 Сейчас в теме
(12) Отлично, спасибо, обязательно скачаю и посмотрю!
16. ishelper 07.02.22 13:22 Сейчас в теме
(11)
планируется разработка инструмента
Ну, так очевидно, что алгоритм работы этого сервиса не может быть универсальным (да еще и быстрым!) для разных вариантов ТЗ: или быстро делаем сильно урезанную базку, или - "почти полную копию".

Аналогично: чтобы наковырять немного земли из огромной кучи, достаточно лопаты, а чтобы переместить "почти всю" кучу - нужны экскаватор и грузовик... разумеется, если надо сделать это быстро, а не за время, сравнимое со строительством пирамид. :-)
19. o.nikolaev 214 07.02.22 13:27 Сейчас в теме
(16) Вы зрите в корень! Задача сложная, вначале казалась легкой, но после наскока и набивки шишек уже не кажется такой :) Потому и создано это сообщение-обращение к community.
8. GeraltSnow 174 07.02.22 13:08 Сейчас в теме
Я в подобной ситуации генерировал запрос на truncate таблиц всех документов, справочников и регистров накопления.
Пример:
USE [Database]
SEL ECT 'TRUNCATE TABLE ' + name FR OM sys.objects WHERE type in (N'U') and name LIKE '%Document%'

Результат скопировать и выполнить как новый запрос.

Если нужно почистить таблицы точечно, например удалить только контрагентов, то можно воспользовался инструментами разработчика. Там есть функционал выполнения прямых запросов truncate с отбором по таблицам.
9. o.nikolaev 214 07.02.22 13:10 Сейчас в теме
(8) В данном случае требуется оставить часть данных таблиц документов, справочников и регистров. truncate очищает таблицу полностью. Требуется удалить только часть данных.
13. GeraltSnow 174 07.02.22 13:18 Сейчас в теме
(9) После подобной чистки нужные данные из рабочей базы можно переносить при помощи обработки ЗагрузкаВыгрузкаДанныхXML с ИТС без каких либо правил обмена, т.к. конфигурации идентичны.

Как по мне это самый простой и быстрый способ.
Дмитрий74Чел; o.nikolaev; +2 Ответить
17. o.nikolaev 214 07.02.22 13:23 Сейчас в теме
(13) Да, спасибо, комплексный подход тоже рассматривается.
15. user-z99999 70 07.02.22 13:19 Сейчас в теме
очень большая информационная база 1С на SQL Server (~5Тб).

А что много места занимает?
Посмотрите информацию о размерах таблиц базы данных на SQL.

А далее, на sql создавайте скрипты
1) сделать копию базы
2) обрезать таблицы
2 а) из существующей таблицы скопировать данные в Новую таблицу, за период (фильтр по Дате или Период)
2 б) удалить старую таблицу (TRUNCATE TABLE)
2 в) переименовать новую таблицу в старую (для этого предварительно нужно запоминать как называлась старая таблица)
и так для каждого регистра (посмотрите какие вам нужны, начинайте с самых больших по размеру)

Основу всех скриптов пишем в ms sql
А из кода 1с получаем названия названия таблиц и генерим скрипт.
18. o.nikolaev 214 07.02.22 13:25 Сейчас в теме
(15) Благодарю за ответ!

Исходный объем ~5Тб.
На данном этапе прикидки - уже есть наброски системы - именно такие (генерация скриптов и их выполнение). Скорость к сожалению пока не устраивает.
20. user-z99999 70 07.02.22 13:33 Сейчас в теме
(18)
А обрезаете таблицы как у меня в пункте 2 написано?

Можно померить время каждого этапа в ваших скриптах, выполняйте частями. Найдете узкое место.
21. o.nikolaev 214 07.02.22 13:39 Сейчас в теме
(20)
>> А обрезаете таблицы как у меня в пункте 2 написано?
Насколько я знаю нет, выполняется delete без создания копии таблицы.

Да, замеры делаем.
22. user-z99999 70 07.02.22 14:32 Сейчас в теме
(21)
Насколько я знаю нет, выполняется delete без создания копии таблицы.

а нужно делать RENAME и TRUNCATE TABLE, это будет намного быстрее на больших таблицах.

Пример RENAME таблицы
EXEC sp_rename 'Sales.SalesTerritory', 'SalesTerr';
23. o.nikolaev 214 07.02.22 14:36 Сейчас в теме
(22) Спасибо! Учтем ваше замечание.
24. МихаилМ 08.02.22 11:36 Сейчас в теме
Для удаления можно задействовать схему данных. тогда согласованные данные удаляться автоматически
o.nikolaev; +1 Ответить
25. Onwardv 65 08.02.22 12:38 Сейчас в теме
(24) Да, тоже так считаю.
Был опыт с попыткой создания себе маленькой базы. Мучительно долго чистим таблицы. Потом добавляем нужные данные

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

Есть эталонная база, где минимум информации, чтобы можно было работать в режиме 1с предприятия.

Аналитик через спец. интерфейс быстро делает себе базу под каждую задачу (Пару кнопок):
(Делается копия эталонной базы и обновляется конфа с Git.)

Под конкретную задачу аналитик делает примеры документов, справочников и т.д. Задачу переводит на программиста. В задаче прямо конкретные ссылки на конкретные элементы (УФ это позволяют).
Пример: (для нового РН), при проведении документа (внешняя ссылка) должны появится такие-то движения. А при проведении документа (ссылка) этих движений быть не должно, т.к. такие-то условия не выполняются.

Программист делает копию этой подготовленной под задачу базы (пару кнопок в спец интерфейсе). Обновляет конфу своей базы из Gita и с ней работает.
После того, как закончил работу, выкладывает в GIT и переводит задачу на аналитика.

ИЗ ветки GIT-а по задаче (совпадает с номером задачи) делается cf-ник в Jenkins. Аналитик свою конфу обновляет этим cf-ником и проверяет. Пока не устранятся все ошибки, программист работает со своей базой и с веткой GIt. Как задача готова, она попадает в релиз. Релиз собирается опытным разрабом (или архитектором) из GIT. Тут м.б. конфликт веток и архитектор, иногда, может попросить опытного разраба устранить конфликты по своей задачке. Это бывает очень редко. Обычно архитектор сливает ветки GIT-а самостоятельно.

Через некоторое время ИБ аналитика и программиста удаляются. Обычно в имени используются номера задач. Так удобнее. (Можно и заменять, или продолжать в этой же, но всё это ведёт к непоняткам и ошибкам)

Оказалось важным, чтобы программист не делал разработку в базе аналитика. Часто были ошибки, т.е. в ИБ аналитика всё работает, а потом на проде ошибки (не всё попало в GIT).
И подготовка cf-ника аналитиком с помощью Jenkins из GIT-а также очень важна. Если программист cf-ник сделает со своей базы и аналитик обновиться с него, также м.б. ошибка в проде (опять не всё попало в GIT).
Ну и аналитик не должен работать с базой программиста.

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

Несмотря на наличие проблем, считаю такой подход самым правильным. Под каждую задачу - свой набор баз и окружения (например: БУХ+ЗУП + rabbit для задачки обмена бухии и зупа). Считай, что контейнер.
o.nikolaev; +1 Ответить
27. o.nikolaev 214 08.02.22 14:58 Сейчас в теме
(24) О, интересно! А можно поподробнее? Что вы имеете в виду?
30. Onwardv 65 08.02.22 21:02 Сейчас в теме
(27)
Непонятно, про что поподробнее рассказать.

Кстати был пост, критикующий подход удаления данных из полной копии, на который я и ответил, что согласен с критикой метода.
Т.е. взять огромную базу и постараться удалить не обязательные данные.
Минусы:
Если делать средствами 1С - то очень долго.
Если же средствами СУБД, то делается быстрее, но будут ошибки почти 100%.
И оно устаревает стремительно, если скриптом (обработкой) сделано.
И всё равно останется куча ненужной информации.

На мой взгляд, лучший подход:
К НИЧЕМУ добавить только очень НУЖНОЕ.

Даже обработка ЗагрузкаВыгрузкаДанныхXML позволяет это сделать и сохранить настройки для последующего использования.
Как пример: Выбрать документы за неделю, а все связанные данные ссылочного типа подтянутся. У Вас останутся только независимые РС.

Но есть нюанс для обработки. Метаданные должны быть одинаковы в обоих базах.
Там вроде бы можно грузить из конфигурации-предка, так сказать, (АрхивРабочейБазы) в конфигурацию-потомка: (ИБ_Разраб) . Но почти никогда без кучи ошибок не бывает.

Почти 100% алгоритм:
1) Из ИБ Архив выгружаем cf
2) Из ИБ_Разраб выгружаем cf (только при необходимости, если хранилище, то надо отключиться)
3) В ИБ_Разраб делаем "Загрузить конфигурацию из файла" и выбираем файл Архив.cf
4) Из ИБ Архив выгружаем обработкой нужные данные в xml. (Настройки сохраняем)
5) В ИБ_Разраб грузим обработкой данные из файла xml
6) Проверяем ИБ_Разраб, если что-то не так, то надо вернуться к п.4
7) В конфигурации ИБ_Разраб делаем "Загрузить конфигурацию из файла..." и выбираем файл ИБ_Разраб.cf. Или подключаемся к хранилищу и обновляемся с него.

9) Приятно удивляемся, как быстро всё работает и гордимся собой :)
o.nikolaev; +1 Ответить
31. o.nikolaev 214 08.02.22 22:01 Сейчас в теме
(30) :) Спасибо за дополнение! Подробнее рассказать я просил МихаилаМ :) Но он пока молчит.
34. МихаилМ 09.02.22 22:31 Сейчас в теме +1 $m
(27) Даже не знаю что подробнее. По метаданным создаете дерево взаимосвязей метаданных. Добавляете служебные (истории). На основе проекции метаданных на реальные таблицы бд создаете схему данных с поддержкой согласованного удаления. В этом случае при удалении записи документа SQL запросом будут удаляться согласованные данные.
o.nikolaev; +1 Ответить
38. o.nikolaev 214 10.02.22 14:47 Сейчас в теме
(34) Отлично! Это обсуждалось тоже. Скажите а у вас получился такой подход? Сколько времени заняло удаление? Какой был размер базы? Столкнулись ли с какими-то проблемами при добавлении большого количество foreign key constraints?
26. Onwardv 65 08.02.22 13:02 Сейчас в теме +1 $m
Но это такой системный подход к разработке. Требующий много сил.

Если же для пары человек, то на мой взгляд, необходимо
1. добиться запуска 1с в режиме Предприятия с голого cf-ника.
С помощью обработок обновления все минимально необходимые элементы должны появляться при запуске.

Т.е. сделали новую пустую ИБ, загрузили в конфигурацию cf-ник рабочей базы. Стартанули -> режим 1с предприятия загрузился.

2. Далее из большой рабочей базы делаете выгрузку необходимых данных в файл. Например, все документы за последнюю неделю и весь справочник организаций + весь справочник пользователей. Можно даже обработкой ЗагрузкаВыгрузкаДанныхXML.

3. И той же обработкой грузите данные из файла себе в базу.

Про 1-й пункт идея у меня возникла потом.
Я же делал так: нашёл старую маленькую базу из архива (за несколько лет назад), обновил cf-ник до рабочей версии, потом, неожиданно для меня, долго и упорно добивался чтобы оно в 1сПредприятии запускалось без ошибок.

Далее в цикле:
В ИБ последней копии рабочей в обработке ЗагрузкаВыгрузкаДанныхXML делал файл выгрузки с документами за последнюю неделю со связанными объектами. Настройку сохранял.
В подготовленную базу подгружал этот файл той же обработкой. Потом проверял и смотрел. Недостающие битые ссылки, РС и т.д. опять добавлял в настройки выгрузки и выгружал заново.

И оно всё-таки заработало. Маленькая быстрая база с актуальными данными. Но больше я не решился чистить. Так в эту базу свежие данные и добавлял периодически.
o.nikolaev; +1 Ответить
28. o.nikolaev 214 08.02.22 15:14 Сейчас в теме
(26) Спасибо! Шикарное описание. Такой вариант, по-моему, даже не рассматривали. Благодарю за идею!
29. Onwardv 65 08.02.22 20:29 Сейчас в теме
(26)

Как-то я не туда пост отправил.
Пост (26) планировался, как продолжение поста (25)
32. JohnGalt 58 09.02.22 12:15 Сейчас в теме
Размер достаточно внушительный. В любом случае нужно проанализировать какие таблицы больше всего занимают места, чтобы в будущем этим управлять.
1й вариант: РИБ. Создать начальный образ с минимальным набором НСИ (без документов и регистров) и далее дозаполнить обменом что нужно.
2й вариант. Уже упоминали ранее чистая база с актуальным cf. Риск конечно вообще не запустить есть)
3й вариант. Копия базы и последующая очистка всех больших таблиц. Документы можно оставить только свежие. Неактуальными данными можно и пренебречь вплоть до битых ссылок.
o.nikolaev; +1 Ответить
33. o.nikolaev 214 09.02.22 19:32 Сейчас в теме
(32) Спасибо за рекомендацию. Идея с обменом тоже обсуждается.
35. МихаилМ 09.02.22 22:34 Сейчас в теме
У Вас проблема не столько техническая сколько организационная . для бд лучше нанять dba. который будет готовить базы для разрабов.
o.nikolaev; +1 Ответить
39. o.nikolaev 214 10.02.22 14:48 Сейчас в теме
(35) Был. Но ушел :( А выкручиваться надо!
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот