Бухгалтерская база SQL-я существует несколько лет, много раз правлена. Обновила ее в свое время до 551 релиза и сегодня обрезала. При этом помечены на удаление почти 1,7 млн документов и некоторое количество записей в справочниках. Сюда входят и ручные пометки на удаление. Стандартно удалять не могу, все виснет. Написала обработочку с транзакциями по 150 документов, с проверкой ссылок. Работает все равно очень медленно. Буду благодарна за рекомендацию чисто SQL-х или 1С-овских более быстрых методов удаления документов и элементов справочников с проверкой ссылок.

прямыми запросами можно удалить. С помощью 1С++, например. Как, не подскажу, т.к. сам в свое время привлекал для этого специалиста. )

Ссылок на подобные обработки нашла много, но все немножко не то или не 100% надежно, по словам авторов.  SQL знаю недостаточно хорошо, чтобы делать самостоятельно. Важно не просто удалить все, но и не нарушить ссылочную целостность.

(0) а пошринковать, то что удалено пробовали?

(3) Что значит - пошринковать? Я обрезала базу стандартной обработкой WRAP.ert, убрав только пометку на удаление. Потом убрала на начало времен ТА и БИ, пометила на удаление все до операций ввода начальных остатков в корреспонденции со счетом 00 и теперь хочу удалить все, помеченное на удаление вручную до начала обрезки и автоматические помеченное - это почти 1,7 миллиона документов за несколько лет и сколько-то элементов справочников. Все это, естественно , надо делать с учетом ссылок.

Ответы смогу посмотреть только завтра утром. Заранее благодарна за них! Всем хороших выходных!)

а перенести оставшиеся актуальные доки и справочники в чистую конфу не вариант ?

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

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

http://1c911.by/skachat-1s-besplatno/universalnaya-svertka-korrektirovka-registrov-sql.htm

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

В ДБФ мусор остается, можно Сжать()
В СКЛ нет

(8), (9) Сжатие после удаления, чтобы физически удалить из базы невидимые уже объекты - это понятно, просто в Конфигураторе. Да и в SQL вроде не нужно же? Речь только о НайтиСсылки(Док, Ссылки); и Если Ссылки.КоличествоСтрок()=0 Тогда Удалить(1);КонецЕсли; Это работает медленно, можно ли заменить на прямые SQL-е запросы, обязательно с проверкой ссылок? Ну и со справочниками аналогично.
(6) Если не смогу быстро почистить хвосты, придется переносить, возможно. Но с будущего года базу будем переводить на 8.2, еще тратить время на перенос не хотелось бы - база уже свернута, другой работы полно.

Запуская по ночам обработку удаления объектов в фоновом режиме. Постепенно удалит.

(0) Зачем? СФ ты никогда не удалишь, на них есть ссылки..
Реализации так же, тоже ссылки :)
В итоге получишь мертвую БД...

(7) Почему то мне кажется, что контроль ссылок его мало интересует :)

(12), (13) Ребята, я не против, чтобы меня считали блондинкой, мне бы задачку решить). В том-то и дело, что счета-фактуры, как и реализации, в удаляемом периоде имеют ссылки на удаляемые же документы. Вот и хотелось бы удалить все, что не цепляет рабочих периодов. Конкретнее: база существует с декабря 2004 года. Свертка сделана по 2011 год включительно, чтобы оставить очередной период трехлетний для аудита, текущий проверяют в старой базе, если что-поправить начальные остатки в боевой не проблема.
Вся история возникла из-за того, что база последнее время работает медленно и начались странные ошибки, например, в журнале по серии одинаковых документов суммы видны нарастающим итогом и т.д. О переводе на 8.2 только что принято решение, но улита едет - когда-то будет, а работать надо здесь и сейчас. Поэтому полумера-обрезка базы. Так можно ли ее обрезать корректно?) Если да, то как удалить помеченное на удаление?) У меня часов 15-20 крутится на пробу 1 месяц так, как я писала в (10)... И конца-краю не видать)...

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

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

(12), (13) Да, и, конечно, контроль ссылок интересует и очень). Я попробовала самый простой вариант пока, и то медленно безумно, а если таблицы ссылок анализировать-еще веселей будет. Поэтому и спрашиваю об альтернативных методах.

(16) заведите пустую базу и в нее загрузите из внешних источников

(16) Это проблемы не решает. База заполняется как изнутри, так и заливом извне. Еще раз - если способа безболезненно и быстро удалить помеченные на удаление документы и элементы справочников, не имеющие ссылок на непомеченные на удал. документы и эл-ты спр-ков не найдется, я, конечно, буду выгружать справочники и доки в чистую базу, но хотелось бы закончить начатое, а не ваять все с нуля.

