Доброго дня, коллеги!
Стоит вопрос по очистке регистра цен.
Начальные данные задачи
Регистр сведений "Цены", подчинен регистратору, набор измерений ТипЦен, Номенклатура, ХарактеристикаНоменклатуры, ЕдиницаИзмерения, ПодразделениеКомпании, Контрагент.
Количество записей: 53кк
Размер таблицы: 35гб (из них индексы этой таблицы 27гб) плюс сам документ 14 гигов, при том, что размер базы 80гб.
Что нужно сделать
Было решено оставить последнюю цену (разумеется, в разрезе групп измерений) и удалить все имеющиеся с 2008 года.
Вопрос к знатокам - как правильно методически выполнить сию задачу?
Сейчас у меня кроме как создать обработку на создание документа "изменение цен" с последним срезом цен (на текущую дату) и удалить все старые записи (правда ещё стоит вопрос, как это делать... уж точно не средствами 1с).
Просьба помочь, пнуть в нужную сторону, дать совет...
Стоит вопрос по очистке регистра цен.
Начальные данные задачи
Регистр сведений "Цены", подчинен регистратору, набор измерений ТипЦен, Номенклатура, ХарактеристикаНоменклатуры, ЕдиницаИзмерения, ПодразделениеКомпании, Контрагент.
Количество записей: 53кк
Размер таблицы: 35гб (из них индексы этой таблицы 27гб) плюс сам документ 14 гигов, при том, что размер базы 80гб.
Что нужно сделать
Было решено оставить последнюю цену (разумеется, в разрезе групп измерений) и удалить все имеющиеся с 2008 года.
Вопрос к знатокам - как правильно методически выполнить сию задачу?
Сейчас у меня кроме как создать обработку на создание документа "изменение цен" с последним срезом цен (на текущую дату) и удалить все старые записи (правда ещё стоит вопрос, как это делать... уж точно не средствами 1с).
Просьба помочь, пнуть в нужную сторону, дать совет...
Прикрепленные файлы:
По теме из базы знаний
- Алгоритмы с решениями для экзамена Специалист УТ 11.1
- Печать трех цен в ценнике (или на этикетке)
- Обработка табличных частей документов
- Интеграции с маркетплейсами из одного окна: Озон, ВБ, Яндекс, Сбер, Али, ЛаМода для 1С:УНФ, УТ, КА, ERP
- Ценовая власть-4. Алгоритм обновления цен, формулы и схемы СКД в ВидыЦен
Найденные решения
ну я бы выгрузил срез последних в файл или в отдельную таблицу, затем средствами SQL выполнил Truncate table для таблицы регистра(выполняется мгновенно), затем залил бы срез последних назад. Время выполнения в общем будет зависеть от того, насколько большая у вас таблица со срезом последних
Ну, мое решение вам не понравится. База была на 1,2 ТБ. Так что об выборке "в 1с" в принципе не может идти речь.
В сиквеле получил срез последних (max по дате) и left join этой же таблицы. Все что null - delete.
По факту, в 1с, у проведенных старых доках просто исчезли движения.
Сами документы уже не удалял (оставил как историю для запросов), проведенный документ без движений - значит "история". Если выпилить и эти данные, то я бы делал по принципу рег.цен. Таблица регистратора LEFT JOIN таблица движений, если проведен и движения - NULL = DELETE
Если же нужно сохранить эти данные, делаем бекап "всей" базы и складываем на полочку.
Запомните - миграция данных или конвертация из реляционного вида в любой промежуточный и обратно - гиблое дело по своей сути.
upd. И да, данное "варварство" ведет к проблемам с "срез первых". При попытке получить срез - в лучшем случае скуль отматерит вас по полной, дай бог что бы не сошел с ума =))). Я не пользуюсь данным срезом, посему не заморачивался.
В сиквеле получил срез последних (max по дате) и left join этой же таблицы. Все что null - delete.
По факту, в 1с, у проведенных старых доках просто исчезли движения.
Сами документы уже не удалял (оставил как историю для запросов), проведенный документ без движений - значит "история". Если выпилить и эти данные, то я бы делал по принципу рег.цен. Таблица регистратора LEFT JOIN таблица движений, если проведен и движения - NULL = DELETE
Если же нужно сохранить эти данные, делаем бекап "всей" базы и складываем на полочку.
Запомните - миграция данных или конвертация из реляционного вида в любой промежуточный и обратно - гиблое дело по своей сути.
upd. И да, данное "варварство" ведет к проблемам с "срез первых". При попытке получить срез - в лучшем случае скуль отматерит вас по полной, дай бог что бы не сошел с ума =))). Я не пользуюсь данным срезом, посему не заморачивался.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Какая конфигурация?
С вводом среза последних проблем по идее быть не должно, можно взять типовую свертку, она введет остатки через КорректировкуЗаписейРегистров(в зависимости от конфы свой служебный документ)
С удалением сложнее, лучше конечно средствами 1С, например в несколько потоков очищать наборы записей по регистраторам (по идее пересечения быть не должно), а потом и сами регистраторы удалять.
Если скулем, удалить таблицу, создать заново, через выгрузкузагрузкуxml загрузить документ по переносу цен (но это так, теория, на практике я такое не делал)
з.Ы Какой обработкой размеры таблиц смотрели?
С вводом среза последних проблем по идее быть не должно, можно взять типовую свертку, она введет остатки через КорректировкуЗаписейРегистров(в зависимости от конфы свой служебный документ)
С удалением сложнее, лучше конечно средствами 1С, например в несколько потоков очищать наборы записей по регистраторам (по идее пересечения быть не должно), а потом и сами регистраторы удалять.
Если скулем, удалить таблицу, создать заново, через выгрузкузагрузкуxml загрузить документ по переносу цен (но это так, теория, на практике я такое не делал)
з.Ы Какой обработкой размеры таблиц смотрели?
ну я бы выгрузил срез последних в файл или в отдельную таблицу, затем средствами SQL выполнил Truncate table для таблицы регистра(выполняется мгновенно), затем залил бы срез последних назад. Время выполнения в общем будет зависеть от того, насколько большая у вас таблица со срезом последних
(4) индексы всегда можно пересчитать, регистратор надо вытаскивать при получении таблицы со срезом последних, это ваша задача их учесть)
имею ввиду регистратор можно оставить старый, тогда не нужен будет новый документ изменения цен. Если же будете делать через новый документ, то еще проще - регистратор заполнится автоматически при проведении документа
имею ввиду регистратор можно оставить старый, тогда не нужен будет новый документ изменения цен. Если же будете делать через новый документ, то еще проще - регистратор заполнится автоматически при проведении документа
(6) собсна вот, вполне рабочий запрос
ВЫБРАТЬ
ЦеныНоменклатурыСрезПоследних.Период,
ЦеныНоменклатурыСрезПоследних.Регистратор,
ЦеныНоменклатурыСрезПоследних.НомерСтроки,
ЦеныНоменклатурыСрезПоследних.Активность,
ЦеныНоменклатурыСрезПоследних.ТипЦен,
ЦеныНоменклатурыСрезПоследних.Номенклатура,
ЦеныНоменклатурыСрезПоследних.ХарактеристикаНоменклатуры,
ЦеныНоменклатурыСрезПоследних.Валюта,
ЦеныНоменклатурыСрезПоследних.Цена,
ЦеныНоменклатурыСрезПоследних.ЕдиницаИзмерения,
ЦеныНоменклатурыСрезПоследних.ПроцентСкидкиНаценки,
ЦеныНоменклатурыСрезПоследних.СпособРасчетаЦены
ИЗ
РегистрСведений.ЦеныНоменклатуры.СрезПоследних КАК ЦеныНоменклатурыСрезПоследних
Показать
(7) В моем случае он будет выполняться бесконечность, плюс боюсь предположить размер этого среза...
Уже 30 минут жду... а если ещё и по регистратору... даже страшно.
ВЫБРАТЬ
ЦеныСрезПоследних.ТипЦен,
ЦеныСрезПоследних.Номенклатура,
ЦеныСрезПоследних.ХарактеристикаНоменклатуры,
ЦеныСрезПоследних.ЕдиницаИзмерения,
ЦеныСрезПоследних.ПодразделениеКомпании,
ЦеныСрезПоследних.Контрагент,
ЦеныСрезПоследних.Цена
ИЗ
РегистрСведений.Цены.СрезПоследних КАК ЦеныСрезПоследних
ПоказатьУже 30 минут жду... а если ещё и по регистратору... даже страшно.
(9) срез последних немного по-другому работает, он дает срез на комбинацию всех измерений регистра + период и регистратор (неважно, все или не все измерения выведены в запросе). Остальные поля побочные, просто берутся те значения, которые соответствуют ключу записи.
1.сделать копию базы 1+ раз
----> дальше все на копии
2.создать документ установка цен с необходимыми ценами
3.выгрузить документ в XML
4. через SQL TRUNCATE TABLE_infoRg5011 если не сработало то delete from _infoRg5011
5. залить из XML документ установка цен и провести
6. если на копии ответственным и тебе всё нравиться
7. делать в продуктовой базе, предварительно сделав ещё 1+ копий
ЗЫ: подобным способом чистил 5 млн. налоговых
----> дальше все на копии
2.создать документ установка цен с необходимыми ценами
3.выгрузить документ в XML
4. через SQL TRUNCATE TABLE_infoRg5011 если не сработало то delete from _infoRg5011
5. залить из XML документ установка цен и провести
6. если на копии ответственным и тебе всё нравиться
7. делать в продуктовой базе, предварительно сделав ещё 1+ копий
ЗЫ: подобным способом чистил 5 млн. налоговых
(13) нормально описали, но я бы заменил загрузку/выгрузку в XML на копирование средствами SQL в промежуточную таблицу, которую можно создать в отдельной базе (запрос на срез последних можно поймать трассировкой и, выполнив его, залить результат в промежуточную таблицу). Это будет во много раз быстрее, к тому же XML очень объемный формат хранения данных, под такие объемы файлы будут просто огромными.
2.создать документ установка цен с необходимыми ценами
Можно тут подробней?)
номенклатуры 1кк, таких документов с учетом всех измерений цен будет.. думаю много) тем более ограничение на количество строк в ТЧ в 50к (вроде)
Я что-то сомневаюсь что прям так долго будет работать обработка, которая распроведет все документы, кроме последнего (в котором вы укажате срез последних цен).
Можно сделать регламентное задание которое постепенно пачками распроведет документы.
Можно сделать регламентное задание которое постепенно пачками распроведет документы.
1с даже не хочет вернуть мне результат, о какой обработке может идти речь.
Запрос типа (учет характеристик не ведётся)
тупо виснет
смотрю в профайлер:
Пришлось переписать:
этот за 16 минут выдал результат...
Боюсь, что только средствами 1с эту задачу не решить.
Буду пробовать сохранить этот результат (в файл или вспомогательную таблицу) и создать на основании полученного среза новые документы "Изменение цен".
Запрос типа (учет характеристик не ведётся)
ВЫБРАТЬ
ЦеныСрезПоследних.ТипЦен,
ЦеныСрезПоследних.Номенклатура,
ЦеныСрезПоследних.ЕдиницаИзмерения,
ЦеныСрезПоследних.ПодразделениеКомпании,
ЦеныСрезПоследних.Контрагент,
ЦеныСрезПоследних.Цена
ИЗ
РегистрСведений.Цены.СрезПоследних КАК ЦеныСрезПоследних
Показатьтупо виснет
смотрю в профайлер:
SEL ECT
T1.Fld5012RRef,
T1.Fld5013RRef,
T1.Fld6523RRef,
T1.Fld6524RRef,
T1.Fld6525RRef,
T1.Fld5014RRef,
T1.Fld5015_
FR OM (SEL ECT
T6._Fld6524RRef AS Fld6524RRef,
T6._Fld6523RRef AS Fld6523RRef,
T6._Fld5013RRef AS Fld5013RRef,
T6._Fld6525RRef AS Fld6525RRef,
T6._Fld5015 AS Fld5015_,
T6._Fld5012RRef AS Fld5012RRef,
T6._Fld5014RRef AS Fld5014RRef
FR OM (SEL ECT
T3.Fld5012RRef AS Fld5012RRef,
T3.Fld5013RRef AS Fld5013RRef,
T3.Fld6523RRef AS Fld6523RRef,
T3.Fld6524RRef AS Fld6524RRef,
T3.Fld6525RRef AS Fld6525RRef,
T3.Fld5014RRef AS Fld5014RRef,
T3.MAXPERIOD_ AS MAXPERIOD_,
SUBSTRING(MAX(T5._RecorderTRef + T5._RecorderRRef),1,4) AS MAXRECORDERTRef,
SUBSTRING(MAX(T5._RecorderTRef + T5._RecorderRRef),5,16) AS MAXRECORDERRRef
FROM (SELECT
T4._Fld5012RRef AS Fld5012RRef,
T4._Fld5013RRef AS Fld5013RRef,
T4._Fld6523RRef AS Fld6523RRef,
T4._Fld6524RRef AS Fld6524RRef,
T4._Fld6525RRef AS Fld6525RRef,
T4._Fld5014RRef AS Fld5014RRef,
MAX(T4._Period) AS MAXPERIOD_
FR OM dbo._InfoRg5011 T4 WITH(NOLOCK)
WH ERE T4._Active = 0x01
GROUP BY T4._Fld5012RRef,
T4._Fld5013RRef,
T4._Fld6523RRef,
T4._Fld6524RRef,
T4._Fld6525RRef,
T4._Fld5014RRef) T3
INNER JOIN dbo._InfoRg5011 T5 WITH(NOLOCK)
ON T3.Fld5012RRef = T5._Fld5012RRef AND T3.Fld5013RRef = T5._Fld5013RRef AND T3.Fld6523RRef = T5._Fld6523RRef AND T3.Fld6524RRef = T5._Fld6524RRef AND T3.Fld6525RRef = T5._Fld6525RRef AND T3.Fld5014RRef = T5._Fld5014RRef AND T3.MAXPERIOD_ = T5._Period
WH ERE T5._Active = 0x01
GROUP BY T3.Fld5012RRef,
T3.Fld5013RRef,
T3.Fld6523RRef,
T3.Fld6524RRef,
T3.Fld6525RRef,
T3.Fld5014RRef,
T3.MAXPERIOD_) T2
INNER JOIN dbo._InfoRg5011 T6 WITH(NOLOCK)
ON T2.Fld5012RRef = T6._Fld5012RRef AND T2.Fld5013RRef = T6._Fld5013RRef AND T2.Fld6523RRef = T6._Fld6523RRef AND T2.Fld6524RRef = T6._Fld6524RRef AND T2.Fld6525RRef = T6._Fld6525RRef AND T2.Fld5014RRef = T6._Fld5014RRef AND T2.MAXPERIOD_ = T6._Period AND T2.MAXRECORDERTRef = T6._RecorderTRef AND T2.MAXRECORDERRRef = T6._RecorderRRef) T1
ПоказатьПришлось переписать:
select
t1._Fld6524RRef,
t1._Fld5014RRef,
t1._Fld5013RRef,
t1._Fld6525RRef,
t1._Fld5012RRef,
t1._Fld5015
fr om
_InfoRg5011 as t1
inner join
(
select
_Fld6524RRef,
_Fld5014RRef,
_Fld5013RRef,
_Fld6525RRef,
_Fld5012RRef,
MAX(_Period) as _Period
fr om
_InfoRg5011
group by
_Fld6524RRef,
_Fld5014RRef,
_Fld5013RRef,
_Fld6525RRef,
_Fld5012RRef
) as t2
on t1._Fld6524RRef = t2._Fld6524RRef
and t1._Fld5014RRef = t2._Fld5014RRef
and t1._Fld5013RRef = t2._Fld5013RRef
and t1._Fld6525RRef = t2._Fld6525RRef
and t1._Fld5012RRef = t2._Fld5012RRef
and t1._Period = t2._Period
Показатьэтот за 16 минут выдал результат...
Боюсь, что только средствами 1с эту задачу не решить.
Буду пробовать сохранить этот результат (в файл или вспомогательную таблицу) и создать на основании полученного среза новые документы "Изменение цен".
Ну, мое решение вам не понравится. База была на 1,2 ТБ. Так что об выборке "в 1с" в принципе не может идти речь.
В сиквеле получил срез последних (max по дате) и left join этой же таблицы. Все что null - delete.
По факту, в 1с, у проведенных старых доках просто исчезли движения.
Сами документы уже не удалял (оставил как историю для запросов), проведенный документ без движений - значит "история". Если выпилить и эти данные, то я бы делал по принципу рег.цен. Таблица регистратора LEFT JOIN таблица движений, если проведен и движения - NULL = DELETE
Если же нужно сохранить эти данные, делаем бекап "всей" базы и складываем на полочку.
Запомните - миграция данных или конвертация из реляционного вида в любой промежуточный и обратно - гиблое дело по своей сути.
upd. И да, данное "варварство" ведет к проблемам с "срез первых". При попытке получить срез - в лучшем случае скуль отматерит вас по полной, дай бог что бы не сошел с ума =))). Я не пользуюсь данным срезом, посему не заморачивался.
В сиквеле получил срез последних (max по дате) и left join этой же таблицы. Все что null - delete.
По факту, в 1с, у проведенных старых доках просто исчезли движения.
Сами документы уже не удалял (оставил как историю для запросов), проведенный документ без движений - значит "история". Если выпилить и эти данные, то я бы делал по принципу рег.цен. Таблица регистратора LEFT JOIN таблица движений, если проведен и движения - NULL = DELETE
Если же нужно сохранить эти данные, делаем бекап "всей" базы и складываем на полочку.
Запомните - миграция данных или конвертация из реляционного вида в любой промежуточный и обратно - гиблое дело по своей сути.
upd. И да, данное "варварство" ведет к проблемам с "срез первых". При попытке получить срез - в лучшем случае скуль отматерит вас по полной, дай бог что бы не сошел с ума =))). Я не пользуюсь данным срезом, посему не заморачивался.
(28)
тогда наверное таблица тч регистратора? ведь может быть документ с 50к строк, и по всем удалены движения, кроме одной)
А можно поподробней? отчего это
Если выпилить и эти данные, то я бы делал по принципу рег.цен. Таблица регистратора LEFT JOIN таблица движений, если проведен и движения - NULL = DELETE
тогда наверное таблица тч регистратора? ведь может быть документ с 50к строк, и по всем удалены движения, кроме одной)
И да, данное "варварство" ведет к проблемам с "срез первых"
А можно поподробней? отчего это
(29)
угу, очепятка, но таблицу доков с пустыми строками все равно тогда удалять 3-м этапом. + с номерами строк все "поедет". Хз надо ли.
.
(29)
для первого запроса - нет необходимости, если надо очищать доки - делайте это вторым этапом
Вам бы забыть про документ как объект и про его ТЧ, он вам не нужен. Все запросы строятся по регистрам ведь. Оптимизация размера табл дока практически ни на что не влияет (кроме места)
Если он перепроведется руками - запись по всем товарам "восстановиться".
У вас есть регистр цен, с которым и надо работать.
регистратор1|товар1|цена|период3
регистратор1|товар2|цена|период2
регистратор2|товар1|цена|период1
регистратор2|товар2|цена|период4
регистратор2|товар3|цена|период5
Из данной табл получаем MAX по периоду и товару
товар1|период3
товар2|период4
товар3|период5
Соединяем эту таблицу с основной, получаем
регистратор1|товар1|цена|период3- товар1
регистратор1|товар2|цена|период2 - null
регистратор2|товар1|цена|период1 - null
регистратор2|товар2|цена|период4 - товар2
регистратор2|товар3|цена|период5 - товар3
Как по мне - ничего страшного, если документ 50 записей, а движений только 1.
Если хотите заморачиваться - пишите доп запрос, по очистке ТЧ документа.
В нашем случае это регистратор1, у которого в тч только 1 актуальный товар "товар1".
Суть в том, что запросы по ценам - будут работать быстро. И случайное перепроведение данного документа не сделает ничего страшного. Просто восстановит соответствие дока с движениями.
(29)
Срез первых как и срез последних - виртуальная таблица, которая хранит только актуальные правилу строки. А что будет, если запись среза есть, а этих строк не найдется в реальной таблице? Правильно, исключение, которое может быть не обработано 1с интерпретатором.
Соответственно таблицы индексов ([_InfoRgхххх_ByPeriod],[_InfoRgхххх_ххххх]) надо будет переформировать.
а наверное таблица тч регистратора
угу, очепятка, но таблицу доков с пустыми строками все равно тогда удалять 3-м этапом. + с номерами строк все "поедет". Хз надо ли.
.
(29)
ведь может быть документ с 50к строк, и по всем удалены движения, кроме одной
для первого запроса - нет необходимости, если надо очищать доки - делайте это вторым этапом
Вам бы забыть про документ как объект и про его ТЧ, он вам не нужен. Все запросы строятся по регистрам ведь. Оптимизация размера табл дока практически ни на что не влияет (кроме места)
Если он перепроведется руками - запись по всем товарам "восстановиться".
У вас есть регистр цен, с которым и надо работать.
регистратор1|товар1|цена|период3
регистратор1|товар2|цена|период2
регистратор2|товар1|цена|период1
регистратор2|товар2|цена|период4
регистратор2|товар3|цена|период5
Из данной табл получаем MAX по периоду и товару
товар1|период3
товар2|период4
товар3|период5
Соединяем эту таблицу с основной, получаем
регистратор1|товар1|цена|период3- товар1
регистратор1|товар2|цена|период2 - null
регистратор2|товар1|цена|период1 - null
регистратор2|товар2|цена|период4 - товар2
регистратор2|товар3|цена|период5 - товар3
Как по мне - ничего страшного, если документ 50 записей, а движений только 1.
Если хотите заморачиваться - пишите доп запрос, по очистке ТЧ документа.
В нашем случае это регистратор1, у которого в тч только 1 актуальный товар "товар1".
Суть в том, что запросы по ценам - будут работать быстро. И случайное перепроведение данного документа не сделает ничего страшного. Просто восстановит соответствие дока с движениями.
(29)
А можно поподробней? отчего это
Срез первых как и срез последних - виртуальная таблица, которая хранит только актуальные правилу строки. А что будет, если запись среза есть, а этих строк не найдется в реальной таблице? Правильно, исключение, которое может быть не обработано 1с интерпретатором.
Соответственно таблицы индексов ([_InfoRgхххх_ByPeriod],[_InfoRgхххх_ххххх]) надо будет переформировать.
(30) Вот вам sql запрос, как пища для рассуждений.
Select TOP 5 Tbl._Period, Tbl.[_Fld904RRef], Tbl.[_Fld942RRef], TblGroup._Period Fr om _InfoRg876 as Tbl
left join (select max(_Period) as _Period, _Fld904RRef, _Fld942RRef Fr om _InfoRg876
group by _Fld904RRef, _Fld942RRef ) as TblGroup
on Tbl._Period = TblGroup._Period and Tbl._Fld904RRef = TblGroup._Fld904RRef and Tbl._Fld942RRef = TblGroup._Fld942RRef
where TblGroup._Period is null
order by Tbl._Period DESC
(30)
1. Создал копию регистра в конфигураторе (со всеми регистраторами).
2. Получил срез (выбрать * из регистрсведений.цены) и залил его в копию.
3. trunc table таблицацен
4. залил в исходную таблицу цен полученный срез из копии.
5. удалил все регистраторы, у которых не оказалось движений
6. удалил все строки табличной части товаров, у которых не осталось ссылок на основную таблицу.
В итоге база увеличилась (на 20 гб, стала аж 100 гб!) после delete table. Ломал голову, а оказалось журнал превысил размеры базы, сжал его и уаля.
Размер базы уменьшился ровно в 2 раза. Профит.
1. Создал копию регистра в конфигураторе (со всеми регистраторами).
2. Получил срез (выбрать * из регистрсведений.цены) и залил его в копию.
3. trunc table таблицацен
4. залил в исходную таблицу цен полученный срез из копии.
5. удалил все регистраторы, у которых не оказалось движений
6. удалил все строки табличной части товаров, у которых не осталось ссылок на основную таблицу.
В итоге база увеличилась (на 20 гб, стала аж 100 гб!) после delete table. Ломал голову, а оказалось журнал превысил размеры базы, сжал его и уаля.
Размер базы уменьшился ровно в 2 раза. Профит.
(40) 55кк записей цен.
Срез (выбрать * из регистрсведений.цены.срезпоследних) и "заливка" его в копию таблицы заняло 15 минут.
Удаление документов (меня интересовал лишь установка цен: 20к документов и 150кк+ строк тч) без движений заняло часа 2.
Все средствами SSMS. Боюсь, что средствами 1с вышло бы очень долго и тяжелее (пришлось бы ещё разбивать на порции).
Срез (выбрать * из регистрсведений.цены.срезпоследних) и "заливка" его в копию таблицы заняло 15 минут.
Удаление документов (меня интересовал лишь установка цен: 20к документов и 150кк+ строк тч) без движений заняло часа 2.
Все средствами SSMS. Боюсь, что средствами 1с вышло бы очень долго и тяжелее (пришлось бы ещё разбивать на порции).
Исхожу из того, что база все-таки хоть как-то, пусть медленно, но работает. Соответственно я бы попытался обойтись средствами 1С. Но не пытался бы вычистить всё сразу, а растянул бы процесс во времени- сделал бы регламентное задание, которое поштучно снимало бы с проводки и помечало на удаление старые документы установки цен, допустим по 1 штуке в N минут, где N зависит от среднего количества строк в документах. Пусть бы работало только ночью.
А перед этим обработкой создал бы новые документы с текущими ценами. Допустим, порциями по 1000 строк в документе.
А перед этим обработкой создал бы новые документы с текущими ценами. Допустим, порциями по 1000 строк в документе.
Я бы предложил такой вариант - создать документ "Установка цен номенклатуры" с датой на начало года и установленными последними действующими ценами по всем применяемым на сегодня типам цен, остальные документы пометить на удаление и удалить.
После этого штатные процедуры "дефрагментации" с базой SQL и тестирование исправление в 1С.
Все делается типовыми средствами 1С (в том числе групповой обработкой документов).
По крайней мере логику базы не нарушит - 146%.
После этого штатные процедуры "дефрагментации" с базой SQL и тестирование исправление в 1С.
Все делается типовыми средствами 1С (в том числе групповой обработкой документов).
По крайней мере логику базы не нарушит - 146%.
Взять срез последних записать в 1 или несколько установок цен номенклатуры.
Как очищать, можно грохнуть регистр в конфигурации, а потом провести последний(е) документ(ы) (ради эксперимента), Но я бы постепенно распроводил старые документы
Как очищать, можно грохнуть регистр в конфигурации, а потом провести последний(е) документ(ы) (ради эксперимента), Но я бы постепенно распроводил старые документы
Друзья, вы же !!!точно понимаете, что такое 53 000 000 записей? И сколько лет будет работать штатное распроведение?
При самых радужных обстоятельствах- чистое процессорное время может составить от двух суток.
+ я более чем уверен, что запрос по этой таблице - хер взлетит в самой 1с (что бы получить доки к распроведению).
Это мы не берем во внимания ошибки записи (тут обменданными.запись не установишь, режим проведения так то).
Если учитывать рандомные вылеты 1с, глюки сиквела или службы 1с, попутно забивая журнал регистрации событиями, возможно, за годик справимся.
При самых радужных обстоятельствах- чистое процессорное время может составить от двух суток.
+ я более чем уверен, что запрос по этой таблице - хер взлетит в самой 1с (что бы получить доки к распроведению).
Это мы не берем во внимания ошибки записи (тут обменданными.запись не установишь, режим проведения так то).
Если учитывать рандомные вылеты 1с, глюки сиквела или службы 1с, попутно забивая журнал регистрации событиями, возможно, за годик справимся.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот