Приветствую коллеги, интересно мнение многоуважаемой публики по этому вопросу.
На входе имеем большую УПП 1.2 база расположилась на внешней СХД и занимает около 700гб. (без учета лога транзакций, только файлы базы 30шт.)
В базе 24х7 работают 200-550 злых юзверей, когда пересекаются часовые пояса мск и дв число юзеров доходит до 520. Прерывать работу БД очень нежелательно.
При этом требуется свертка БД.
Я уверен, что технически возможно свернуть БД не прерывая работы пользователей, выполнив порционные запросы по очистке регистров на сиквеле, внеся остатки и удалив документы без движений из базы.
Если у кого есть подобный опыт и вы сталкивались с неприятными последствиями такой свертки, прошу поделиться :)

на семерке это реализовано!©
:-)))

(0) Не делал,но предложу. Переносить в другую базу регламентным заданием остатки и создаваемые документы с использованием Плана обмена для свёртки.

(0) В праздники НГ или 1 мая тоже вкалывают?

(3) у нас сервер останавливался только с 16-18 часов 31 декабря до 20 часов 1 января.. а в условиях 24*7 от нерезиновска до дальнего востока - и это время сильно сокращается...

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

(4) Я бы для такой схемы ставил фронт для работы пользователей. Что бы формировал только движение, остатки и взаиморасчеты Не закрывая по партиям. А уже с фронта грузил в базу. Тогда можно фронт спокойно резать "по живому".

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

делал копию, сворачивал, затем подгружал всю инфу за время работы свертки и переключал пользователей
на таких объемах поставил бы дату запрета редактирования задним числом на момент снятия копии

я бы пошел через последовательности.

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

такая обработка может крутится и месяц не мешая работе пользователям

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

У меня одно важное условие при выполнении этой задачи - необходимо оставить данные с 2014г. по тек. момент.
Все что раньше 14 - срезать (с 2006г.). При этом база должна быть онлайн.
Я решил поступить следующим образом:
- Зачищаю РНК (на стороне sql), по-одному на дату свертки.
- после зачистки каждого регистра ввожу корректировку записей регистров на момент свертки. Корректировка создается обменом из копии.
Учитывая что в моих условиях sql удаляет из РНК записи со скоростью 1млн/мин.
а корректировка загрузится за 2-3мин., свертка самых крупных РНК типа "ВзаиморасчетыСКонтрагентами" не займет больше 15мин.
и таким образом предстоит свернуть примерно 30 РНК, и один РБУ.
+ примерно 100 РСВ, но по ним итогов нет, остатки загружать не надо, их сверну одним заходом.

(10) я-бы не советовал так поступать, часть кода может быть ориентивана не на виртуальные таблицы остатков/оборотов а на физические записи в регистре.

ну а если будешь резать весь регистр - то у тебя документ корректировки может быть огромным,Ю особенно если регистры не закрываются как надо а расползаются по аналитике... в результате получишь документ корректировки с миллионом строк... и чего с ним будешь делать? а дробить при таком подходе - то же опасно...

проверь сначала, что там занимает эти 700 гб, может там 80% всего объема - итоги кривые.

опять же, зачищать оборотные рн можно прямо в рабочее время.

зачищать остаточные рн можно по дням порегистрово: по определенному регистру сформировали ввод остатокв и сразу удалили движения за предыдущий день(час, неделю).

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

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

Я фанат РИБ :) Развертываешь базу подчиненного узла альтернативным способом из копии. Это несложно и времени потребует почти столько же, как просто развернуть копию из архива.

Там, в базе подчиненного узла, не торопясь, со вкусом , проводишь свёртку... а потом быстро делаешь обмен.

Фсё :)

(11) так и есть, почти все РНК не закрываются полноценно, те-же взаиморасчеты не закрываются по сделкам или докам расчетов...
Код ориентированный на таблицы записей обычно привязан к периоду, для всех будет очевидно что за период ранее 14го, в базе ничего не будет.
(12) с оборотными никаких вопросов, я уже на копии проверил как они зачищаются - все ровно.
700гб заняты основными таблицами партии, расчеты, движения ДС, заказы с корректировками, и немного вложений файлов...
(13) Пересчет итогов конечно понадобится, но и пройдет он намного быстрее чем это происходит сейчас. В воскресенье я еще могу закрыть базу на лопату на несколько часов...
(14) Хорошая идея... главное не менять конфигурацию пока не прошел обмен :)

