Доброго времени.

Ситуация буквально за пару дней файл .mdf увеличился с 2,5 гб до 37 гб. Ни как не могу выявить из-за чего такое могло произойти. Используемая платформа 8.3

Из-за испорченного одинэсника.

Ты посмотри какая у тебя таблица самая большая в базе средствами sql и потом посмотри что это за объект в 1С

(2) только вначале пусть операция по сокращению журнала   закончиться а то я с утра было запустил ее.

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

(4) Проверяй может у тебя документ проведен 216 году, вот он за 2000 лет итоги и пересчитывал

а может кто бабу голую в высоком разрешение в базе спрятал.

выполнил вот такой запрос к базе

DECLARE @pagesizeKB int
SELECT @pagesizeKB = low / 1024 FROM master.dbo.spt_values
WHERE number = 1 AND type = 'E'

SELECT
table_name = OBJECT_NAME(o.id),
rows = i1.rowcnt,
reservedKB = (ISNULL(SUM(i1.reserved), 0) + ISNULL(SUM(i2.reserved), 0)) * @pagesizeKB,
dataKB = (ISNULL(SUM(i1.dpages), 0) + ISNULL(SUM(i2.used), 0)) * @pagesizeKB,
index_sizeKB = ((ISNULL(SUM(i1.used), 0) + ISNULL(SUM(i2.used), 0))
- (ISNULL(SUM(i1.dpages), 0) + ISNULL(SUM(i2.used), 0))) * @pagesizeKB,
unusedKB = ((ISNULL(SUM(i1.reserved), 0) + ISNULL(SUM(i2.reserved), 0))
- (ISNULL(SUM(i1.used), 0) + ISNULL(SUM(i2.used), 0))) * @pagesizeKB
FROM sysobjects o
LEFT OUTER JOIN sysindexes i1 ON i1.id = o.id AND i1.indid < 2
LEFT OUTER JOIN sysindexes i2 ON i2.id = o.id AND i2.indid = 255
WHERE OBJECTPROPERTY(o.id, N'IsUserTable') = 1 --same as: o.xtype = 'IsView'
OR (OBJECTPROPERTY(o.id, N'IsView') = 1 AND OBJECTPROPERTY(o.id, N'IsIndexed') = 1)
GROUP BY o.id, i1.rowcnt
ORDER BY 3 DESC

и получил несколько объемных таблиц со следующими наименованиями
_AccumRgT7247
_AccumRgTn7013
_AccumRg7308
_AccumRg7001
_Document224_VT5410
_AccumRg21629
....

как узнать соответствие этих таблиц в 1с?

(5) интересное предположение проверю спасибо

обработка чуть ли не на 1с есть которая структуру выдает

не, если бы речь была о бабе то распухла бы одна таблица.

тем временем журнал обрезан с сохранением бэкапа в 1,5 гб. Общий размер базы не изменился.

бугагашенки

есть такая штука - базопузомер. Позволяет уйти от ампутации гланд через задний проход.

AccumRg - Регистр накопления
AccumRgT - Таблица остатков
AccumRgTn - Таблица оборотов


По поводу имен - http://catalog.mista.ru/public/295059/

но если очень хочется дрочить как в (7) тогда фапайте на получение структуры хранения

(13) благодарю

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

удалось выявить что _AccumRgT7247 = регистр накопления РасчетыСКлиентами. Там же я нашел запись где период почему то стоит 01.01.0001 23:59:59 хотя дата в самом документе стоит 21.09.2015 16:32:59. При проведении документа проблема не уходить. Из-за чего может это быть?

(0) проверь регистр "ВерсииОбъектов", возможно, включили версионирование

(18) проверено вчера. версионирование выключено.

(17) дату поменяй

(18) странно версионирование выключено но записи в том регистре есть и в некоторых строках автором является наименование плана обмена.

(20) получилось спасибо. А из-за чего такое могло происходит?

(22) Потому что неверно ввели дату. Ваш Кэп.

а пересчет итогов там ТиС не мог на это повлиять?

(24) пересчёт итогов может повлиять на что угодно. Даже на ход войны в Сирии.

пересчёт итогов даже серьёзнее, чем война в Сирии