По теме из базы знаний
- Использование Web-сервисов для синхронизации баз данных в режиме online 1С8.2 (8.1) .
- DBCC CHECKDB оповещение о повреждении баз данных SQL
- Создание базы данных Firebird (при небольших доработках любой sql базы) на основании метаданных 1С. Заполнение данными. Выгрузка в JSON
- Помощник загрузки отчетности в разделенную базу данных 1С: БГУ 2.0 в корпоративном облаке 1cfresh
- От реляционной базы данных к единой таблице DynamoDB: пошаговое исследование
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
1. С помощью обработки пометить на удаление все данные по одной организации и удалить их.
2. Сделать РИБ, выгрузить организации в узлы и отвязать их от РИБа.
3. Удалить их с помощью обработки которая генерирует код для SQL сервера.
Не так давно разделял базы. 1 и 2 способы результата не дали, документооборот большой, что удаление данных, что выгрузка данных в узлы РИБа очень на долго задумывались...
Помог третий способ.
Подскажите, пжлста, как из БД удалить все документы по 4 БУ за 3 года.
1. С помощью обработки пометить на удаление все данные по одной организации и удалить их.
2. Сделать РИБ, выгрузить организации в узлы и отвязать их от РИБа.
3. Удалить их с помощью обработки которая генерирует код для SQL сервера.
Не так давно разделял базы. 1 и 2 способы результата не дали, документооборот большой, что удаление данных, что выгрузка данных в узлы РИБа очень на долго задумывались...
Помог третий способ.
Я бы рассмотрел 2 варианта:
1. Свернуть и выгрузить справочники и остатки в чистую базу
2. Создать РИБ и выгрузить в подчиненный узел данные по нужной организации, а потом отвязать.
вариант именно с удалением возможен, но потребует много ручной обработки.
1. Свернуть и выгрузить справочники и остатки в чистую базу
2. Создать РИБ и выгрузить в подчиненный узел данные по нужной организации, а потом отвязать.
вариант именно с удалением возможен, но потребует много ручной обработки.
(8) Для примера, что бы отделить одну организацию в нашей базе от остальных, удаляли все и вся что не связано с основной. Удаляли без проверки ссылочной целостности. Так вот, такое удаление занимало 12 часов, это просто операция удаления. А если по каждому объекту проверять, так вообще устанете ждать.
В свое время промучился с сильно дописаной базой ЗУП. В базе велся учет по 5 юр. лицам. Типовой юридический и самописный управленческий(много доп. справочников и документов). Плюс множество обменов со всем, что только можно было прикрутить.
Нужно было разделить этот ЗУП на 5 отдельных БД.
Пытался поначалу удалять данные консолью разработчика. Но даже на этапе начального контроля ссылок, отдельно выделенный сервер приложений с 32Гб падал с ошибкой нехватки оперативной памяти.
Пришлось написать обработку, которая перегоняет в БД SQL полную структуру базы ЗУПа с указанием связей между всеми таблицами.
Вторым шагом провел анализ данных, которые нельзя трогать, добавил исключения, настроил правила. Это самый трудозатратный этап, как и проверка данных после чистки базыю
Написал скрипт на t-sql, который удаляет данные в рекурсии по всем взаимосвязям по каждой таблице. Глубина рекурсивных вызовов правда ограничена 32-мя, но я с этим ограничением сталкивался только, если справочник ссылался сам на себя. Такие добавляются в исключения.
Скрипту достаточно было скормить список элементов любой таблицы, которые нужно удалить из базы, и он примерно за 16 минут успешно вычистил базу 90Гб, оставив данные только по одной Организации.
В итоге я получил документы с частично пустыми строками, если в одном документе были внесены сотрудники разных Организаций.
6 часов тестирования/исправления базы данных средствами конфигуратора с пересчетом итогов и красота! Чистая, сжатая база с чистыми документами без пустых строк. Итоги по всем регистрам сошлись с первого раза.
Процедуру деления и тестирования/исправления повторил для каждой Организации достаточно быстро, т.к. правила удаления данных для всех были одинаковы.
Нужно было разделить этот ЗУП на 5 отдельных БД.
Пытался поначалу удалять данные консолью разработчика. Но даже на этапе начального контроля ссылок, отдельно выделенный сервер приложений с 32Гб падал с ошибкой нехватки оперативной памяти.
Пришлось написать обработку, которая перегоняет в БД SQL полную структуру базы ЗУПа с указанием связей между всеми таблицами.
Вторым шагом провел анализ данных, которые нельзя трогать, добавил исключения, настроил правила. Это самый трудозатратный этап, как и проверка данных после чистки базыю
Написал скрипт на t-sql, который удаляет данные в рекурсии по всем взаимосвязям по каждой таблице. Глубина рекурсивных вызовов правда ограничена 32-мя, но я с этим ограничением сталкивался только, если справочник ссылался сам на себя. Такие добавляются в исключения.
Скрипту достаточно было скормить список элементов любой таблицы, которые нужно удалить из базы, и он примерно за 16 минут успешно вычистил базу 90Гб, оставив данные только по одной Организации.
В итоге я получил документы с частично пустыми строками, если в одном документе были внесены сотрудники разных Организаций.
6 часов тестирования/исправления базы данных средствами конфигуратора с пересчетом итогов и красота! Чистая, сжатая база с чистыми документами без пустых строк. Итоги по всем регистрам сошлись с первого раза.
Процедуру деления и тестирования/исправления повторил для каждой Организации достаточно быстро, т.к. правила удаления данных для всех были одинаковы.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот