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

Посмотрел через команду

    МассивИменМетаданных = Новый Массив();
    МассивИменМетаданных.Добавить(Метаданные.РегистрыСведений.ГрафикиРаботыПоВидамВремени);
    СтруктБД = ПолучитьСтруктуруХраненияБазыДанных(МассивИменМетаданных);

получается 2 таблицы - регистрация изменений и основная. Непонятно почему их две, и зачем нужна таблица регистрации изменений, соответственно, не понятно какие изменения можно удалить.

и как правильно написать запрос на T-SQL ?

"Непонятно почему их две, и зачем нужна таблица регистрации изменений" // ИТС уже почитал?

Если удалять долго, то можно сохранить то, что удалять не надо, очистить весь РС и потом в него загрузить то, что сохранил до этого

> ИТС уже почитал?

нет, можешь ссылку дашь куда там смотреть?

> Если удалять долго, то можно сохранить то, что удалять не надо, очистить весь РС и потом в него загрузить то, что сохранил до этого

удаление и запись - это все процесс записи, они долго проходят потому что регистр раздулся. все сразу из 1с не удалить, никакой озу не хватит.
а если частично, то можно просто не удалять то что нужно оставить.

Пересоздать регистр в Конфигураторе, загрузить остатки.

> Пересоздать регистр в Конфигураторе, загрузить остатки.

какие остатки для регистра сведений?

(5) Оставшиеся записи

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

(7) Идентификатор оставить старый

(7) накатить из конфы поставщика

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

(0) "и зачем нужна таблица регистрации изменений"
для планов обмена

(0)
Выгрузить что нужно оставить в xml или еще куда.
Сделать TRUNCATE TABLE.
Загрузить.
PROFIT!

Изменение данных напрямую через SQL является нарушением лицензионного соглашения!

> Выгрузить что нужно оставить в xml или еще куда.

ты себе представляешь xml файл на 10 миллионов записей?

> Изменение данных напрямую через SQL является нарушением лицензионного соглашения!

спасибо, я в курсе

(15) 10 миллионов оставить надо, сколько тогда всех записей?!

+15 а главное какой клиент его прожевать сможет и за какое время?

30 с лишним

(17) Нихуясеберегистр, извините.

(19) Ну выгрузи 30 и снеси регистр.

(15) У меня хорошее воображение.

(15) выгружай на SSD-диск

(23)+ или RAM-диск

Не нравится выгружать - удаляй. DELETE FROM ... WHERE

А это разовая операция?

ну скажем так, двух разовая, сначала надо в тестовой базе убедиться что все хорошо!

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

(27) потом на тестовую накатываешь бэкап и тихой сапой переносишь в очищенную рабочую

(28) А ты точно сварщик, или маску на стройке нашел?

Ничо не надо пересоздавать и перекладывать.
Надо просто удалить лишнее.
Надо просто сделать обмены данными чтобы таблица регистрации изменений была пустая (если обмены данными используются и там вообще что-то есть).

Далее удалять так.
Перевести базу в Простую модель восстановления.
Удалять записи обычным delete с нужными условиями, но делать это порциями, чтобы не сильно прирастал ЖТ.
Потом вернуть полную модель восстановления и сбекапить базу. Все.

Память клиента тут не причем. А сервер точно справится при любом размере памяти.

(31)
> Надо просто удалить лишнее.
да, я тоже за этот вариант, вижу его самым беспроблемным.

Спасибо, план действий понятен!

ГрафикиРаботыПоВидамВремени вероятно в ЗУП 2.5
Посмотрел его.
Решение задачи с помощью прямого доступа к SQL может вообще не дать изюму ну или дать но небольшой, ибо и на 1С можно написать достаточно эффективно.

как-то обрезал большую базу средствами МС СКЛ...
как-то не срасталось всё, плюнул, взял обработку с ИТС - и просто подождал )

(14)а кто придумал эту чепуху? и почему все об этом рассказывают на этом форуме?

(35) обычно пишут те, кто qa в глаза не видел

(35) (36) Ну раньше этот запрет точно был. Может сейчас и поменяли.

(8) Проще TRUNCATE TABLE. Чем удалить, потом сравнением/объединением переносить.

(35)(36) http://v8.1c.ru/predpriyatie/questions_licence.htm#mvv
п. 65

А почему нельзя программно средствами 1с удалить ненужные записи? По одной в цикле, а не весь регистр сразу

> А почему нельзя программно средствами 1с удалить ненужные записи? По одной в цикле, а не весь регистр сразу

в первом посте написал - долго получается, в лучшем случае через месяц.

> Решение задачи с помощью прямого доступа к SQL может вообще не дать изюму ну или дать но небольшой, ибо и на 1С можно написать достаточно эффективно.

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

но я конечно попробую другими порциями еще.

(40) есть платформенные накладные расходы на удаление записей: например, поиск ссылок на объект, если он стоит как ведущее измерение в регистре. в том числе поэтому 1С и не рекомендует прямого доступа к СУБД.

(42) Ты путаешь.

(41) транзакциями не пользуешься?

Автор, ты не поверишь, но и в sql тоже будет долго :-)

Если накладывать хоть какие-нибудь условия на отбор при удалении.

(44) это вроде в 7.7 рулило, а на восьмерке прироста не дает.

А так - можно поотключать индексивароние-ведущесть у измерений и ресурсов - и вперед, типовыми средствами.

(46) понятно, т.е. все меняет то, что устанавливается отбор.

Ну и job в sql на дефраг индеска и апдейт статистики по этим двум таблицам раз в 5 минут.

в целом все понятно! всем спасибо!

(51) тогда закрывайте тему.
А то мы вам напишем тут))

(36) дикари , что с них взять ... ;+)