Как избавиться от фантомных записей в 8.2? #521128

Столкнулся с такой проблемой: нужно было создать новую базу из старой (что бы справочники были заполнены и вообщем все настроено, только без документов). Что бы не заморачиваться с анализом какую информацию переносить и что потом еще ручками устанавливать (справочники, регистры сведений и т.п) решил просто из копии старой базы удалить все документы и движения по документам (все делал сначала в файловом варианте). Само удаление прошло нормально без всяких проблем, почистил параллельно кое-какую ненужную информацию и с удивлением обнаружил, что размер базы нисколько не уменьшился! А даже несколько вырос (почти 5 гигов)! Проверил записи всех регистров накопления и регистров бухгалтерии - все пусты! Подумал, просто не сжата база, в конфигураторе запустил тестирование и исправление базы, выбрал только опции: сжатие таблиц и рестрктуризация таблиц - и тут полный пипец! Сия процедура на ПУСТОЙ БАЗЕ выполнялась 7 часов!!! и после этого база нисколько не уменьшилась! Сделал выгрузку данных и загрузку: результат тот же. Тогда загрузил в SQL и посмотрел что ж так весит? И тут выясняется: База в SQL сразу стала весить 30!!! гигов. Из них 14 гигов занимает индекс таблицы Регистр бухгалтерии "Журнал проводок хозрасчетный" (ИтогиПоСчетамССубконто3) и 1.5 гига сама таблица!!! Ну и по остальным регистрам накопления аналогично, только в меньших объемах, поскольку и движения раньше в базе были меньше. Может конечно разработчикам и пофиг чистить дисковое пространство, но у меня оно как-то не лишнее,  тем более в таких объемах, да и на быстродействии это тоже сказывается. Запустил на ночь полное тестирование и исправление, но мало верю, что это поможет, поскольку раньше тоже как-то пробовал частичные удаления данных и после тестирования все в объемах было как и сейчас, только раньше не придал значения, поскольку не все движения удалял, думал дофига осталось.  Отсюда вопрос: как поудалять нах все эти данные по итогам несуществующих движений?

А тестирование проводилось с опцией удаление пустых ссылок?

А стандартные средства SQL дефрагментации и реиндексации чем не подходят ?

только запустил - раньше завтрашнего утра фиг что узнаю, но очень сильно сомневаюсь что поможет. По логике если выгрузить данные и загрузить итоги должны считаться по-новому на основании движений, (хотя ХЗ: может 1с-цы считают что итоги стоит тоже выгружать в xml файл - ну только нафиг в архиве только место занимать) а как поможет дефрагментация и реиндексация если в таблице реально записи находятся?!

Пересчет итогов не пробовал делать?

Пересчет итогов естественно был первым делом

"Nandarou" прав, нужно тестирование и исправление информационной базы делать с удалением пустых ссылок. Я в таких случаях поступал именно так.

То-то я думаю, откуда вдруг неожиданно в середине года появляются итоги и движения, которых никто в систему не вводил. Оказывается, чистую базу из демки 1С создавали. Это было на 8.0, на 8.1, видно переехало по праву наследования и в 8.2... :)

Итак результат: никакое тестирование и исправление не решает данную проблему - как была база 30 гигов так и осталась. Средств 1С как удалить эти итоги не нашел.    Остатется попробовать выгрузку в xml и загрузку из xml. Конечно это не решение проблемы, но другого выхода не вижу. Можно конечно в SQL почистить таблицы, только вот не уверен что в дальнейшем не получится какой-нибудь косяк при работе.    Подозреваю, чта данный эффект влияет и при рабочей базе (например перепроводим или удалем документы, возможно следы в итогах остаются! Может только не получишь в выборках, т.к. по измерениям регистров не получишь нужных ссылок, но дисковое пространство жрать будет)

Из них 14 гигов занимает индекс таблицы Регистр бухгалтерии "Журнал проводок хозрасчетный" (ИтогиПоСчетамССубконто3) и 1.5 гига сама таблица!!! а сколько строк в таблице?

Собственно обработка (взял с infostar) количество строк выдать не может (т.к. берется средствами 1С, а получить может только количество строк регистра . А количество строк в служебных таблицах 1С средствами 1С не получить). Но выдается объем таблиц SQL. Так вот этот объем и есть! Пока не было времени, чуть попозже посмотрю в таблицах SQL напрямую

каким образом документы удалял?