(19) Ладно, если все так серьезно, то какой бюджет? :)

А вообще если в след. году переходите на 8.2 (удачного перехода), то я бы вообще не заморачивался обрезками. 20 Гиг - это не тот объем.

ну все, конец цикла обогатится и уедет на мальдивы.. ;-)

(22) Ну если токо на след. год :)

(14) Они имеют ссылки не на документы, их имеют Регистры +Счета бух учета :)

(15) Удаление документов не лишит её объемности, т.е. скорости небудет так же как и прирост дискового пространства :)

мне одному показалось, что в ветке бреда про ТА как дерьма за баней? Речь идет о бухгалтерской базе судя по (0). Или что?

(26) Может про БУ, но есть шанс, что это вообще комплексная БД :)
Автор не раскрывает всех козырей, но судя по информации в скоре они переходят на 8.2, но и тут непонятно на какую конфу :)

Так). Смотрю, инфа продолжает поступать). Меня перекинули было на другие срочные задачки, сорри, некогда было глянуть).
(20) Пока даже не обсуждается).
(26) База бухгалтерская, платформа комплексная, с моей точки зрения тоже ТА не относится к делу, но где-то рекомендовалось и ее сперва закидывать на начало времен, потому и упомянула. Насчет дерьма за баней не в курсе, поисками не занималась, возможно, есть более опытные товарищи).
(24),(25),(27). Естественно, ссылки в проводках есть, но и документы-основания, скажем, тоже. Объем базы уже сильно уменьшился за счет табл.проводок, но надо и документы чистить, желательно, побыстрей, хотя теперь так не гонят. На 8.2 переход планируется в будущем году, естественно, тоже будут все компоненты, потому что баз разных в конторе как, хм)... Не рискую писать, в ветке есть специалист по баням)...

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

(25) Объем частично ушел, я писала-проводки ушли, еще уйдет после удаления документов, сжатие вроде ж не нужно, база SQL-я.

(0) если штатно - то отключи ЖР..совсем и помечай себе доки на удаление.

А так, sql запросом всего лишь проапдейтить _1sjourn да прибить проводки и операции, делов то

(31),(32) Вернулась к теме. ЖР отключить не проблема, на удаление тоже помечено все, а проапдейтить _1sjourn - как? Есть ли способ, при котором не оборвутся ссылки? И как прибить проводки и операции? Я в SQL-е не сильна, увы. Простой Select напишу, конечно, а вот хитростей не знаю...

И еще: ЖР с 2012 года нужен, можно ли его переписать или обрезать, как обычный текстовой файл? Есть ли в этом случае ограничения по размеру записываемого через V7plus текстового файла? Или лучше использовать другие средства? Если да, то какие?

(34)дак пусть ЖР в копии останется.

(33)
Да ё..
ЖР прибивать не надо!
Нужно в пофигураторе СЫНять галочки все с него, чтоб при штатной пометке на удаления туда ничего не писалось..вообще.
Потом можешь обратно галки взад вернуть.

но  sql запросом всё можно сделать быстрее

(35) База обрезана по 2011 год, ЖР с 2012 года нужен, просто в копии оставлять мало. Им бывает надо видеть, кто что делал не только с момента обрезки, но и раньше.

В ЖР при обрезке, галочки, конечно, убирала. Речь не о том, просто попутно ответила. С обрезкой его тоже все просто оказалось - обычный текстовой файл, в копии уже обрезала. А вот вопросы из (33) остались...

(0) А зачем так сильно волноваться о ссылочной целостности?
Период закрыт, прошлые данные всегда можно в копии посмотреть.
Удалите програмно все документы до 2011 года без проверок.

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

(40) Ведь ссылки могут быть в более поздних документах и элементах справочников, и точно будут  - есть справочники, в которых одним из реквизитов является документ, есть документы, ссылающиеся на другие - хотя бы как на основания, да много чего есть).

(9) в SQL тоже запись помечается как удаленная и через некий промежуток времени очищается

да блин, примитивный запрос который в 1sjourn пометит доки на удаление и в табличках операций и проводок уберёт все записи с этих документов.. и всё.

+ с таблички итогов можно тоже вычистить, хотя проще, прибить и пересчитать таблички итогов.

(44) А физически и с точки зрения 1Са они останутся в базе помеченными на удаление? А надо их физически удалить, чтобы уменьшить размер базы. И как насчет ссылок на эти документы в справочниках и других документах?

(45) И что значит "прибить таблички итогов"?