Добрый день коллеги.
Поступила задача свернуть 1С ERP 2.4с условием, чтобы данные за последний год остались, а остальное исчезло. Хочу попросить вашей помощи, в выборе подхода к решению задачи.
Ниже подробное описание:
База - 400гб.
При запуске типовой обработки - время первого этапа свертки(создание документов ввода остатков) до первой ошибки 10-12 часов.
Технические характеристики сервера пока приводить не буду, не потому что бессмысленно, а потому что нет возможности их изменить и попробовать свертку на другом сервере.

Собственно вопрос, какой подход лучше выбрать:
1. Исправлять ошибки свертки, чтобы отработала типовая обработка( минус в том, что неизвестно сколько времени уйдет на это решение).
2. Создать свой механизм ввода остатков, и удалить лишние документы вручную? (возможно для ускорения рубануть их в sql?).

Возможно Вы предложите какой-то более эффективный подход? Заранее благодарю за внимание.

аминь

Могу предложить древнее заклинание "хусим". Помогает в 99% случаев

dixi

(2) с приставкой "да" не мощней будет?

(4) Это уже художественное излишество.
Можно усилить заклинание магией жеста, но тут есть опасность.

(0) 0. нанять спеца
1. сделать бэкап
2. выкинуть прикрепленные файлы в том
3. запустить ТиИ
4. выгрузить в dt
5. отдать dt спецу

(6) Нам выгрузку СКЛ давали

(7) на флешке? 400 гигов через инет тяжеловато

на 100 гб, далее через фтп

Далее 2 раза скачиваешь

Но тут свои услуги предлагать не буду

Пришлось правда восстанавливать кривизну настроек СКЛ сервера заказчика, но что поделать

интересно кто то юзает 1С на Oracle или IBM DB2 ?

На оракле точно да

(0) Отдать базу тому, кто решил, что свёртка действительно необходима и после неё будут достигнуты поставленные цели.

>> какой подход лучше выбрать.

Выбор подходов и методов должен зависеть от того зачем вы её (свёртку) делаете. Какие решаются при этом задачи.

>> Исправлять ошибки свертки ... неизвестно сколько времени уйдет на это решение.

То есть сколько времени уйдёт на "создать свой механизм ввода остатков, и удалить лишние документы вручную" вы точно знаете?
И сколько же? Мне просто интересно.

(13) Много лет назад видел УТ 10 на DB2. Потом они перешли на SQL - после этого при обменах в РБД стало больше(!) блокировок и начались страдания :)
А ЗУП вываливалась в ошибку при обновлениях, приходилось обновляться в файловой.

(15) от одного до 2-х человекомесяцев, что тут знать-то?

(17) угу а потом темы типа JOB: Вот вам и почасовка) Как правильно оценивать задачи в часах и разводить клиентов)

имхо развести у себя базы за 400гб без наличия вменяемого 1Сника на окладе это верх наивности (ну или жадности)

(18) Да пусть делают, мне не жалко

(19) Скорее СКЛщика

(21) СКЛщик тут как раз нахер не нужен уже давно
И он как раз походу и спрашивает

У меня для этой базы стенда нет, а спеца не проблема найти

(23) дык там просто "Настройки работы с файлами" и не проблема в стенде
имхо иным способом 400 гигов не получить
если что пакеты ЭДО тоже сча в прикрепленных файлах

А делать эти работы не на своем стенде, это к проблемам

(24) Для того чтобы открыть базу, ее надо развернуть, а для этого должна быть машинка, способная развернуть ;-)

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

(27) Ну бери работы ;-)

Потом расскажешь ;-)

(28) Если там интеркампани то точность результата не гарантируется

(24)[имхо иным способом 400 гигов не получить]
у нас, с безусловным выносом в тома,за 3 года под сотку ГБ набежало, переделов меньше 10 и выпусков в день не больше 30,
будь машиностроительный завод + торговый дом - было бы в 3-5 раз больше

Почувствуешь себя на этапе сдачи, дата майнером и дип анализ

(23) что так ?
терабайтный ssd - основа успеха аналитика

(31) я очень сомневаюсь что ERP у них дольше 6 лет
так что гигов 200 с натяжкой можно поверить

(33) ХЗ, всегда в 10 гб укладывался

(34) ты не прав, базы УПП и ERP  выше 500 Гбайт - рядовое явление

(35) да средняя база чисто данные (выкидываем все лишнее типа комментариев и прочего изврата) обычно в 10гб влазит

(35) для продуктива это не размер

(36) обычно за счет прикрепленных файлов
и в виде sql
если выкинуть прикрепленные и сжать то будет сильно меньше

(38) Нафига мне продуктив держать у себя на компе? акстись

(39) не тупи

(39) Литрес у меня учился, там порядка 0,5кк реализаций

в месяц

(41) (42) 49,5 да?

Имхо на таких базах уже (19)

(45) Ну мне же заказывали работы ;-)

сворачивай каждый регистр отдельно
https://infostart.ru/public/392451/

Да и большинство компаний, идут по пути, обслуживание свое, специалитет наемный

(42) УТ?

(0) предлагаю альтернативу, сиквел ведь уже умеет партишен тейбл? что-б всё старьё не вынести на другой диск ииии и всё доступно и хлам есть не просит.

(49) УПП