а документы небось имеют еще и доп проводки в модуле, помимо явно указанных ;)

- да собственно обработкой сначала сделал не проведенными, затем пометил на удаление. А непосредственно удаление не стал выполнять интерактивно, так как что то прядка 120 тысяч документов только проверка на возможность удаления не просто долго а очень долго выполнялась бы (опять же не пойму что тут такого можно лопатить столько времени, если просто поискать возможные ссылки - то например в Visual FoxPro по такой базе ну максимум минут 5-10). Поэтому удалял обработкой (Док.Удалить). Но способ удаления здесь ни причем. До этого проведение документов уже было отменено и все регистры накопления и бухгалтерии были очищены!! - а это что еще за секретные доп проводки? И как проводки можно указать неявно? Мы наверное разное пиво пьем.

Удалить помеченные объекты, потом выгрузить dt и вновь загрузить его. Таким образом уменьшил одну файловую базу с 16Гб до 12Гб.

- да выгружал и загружал, уже запарился! Могу констатировать на сегодняшний день однозначно: НИКАКИЕ ДЕЙСТВИЯ из НИЖЕ ПЕРЕЧИСЛЕННЫХ НЕ ДАЮТ РЕЗУЛЬТАТА - пересчет итогов - тестирование и исправление данных - выгрузка в dt и загрузка в эту же или другую базу - всевозможные комбинации 3-х предыдущих пунктов. А так же НЕ НАШЕЛ НИ ЕДИНОГО метода средствами 1С очистить итоги! Еще раз повторю: в базе НЕТ НИ ОДНОЙ ЗАПИСИ почти по всем РЕГИСТРАМ НАКОПЛЕНИЯ И РЕГИСТРАМ БУХГАЛТЕРИИ (Нужно было оставить один тип документов, а именно "Заказ", по которому есть движения по регистру накопления "Взаиморасчеты", конфигурация не типовая, поэтому не ищите данных регистров и документов там. не суть в этом. Данные регистры я не рассматриваю). В частности наибольший объем занимают итоги по регистра бухгалтерии , по которому ТОЧНО НЕТ НИ ОДНОЙ ЗАПИСИ. Отсюда резонный вопрос: почему тогда по этому регистру таблица итогов весит 1.5 гига, а индексы по этой таблице 14 гигов?!!! Нах ОНИ МНЕ НУЖНЫ!!! Поэтому делаю вывод: ЭТО ТРАБЛ 1С!!! Если это не так - переубедите меня и покажите скрытый смысл в этом!? Или не учат в программировании "убирать за собой"?!

а ты пробовал индекс перестроить? сколько строк в указанной таблице? метод count или свойства таблицы -> хранилище? Если таблица действительно пустая - тогда нет ничего удивительного..

динамическое обновление - не оч. хорошо

- В каких терминах идет разговор? в терминах 1С или SQL? SQL здесь НИПРИЧЕМ! Индекс больше размера самой таблицы - ничего удивительного (их то не один а несколько), а данные в таблице SQL ЕСТЬ! Что к нему цепляться! Что накидали, то он и хранит! Вопрос КАКОГО ХРЕНА 1С создат итоги по РЕГИСТРАМ (уже в теминах 1С), по которым отсутствую какие-либо движения (НЕТ ЗАПИСЕЙ в РЕГСИТРАХ, по которым ЕСТЬ таблица итогов SQL)!? Эти же итоги есть и в ФАЙЛОВОМ ВАРИАНТЕ! Только размер базы в файловом варианте в 6! раз меньше (это к оптимизации структур 1С под SQL - что-то здается далеко до оптимального, но не об этом разговор) да собственно динамическое обновление здесь каким боком? Ну была база, ну были удалены из базы документы, потом былр ПЕРЕСЧЕИ ИТОГОВ! Ну и какой-же алгоритм должен быть при пересчете итогов??? По здравому смыслу берем пустую таблицу итогов и строим по заданным измерениям итоги на основании регистра, по которому пересчитываем итоги! Результат записываем в базу! Все просто как грабли! А тут видать намутили и наоптимизировали так, что потерялся здравый смысл - движений нет а итоги офигенного размера!

Выгрузил данные с помощью универсальной обработки в xml-файл и затем загрузил в базу: база стала нормальных размеров, итоги по регистру бухгалтерии отсутствуют вообще (нет даже таблицы в SQL)! Отсюда можно констатировать: что это ТОЧНО ТРАБЛЫ 1С.