Столкнулся с такой проблемой: нужно было создать новую базу из старой (что бы справочники были заполнены и вообщем все настроено, только без документов). Что бы не заморачиваться с анализом какую информацию переносить и что потом еще ручками устанавливать (справочники, регистры сведений и т.п) решил просто из копии старой базы удалить все документы и движения по документам (все делал сначала в файловом варианте). Само удаление прошло нормально без всяких проблем, почистил параллельно кое-какую ненужную информацию и с удивлением обнаружил, что размер базы нисколько не уменьшился! А даже несколько вырос (почти 5 гигов)!

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

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

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

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

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

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

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

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

Итак результат: никакое тестирование и исправление не решает данную проблему - как была база 30 гигов так и осталась. Средств 1С как удалить эти итоги не нашел.

   Остатется попробовать выгрузку в xml и загрузку из xml. Конечно это не решение проблемы, но другого выхода не вижу. Можно конечно в SQL почистить таблицы, только вот не уверен что в дальнейшем не получится какой-нибудь косяк при работе.

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

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

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

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

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

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

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

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

А так же НЕ НАШЕЛ НИ ЕДИНОГО метода средствами 1С очистить итоги!

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

Поэтому делаю вывод: ЭТО ТРАБЛ 1С!!! Если это не так - переубедите меня и покажите скрытый смысл в этом!? Или не учат в программировании "убирать за собой"?!

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

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

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

(17) да собственно динамическое обновление здесь каким боком? Ну была база, ну были удалены из базы документы, потом былр ПЕРЕСЧЕИ ИТОГОВ! Ну и какой-же алгоритм должен быть при пересчете итогов??? По здравому смыслу берем пустую таблицу итогов и строим по заданным измерениям итоги на основании регистра, по которому пересчитываем итоги! Результат записываем в базу! Все просто как грабли! А тут видать намутили и наоптимизировали так, что потерялся здравый смысл - движений нет а итоги офигенного размера!

Выгрузил данные с помощью универсальной обработки в xml-файл и затем загрузил в базу: база стала нормальных размеров, итоги по регистру бухгалтерии отсутствуют вообще (нет даже таблицы в SQL)!

Отсюда можно констатировать: что это ТОЧНО ТРАБЛЫ 1С.