Предистория была большая база на скуле (Бухгалтерия). Нужно было выделить 1 организацию. Сделал копию удалили лишние выгрузил в файловую базу. И тут обратил внимания, что база весит 13 гигов. И это при том что  в базе всего 10 проведенных документов. Почистил все классификаторы из РС, удалось сбросить пару гигов. 11 гигов для практически пустой базы ... многовато будет.
Полез в Tool_1CD. При выборе базы ругается - длина таблица не кратна длине записи
Длина таблицы 4,5 гига, длина записи 280 байт
Проблемная таблица - _ACCUMRGT16153, т.е. таблица остатков (РН - Затраты при УСН). При этом в режиме предприятия у этого регистра нет движения.


Собственно возникает вопрос как средствами 1С избавиться от фантомных записей?

Что было сделано

Средствами скуля
- DBCC CHECKDB (N'base', REPAIR_REBUILD) WITH NO_INFOMSGS - ошибок не обнаружено

В конфигураторе
- полное ТиИ - тестирование базы средствами 1С, включая проверку, полный пересчет итогов, сжатие и реструктуризацию - фантомные записи остались

Выгрузка/загрузка в файловую

Проверка базы средствами chdbfl - ошибок не обнаружено

В режиме предприятия - управление итогов
- Включение/отключение итогов,
- включение/отключение текущих итогов,
- двигал период расчета, в том числе установка итогов на 31.01.0001
- отключал разделение итогов
- Запускал пересчет итогов и пересчет текущих итогов

Все это не привело к очистке от фантомных записей. Более того в базе есть и записи с битым периодом (период "86.75.762; ;1:88:=8") которые тоже остались.


Собственно вопрос, что еще можно предпринять, кроме drop table средствами скуля с последующим полным пересчетом итогов, так как неизвестно в каких таблицах есть еще фантомные записи (дропать все подряд?) и этот метод очень трудно реализовывать на "рабочих базах", не будешь же в регламент вставлять раз в месяц дроп итогов и полный перерасчет.

На мисте была похожая тема v8: Как избавиться от фантомных записей в 8.2?, но решений так и не нашлось. Все закончилось переносом данных в чистую базу через xml, а не исправление текущей

а средствами скуля delet from, а потом ТИИ

(2) Тогда уж средствами скуля выбрать нужные записи во временную таблицу, транкейт сбойную таблицу, инсерт из временной.

(3) автор сказал, что движений вообще, поэтому truncate и ТИИ

(4) автор также сказал что неизвестно в каких еще таблицах итогов есть такие записи. как искать?

Автор так же сказал что скорее всего в рабочей базе такие же записи, а там есть движение, как фильтровать?

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

Исходя из всего этого автор категорически против delet from, транкейт

(5) глобальный метод ПолучитьСтруктуруХраненияБазыДанных()

(6) и? я им воспользовался чтобы найти имя проблемного регистра

Вопрос в том что Tool_1CD пишет "длина таблица не кратна длине записи"
И при этом ни средствами скуля, ни средствами 1С я не знаю как диагностировать, чтобы исправить эту проблему. Т.е. в таблице 4,5 гига левых записей, при этом рабочую базу я не могу выгрузить в файловую базу, чтобы натравить на ней Tool_1CD, а значит ищется инструмент которые сможет продиагностировать запись на левость, а таблицу на кривость

Если в базе 10 документов - удалить все регистры в конфигураторе, потом ТИИ, загрузить регистры из сохраненной конфигурации.

(9) Это на базе где 10 документов это всплыло, а неизвестно сколько таких записей в оригинале, т.е. в рабочей.

Понятно что можно транс и забыть, но нужен инструмент для контроля целостности рабочей базы

вообщем так и не нашел как это сделать пришлось скулем грохать. Как результат база сдулась с 11 гигов до 1,1 гига.
Почистил сохраненые настройки (тоже прикол пользователь удален, а настройки остаются) это еще - 100 метров. Итого теперь самая большая таблица - блобы конфига (408 метров), за ним идут блоб справочника (23 метра), блоб РС (20 метров). Ну т.е. вполне адекватные данные

кому интересно скрипт для скуля по формированию таблиц для очистки


--очистка итогов http://its.1c.eu/db/metod8dev#content:1591:hdoc

--регистры накопления итоги
SELECT 'TRUNCATE TABLE ' + name+';' FROM sys.tables WHERE name like '_AccumRgT%'
--регистры бухгалтерия итоги по счету
union
SELECT 'TRUNCATE TABLE ' + name+';' FROM sys.tables WHERE name like '_AccRgAT%'
--регистры бухгалтерия обороты между счетами
union
SELECT 'TRUNCATE TABLE ' + name+';' FROM sys.tables WHERE name like '_AccRgCT%'
--таблица регистрации изменений
union
SELECT 'TRUNCATE TABLE ' + name+';' FROM sys.tables WHERE name like '%ChngR%'
--_UsersWorkHistory - История работы пользователей
union
SELECT 'TRUNCATE TABLE ' + name+';' FROM sys.tables WHERE name like '%UsersWorkHistory%'
--_SystemSettings - История работы пользователей
union
SELECT 'TRUNCATE TABLE ' + name+';' FROM sys.tables WHERE name like '%SystemSettings%'
--_RepVarSettings - Хранилище настроек вариантов отчетов
union
SELECT 'TRUNCATE TABLE ' + name+';' FROM sys.tables WHERE name like '%RepVarSettings%'
--_CommonSettings - Хранилище общих настроек
union
SELECT 'TRUNCATE TABLE ' + name+';' FROM sys.tables WHERE name like '%CommonSettings%'
--_FrmDtSettings - Хранилище настроек данных форм
union
SELECT 'TRUNCATE TABLE ' + name+';' FROM sys.tables WHERE name like '%FrmDtSettings%'
--_DynListSettings - Xранилищe динамических списков
union
SELECT 'TRUNCATE TABLE ' + name+';' FROM sys.tables WHERE name like '%DynListSettings%'

(0)
- в конфигураторе выполнить пересчет итогов.
Либо
- в режиме предприятие отключить текущие итоги, а итоги перевести на дату 01.01.0001. После этого  снова включить текущие итоги и выставить новую дату рассчитанный итогов.

(13) и чем этот совет кардинально отличается от описанных в (0) действий?
У меня такое ощущение что 1С не пересчитывает итого если нет движения, либо как то выборочно пересчитывает

(14) плохо прочитал (0) пост, ничего.