(15) В принципе, можно менять конфигурацию.

В центральной очищаешь всю регистрацию, обновляешь конфигурацию и делаешь запись сообщения обмена для подчинённого узла.
В подчинённом узле обработкой читаешь регистрацию изменений; сохраняешь где-нибудь "во вне"; очищаешь регистрацию; проводишь обмен (загрузку/выгрузку); восстанавливаешь регистрацию.
В центральном узле делаешь чтение сообщения обмена от подчиненного узла.

Несложная арифметика :)

(16) все так, безвыходной ситуации здесь конечно нет, но когда на регистрацию встает 2000-3000 заказов и реализаций каждый день, все описанные выше манипуляции могут заметно подпортить настроение, та-же выгрузка/загрузка регистрации в xml

Вообще, я все больше склоняюсь к варианту с РБД, там сколько угодно можно базу блокировать, ТИИ крутить и никто не помешает :)

Угу, ты прав. Растягивать надолго процесс свёртки нежелательно. Только по объективным причинам.

(17) А как собираешься решать проблему обменов? При загрузки в центр оно будет блокировать. Грузить частями по умолчанию не получится. Нельзя прервать на полпути

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

хм. неделю назад запросил КП у одной из фирм из МСК, на свертку УТ10.3 (не особо дописанной). Размер БД - 80Гб.
В общем запросили 350к. Вот думаю....

(19) а не надо в центр грузить. только из центра. и после обрезки и последней загрузки - замена БД

(21) ну наверное, эти 350к выражены в каком-то списке работ и почасовой раскладке на каждую из них? Можно поспорить и они наверняка свой ценник уменьшат.

Вопрос к Trance_1C

А какой эффект ожидают поиметь от этой процедуры "все свернуть и поделить" ?

Вангую, что этот же эффект не всем будет нужен и далеко не все его заметят.

(23) приведу несколько этапов которые они оценили.
1) Анализ текущей информационной системы и разработка методики свертки объектов ИС - 54к

2) Разработка инструментария свертки ИС - 144к.


Ладно еще если УТ 10 у нас была бы сильно допилена. Так там Полностью типовой функционал, разве что есть 1 свой регистр накопления.

(25) Так пункт 2 зависит от пункта 1. Поэтому выставили по максимуму. Или ты хотел увидеть вилку?

а еще есть секционирование
https://msdn.microsoft.com/ru-ru/library/ms190787.aspx

(21)(25)  эх, а я, лошара, за 2 выходных 200 гиговую упп переписанную сворачивал самописными многопотоковыми обработками (стандартная свертка раз в 5 медленнее работает)

(25) // Анализ текущей информационной системы и разработка методики свертки объектов ИС - 54к

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

Ну нормально все и выставили, если внутри вилки почасового тарифа 54к оказались сопоставимы примерно с 25-30 часов на проведение Анализа.

Или тебе хочется найти того, кто сдемпенгует от этой оценки в меньшую сторону и в три раза меньше возьмет в рублях?

к 29 допишу

Но я не удивлюсь,, если в процессе выяснится, что 25 часов анализ и 25 составление методики, если это рассматривается крупная контора, а не решение всех проблем внутри квартир подходом "муж на час". Имеем отдельного Аналитика - тот свою выработку крутит. И отдельного разработчика - у которого своя выработка. В итогах идет впечатление о завышенных оценках, которые должны покрыть все издержки компании-внедренца

(10) "Корректировка создается обменом из копии."
Лучше так:
1) Создаешь корректировку с Выключенными движениями
2) После обрезания включаешь движения.

+(31) речь про "активность" записей

1 ) однозначно в основной базе (с учетом такого и объема и всего) не получиться делать поиск и удаление объектов .....
2 ) да есть,  скульные свертки , а есть очистки базы
вот пример http://catalog.mista.ru/public/122546/

3) 700 гиг конечно не щутки (врать не буду с таким объемом да же близко не сталкивался)

4) какие таблицы самые большие ?
Делал свертку в одной конторе ,  по удалял рег. сведений и оборотные регистры , по мелочи док которые не влияют на движения (счет с\ф и т.д - для меня....), удалил табличные части документов (движения оставил), был удивлен что места много занимает журналы ...  и этого хватило !!!

а вот этой очисткой можно удалить из журналов....

(30) спасибо. в общем все наверное именно так как вы расписали. Внедренцы полностью покрыли свои расходы.

(0) сколько в среднем в минуту добавляется/изменяется справочников и документов ?