+ биллинг

(52) Эээээ, а нафига-ж? У литреса разве есть своё пр-во?

(53) Последнее что все смотрят, в т.ч. и торги, на наличие блока производсва

(53) они из воздуха же делают - значит есть производство

(55) Зря смеешься, есть себестоимость часа, метра, и производство контента

(56) только вот налоги с производства не хотят платить

(57) Во вы любите считать за других кто что любит, а кто нет

(0) Какой срок? И бюджет? Можно и за 5 дней. Но лучше за 10. Нужен удаленный терминал, с 1С и пароль подключения к MS SQL.  Желательно иметь пару копий для тестов. Делал 180 гб за неделю до 40. удалял 6 лет.

(0) Сворачивал 140-180Гб базу за 8-12 часов (точно уже не помню), основное время заняло на скачивание базы, разворачивание у себя на ПК, т.к. на рабочем сервере не разрешили это делать, проблемы со старой СХД.
1. Штатно формируются документы ввода остатков.
2. Прямыми запросами по сворачиваемым регистрам создается копия таблицы, копируются туда записи за 6 месяцев, создаются индексы как в эталонной. Старая таблица удаляется, новая переименовывается как у старой.
3. Прямыми запросами помечаются документы на удаления без движений (таблицы документов и журналы документов > 6 месяцев).
4. Проводятся документы ввода остатков на нужную дату (штатная ставит 01.01.2021, а надо 31.12.2020).
Пользователи могут работать, фоновым по-тихоньку удаляются документы (удаление заняло около 10 дней).
Отладка обработки заняло дней 5-10 параллельно с текущими задачами.

(47) В бухгалтерии при свертке создаются документы ввода остатков по МЗ, ОС, НДС. Тут же все через корректировки регистров, потом нереально это исправлять. Конечно, можно запустить создание документов по-человечески после свертки таблиц.

(42) >> там порядка 0,5кк реализаций
это по-русски, сколько?...

(62) к = 1 000
кк = 1 000 000
ккк = 1 000 000 000
незнакомо?

(63) Ну, не все же играли в EVE-online

(0)
Что мешает
а) Сделать узел в полном обмене
б) сворачивать бд узла
в) в процессе сворачивание переливать новые данные и узел
г) после свертки и проверки подменяем основную базу на узел (делаем его главным, префиксы и бла-бла-бла)

P.S.
1) А что за ошибки возникают? Возможно базу уже так загадили кривыми руками, что и связываться не стоит
2) Если вместо сервера калькулятор, то наверное тоже нафиг-нафиг

это задолго до евы было) но приятно что разумная система была перенесена и туда, не знал.

(60) Добрый день, благодарю за ответ по теме.
Примерно так и думал действовать.

Интересно почему почти все предпочитают "удалять", когда часто намного проще и быстрее "скопировать"

(68)+ И даже штатно через предприятие можно без прямых запросов sql справиться в разумный срок

(68) Ну, например можно удалять регламентом, по чуть-чуть не особо нагружая базу.

(70) А смысла? Вот в (60) п.2 отличный! Но почему дальше так же не сделать?
Это намного шустрей чем по чуть-чуть

(67) Обратите внимание: индексов в создаваемых новых таблицах не будет (будет тормозить и их надо добавить как у эталонной) и в некоторых регистрах сведений период остается эталонным (не будет даты свертки).
(71) Чтобы битых ссылок не получить, можно добавить поиск ссылок запросами, но придется учитывать данные с учетом производительного режима, акта сверок и тд.

(0) 3. сделать ввод остатков и обрезание регистров многопоточными. Одно фоновое задание долбит один объект. И ты в шоколаде

(13) Oracle шибко дорогая. Развлечение только для крупных богатых контор, поэтому в мире 1с скорее редкость

(74) Oracle Database XE

(75) вот даже не смешно

(76) не более чем Microsoft SQL Server Express

(72) еще дополню: сделайте копию присоединенных файлов (если хранятся в томах диска).

(77) экспрессы зайдут разве что под маленькую нетленочку, юзаемую в ларьке под сервером-мини на 5 юзеров

(60) не тот объём, чтобы заморачиваться с прямыми запросами

(80) Окно 2 дня дали и 3 недели срок: 800 пользователей стабильно сидело в базе по всей РФ по 90 организациям. Поэтому только так.

(81) Сначала сделай анализ: какие таблицы жрут место и что имеет смысл удалять. Дальше - дело техники, как в (60). (я так же делаю, только пересоздание индексов делать не рискнул, а делаю truncate старой таблицы и возвращаю записи обратно).

(81) сервер то полноценная копия боевой?

(60)(80)(81) >> Сворачивал 140-180Гб базу.
>> не тот объём, чтобы заморачиваться.

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

(82) Очистка таблицы тоже хороший вариант.
(83) не понял вопроса
(84) Начальству со стороны заказчика "специалист 1С" посоветовал свернуть базу для ускорения и они зацепились за эту идею. Конечно, свертка не помогла и я был против, но договор заключили наши менеджеры.
Проблема быстродействия в СХД, которое было подключено к серверам iSCSI 10Гбит по меди (рука-лицо), плюс на этой СХД крутилось еще с десяток других систем.

(85) Опыт высококлассных спецов оплачивается именно такими задачами, ничего страшного нет