Месяц назад при выгрузке базы и загрузке ее у себя выдало сообщение.

Ошибка загрузки информационной базы. В информационную базу загружены не все данные
по причине:
Ошибка СУБД:
Превышен максимально допустимый размер внутреннего файла 'C:\Users\marat\Documents\InfoBase1/1Cv8.1CD'
по причине:
Превышен максимально допустимый размер внутреннего файла 'C:\Users\marat\Documents\InfoBase1/1Cv8.1CD'

Долго не стал разбираться перешел у себя для разработки на sql 2008.
Сейчас встал вопрос делать копию базы для фин директора.
Дело в том что база всего вести 2.8 гб а по отдельным таблицам максимальная 135 мб. В файовом варианте если не изменяет память то объем не превышал и 1 гб в момент возникновения ситуации.

Подскажите в чем модет быть проблема. ТИИ делал, сжатие базы делал.
Даже пробовал удалить данные РС в котором очень много данных.

(66) Черт! Дело говоришь. Ведь есть у меня справочник для хранения фото сотрудников.
Пробую...
увы нет не тот...

а в 8ке есть метод посмотреть размер базы справочников,документов,регистров? В 7ке дбфной все в файл-менеджере было видно, в скл тоже.

Пытаюсь удалить справочник "ДоговорыКонтрагентов"

вываливается ошибка

В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Поле Fld440 таблицы AccumRgAggDict2h447 содержит висячую ссылку. Старое поколение не может быть удалено.

Причем AccumRgAggDict2h447 это РегистрНакопления.ЗаказыНаОтгрузку
Который уже не существует.
Что делать как быть?

(68) Визуально без спец обработки не увидишь выше есть ссылка на эту обработку. ДАже не обработка а програмулька.

(68) есть,  им надо просто воспользоваться

(70) ты не пробовал ее чтоли?

(70) будьте добреньки, кто не жадный киньте на почту. у меня на инфостарте 32 старто-копейки.

(72) В скуле глянул размеры и все. А для файловой у меня тоже нет денег в ИСе (((

гугл рулез!) нашла ссылку в инете на нее)

Интересно, что такое "висячая ссылка"?
В конфигураторе конфигурация-тестирование конфигурации сделай
Попробуй конфиурацию выгрузить в файловую загрузить

Может, поможет v8: Поле ID таблицы .... содержит висячую ссылку. Старое поколение не может быть удалено

(74) (73) http://rusfolder.com/27931727

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

Конфигурацию можешь выложить?
Посмотрим

а 8.3.4 в режиме совместимости с 8.3.3?

(81) До сих пор я все крутил ее в 8.3.3
Но 5 мин назад перевел в 8.3.4 и при этом режим совместимости стоит

(80) Конфу или базу? А если базу то скульную или dt?
Желательно не давать ни кому. Как вариаент кинуть только конкретному лицу.

Пля че за платформа блин?!
Пол года вроде ничего не было а тут удаляю в конфе объект РН и при этом делаю ТИИ. Но тем не менее в скуле остаются мертвые души в виде таблиц РН...

Или в скуле всегда остаются таблицы???

Пробовал делать сжатие не помогает...

Попробовал сделать следующее.
Из скулевой базы то что у меня осталось после всевоможных удалений объектов выгрузил cf.
Создал файловую из нее выгрузил в dt.
Загрузил в скулевую. При этом в скулевых таблицах исчезли все лишние таблицы от удаленных ранее объектов.

По ходу мне кажется только конвертакия и поможет.

(14) Этого даже в 1С не знают. Поэтому и выпустили мини-сервер.

(53) Похоже на зацикливание. Возможно, повреждена конфигурация. Демоническое обновление не использовалось?

(69) Очень похоже на битую конфигурацию...

(88) Почему? Демоническое использовалось. Но серьезных нарушений не видел. ДА и ТИИ ничего страшного не показал.

(69) База сегодня мною убивалось но естественным путем. Удалял постепенно объекты но их слепки остались в скуле.

Вот я тему даже создал.
v8: В скулевой базе удаляю РС РН итп. Но в самом скуле эти таблицы остаются почему?

(89) кстати попробуй на cd программку чекдск использовать из папки bin.

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

Кстати, dt в клиент-серверный вариант загружается или нет?

(59) мне кажется, что в зависимости от размера базы применяются разные алгоритмы сжатия - иногда dt получается маленьким, иногда большим
(63) 1C при удалении забивает пространство нулями. Хотя как ведет себя при физическом удалении не знаю
(64) можно с помощью универсального обмена данными (в юнирепсах есть) делать выгрузку по каждой таблице в xml файл - так и найти самый большой

Используются ли планы обмена в базе?

(92) Размер dt сильно поменялся в 8.2.14. ЕМНИП - это по той причине, что в платформе 8.2.14 и позднее выгружаются еще и итоги по РН.

(0) мои мысли такие

1. Каждая таблица в файловом варианте состоит из 4х внутрених файлов
2. Единственный внутрений файл который может расти в процессе загрузки - это индексы (они полностью пересчитываются)
3. Индексы у разных версий платформы могут быть принцепиально разные по алгоритму.
4. кроме индексов есть "волшебные, служебные" таблицы и обмен.
5. в последней платформе изменен файл лога
6. 8.3 пока нестабильна

Идем исключением
1. перейти на стабильную платформу 8.2 (исключим п. 6,5,3)
2. исключим кеш, и системные таблицы (загрузку ведем на новом чистом компе в ПУСТУЮ базу!!!! обязательно в ПУСТУЮ !!!!!), так-же загрузка в пустую исключит "фантомные" таблицы
3. Исключим план обмена

вроде все...

Отвечу на вопросы.
Выгруженая со скуля dt  обратно грузится в скуль.
Но файловую так и не смог пока создать. При чем почти все удалил. Я бы дальше удалял но натолкнулся на "скелеты" удаленных  регистров в таблицах скуля.

(96) дт грузи в ПУСТУЮ базу, нельзя грузить в существующую...

(97) Пробовал и не раз.

(0) "Дело в том что база всего вести 2.8 гб а по отдельным таблицам максимальная 135 мб"

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

(96) Попробуй следующее:
I. Провести проверку конфигурации штатными средствами Конфигуратора.

II. Выполнить следующие действия:
1. Создать пустую базу.
2. Выполнить "Сравнение и объединение" со своей конфигурацией.
3. Выгрузить полученную конфигурацию в файл.
4. В копии базы выполнить "Загрузить конфигурацию из файла"
5. Применить изменения, выгрузить базу в dt.

После чего попробовать загрузить в файловый вариант.

Надо учесть, что во втором случае часть данных может потеряться.

(99) http://savepic.net/4228612.htm
(100) Примерно так  пробовал но еще раз сделаю

(101) С пустой конфигурацией выгрузку-загрузку тоже стоит проверить.

(102) С пустой базы выгрузка загрузка работает
Но то что в (100) не дал положительного результата.

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

ещё раз спрашиваю. Распределенка есть?

(105) Прошу прощения нет.

Кстати, я решил сделать распределенку отпочковать и с ПБ сделать нормальную базу.

(0) Очень похоже, что где-то в базе есть "закольцованность", типа "Элемент А" - Родитель "Элемента Б", и "Элемент Б" - родитель "Элемент А"

(106) Кстати, а размер файла 'C:\Users\marat\Documents\InfoBase1/1Cv8.1CD' когда выдало ошибку - не смотрел сколько? И еще можно посмотреть - размер свободного дискового пространства до загрузки и в момент ошибки - чтобы точно узнать - с размером файла связана ошибка или с чем другим.

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

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

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

(109)  "выходит имеем новое ограничение в виде количества объектов метаданных"
Тогда бы и на пустой базе с проблемной конфигурацией таже ошибка была, а в (103) вроде загружается

Интересно а почему в 1С 8.3 действуют ограничения СТАРОЙ версии DBF (которое уже давно устранил разработчик формата)?

Там небось у них еще и зашиты CDX?

То есть теперь максимум не 2 Гб, а 2 Гб*длина записи в байтах, при сохранении 32-разрядной структуры всех индексов.

Думаю что проблему решил. Что я сделал.

1. Взял свежую копию скульной базы
2. В нем создал План обмена - назвал "КЛОН"
3. Включил полную миграцию всех объектов.
4. Отпочковал базу. Получилос ПБ файловая- клон скульной.
5. Удалил главынй узел. выгрузил в DT.
6. Загрузил в скуль
7. из скулевой базы выгрузил опять в DT.
8. Попробовал загрузить в файловую. Все ок загрузилось.
9. Удалил план обмена.
10 Вуаля! Надеюсь ничего не потерял если даже потерял то это было ошибкой.
БАза sql мдф - 2.7, выгрузка в dt- 47 мб,  файловая- 320 мб

Хм... Получается, дело было не в конфе, а в данных?

А вот почему произошел то что в теме я так и не узнал.
Есть предположение.
1. Демоническое обновление
2. копипаст (имопорт из конф) неторых документов с обычных форм с их обычными формами из 8.2
3. База какое-то время жила на ссд. может быть там что-то было. Хотя сервак новый и до сих пор пашет.
4. Проблема релиза 8.3.3.687...
5. разрабатывали конфу 2-3 человека при чем удаленые помощники быть может они какое то время разработывали в другом релизе....
6. короче фиг знает.

(115) Точно не скажешь. Ведь в 1с8 в файловой все в одном файле. Да и висячие ссылки тоже говорят что со структурой таблиц что-то не так.

(115) Я типа такого и предположил в (107).
З.Ы. У нас было дело еще на 7.7, когда из структуры подчинения "А"->"Б"->"В" сделали "А"->"В"->"Б". При загрузке первое переподчинение сработало и получилось "В"->"Б"->"В"->"Б" и т.д. при этом команда "Спр.Уровень()" уходила в бесконечный цикл и все вешалось.

Обломс
то что в (116) видимо не подойдет. База на первый взгляд норальный но некотороые документы не открываются.
Видать данные покоцаны или же все таки конфа виновата.

Может перенести данные в чистую конфу?

Я еще блин экспериментировал на новом релизе. 1с8.3.4

Для чистоты эксперимента надо было все делать в страром так и сделаю.

Если что придется переносить...

(119) Попробуй запросами глянуть данные проблемных документов.

(119) dbcc checkdb без ошибок проходит?

(123) Все чисто

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

И вот что за таблица топовое на моент не хватки места dbo._InfoRg959 1 427 312 мб

И что за регистр сведения?

(126) Это регистр сведений имеющий 2 измерения и один ресурс в виде даты. Полагаю проблема не в нем.
Это просто большой РС с данными.

видим надо еще глубже копать.

(127) Тебе надо смотреть не на самую большую таблицу, а на самый большой индекс. sql.ru подсказывает такой запрос:

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

(125) у тебя зацикленость данных...

Объект1.Родитель = Объект2
Объект2.родитель = Объект3
Объект3.родитель = Объект1

(125) Да, похоже на зацикливание, в таком случае сколько места на диске не выделяй - все мало будет.

более простой вариант запроса из (128)
DBCC UPDATEUSAGE (0)
create table #t(name varchar(255), row varchar(255), reserved varchar(255), data varchar(255), inxex_size varchar(255), unused varchar(255))

insert into #t
exec sp_msforeachtable N'exec sp_spaceused ''?'''
select * from #t order by CONVERT(bigint,REPLACE(data,' KB','')) DESC
drop table #t

Вот картина и что с ним делать не пойму. все вроде ок.
Хотя при отпочковании базы в ПБ в скуле база выросла до 29 гб
_AccumRg1171    330330    41808    29696    12048    64
_AccumRgTn1286    85402    29600    15408    14184    8
_AccumRg1277    122157    28824    17776    10896    152
_AccumRg1245    130288    21456    16552    4800    104
_AccumRg1319    150262    19152    13512    5496    144
_InfoRg959    178413    17936    10056    7744    136
_Document63    30563    11928    9408    2200    320
_AccumRg1184    72566    9424    6600    2680    144
_AccumRg1121    69310    8912    6232    2568    112
_InfoRg1006    38203    8664    4136    4392    136
_InfoRg993    26226    8152    3384    4640    128
_AccumRg1134    37237    8144    6624    1408    112
_AccumRg1298    23726    5912    3464    2168    280
_AccumRg1093    42659    4944    3256    1584    104
_Reference21    7455    4456    1864    2192    400
_Reference16    7188    3944    1472    1864    608

Вобщем что я сделал.
1. Опять создал РИБ
2. Настройка миграции полная
3. Выгрузил в это раз в скульную периферийку.
4. БАза отпочковалась но заняло 28,5 ГБ (MDF)
5. Просмотр объема таблиц в скуле ничего подозрительного не показало.
6. БАза Пб нормально выгружает в файловую и обратно в скуль
7. НО как тольок удалил план обмена опять глюк. Не открывается самый сложный  документ да и объемы этого дока большие.
8. ТИИ не помогло. Сжатие базы не помогло.
9. Выгружаю эту базу в файлову вроде все нормуль.
ни каких выводов у меня нет до сих пор.

(133) база нетиповая? перенеси этот документ ВыгрузкаЗагрузкаДанных.epf в чистую базу.

Что с зацикленностью-то? Пробовал чистить таблицы справочников?

(132) А это результат какого из запросов? (128) или (131)?

(136) Это было (128) А это (131)

_AccumRg1171    330330         41808 KB    29696 KB    12048 KB    64 KB
_Reference35    1793           29376 KB    27080 KB    344 KB    1952 KB
_AccumRg1277    122157         28824 KB    17776 KB    10896 KB    152 KB
_AccumRg1245    130288         21456 KB    16552 KB    4800 KB    104 KB
_AccumRgTn1286    85402          29600 KB    15408 KB    14184 KB    8 KB
_AccumRg1319    150262         19152 KB    13512 KB    5496 KB    144 KB
_Document63    30563          15776 KB    12192 KB    2200 KB    1384 KB
_InfoRg959    178413         17936 KB    10056 KB    7744 KB    136 KB
_AccumRg1134    37237          8144 KB    6624 KB    1408 KB    112 KB
_AccumRg1184    72566          9424 KB    6600 KB    2680 KB    144 KB
_AccumRg1121    69310          8912 KB    6232 KB    2568 KB    112 KB
_InfoRg1006    38203          8664 KB    4136 KB    4392 KB    136 KB
_Document60_VT537    63530          3784 KB    3712 KB    32 KB    40 KB
_Document44_VT316    55828          3656 KB    3552 KB    32 KB    72 KB
_AccumRg1298    23726          5912 KB    3464 KB    2168 KB    280 KB
_InfoRg993    26226          8152 KB    3384 KB    4640 KB    128 KB

(134) Как вариант.
(135) Чистил пока не уперся в то что конфа начала показывать ошибку (69). Но думаю продолжу. Тем более в той базе остались доки да спр и их почти половина осталось от исходного.

(137) Любопытно узнать, что за справочник "_Reference35" который на 1793 строчка занимает второе место по занимаемому месту. И не при индексации ли этого справочника вываливается с ошибкой. (разумеется индексация не проходит и в этой статистике ее нет). Посмотреть бы еще последнюю операцию в профайлере перед падением.

(139) Это некий справочник называется-Справочник.ХранилищеДополнительнойИнформации
В нем я храню фотки сотрудников и вывожу их при открытии справочника физ лиц и еще отображается при прохождении по карточке в столовой.

+(140) фотки мы спецом обработываем перех хранением приводим в объем менее чем 50 кб

(140)  реквизиты этого справочника -сколько и их длина ?

(142) В этом справочнике есть 5 реквизитов.
Из них 2 типа хранилище 1 текс неограниченной длины.

Но вчера при исследовании я удалял это справочник из базы.
Не помогло- ошибка осталась.

(143) а реквизит текст неогранич длины индексируется или нет?

(143) А что с индексами на этих реквизитах?

В этих реквизитах одна индексируется а другая нет.

(146) Попробуй убрать индексы со всех реквизитов на этом справочнике. (или они реально очень нужны? для чего?)
и в (133)
"
БАза отпочковалась но заняло 28,5 ГБ (MDF) "
Размеры таблиц в (137) приведены из этой "распухшей" базы?

(147) Да из этой базы
Уже пробую убрать индексы.
Я даже пытаюсь реквизит неограниченной длины делать 250 символов.
И еще меня смущает что ревизиты названы "Объект" "ИмяФайла"

Кто-нибудь может подсказать как мне избавится от пустых таблиц в скуле от удаленных объектов как РН РС
Они у меня до сих пор висят. Пример
AccumRgAggDict1h446;
AccumRgAggDict2h447;
AccumRgAggDict3h448;
AccumRgDlK449;
AccumRgBfK450;
AccumRgSt451;
AccumRgAggDict1h461;
AccumRgAggDict2h462;
AccumRgAggDict3h463;
AccumRgDlK464;
AccumRgBfK465;
AccumRgSt466;
AccumRgAggDict3h478;
AccumRgDlK479;
AccumRgBfK480;
InfoRgOpt546;
InfoRgOpt559;
InfoRgOpt670;
AccumRgAggDict1h781;
AccumRgDlK782;
AccumRgBfK783;
....

Или я не правильно их удаляю???
Удалял я их так выше уже писал. Просто пытаюсь удалить тот или иной регистр. Конфа показывает ссылки на регистраторах удаляю признак движений у регистраторв и удаляю.
При этом в конфе и в предприятии регистр бесследно исчезает но в скуле их таблицы живут.

(150) а вы кто по образованию если не секрет?

(150) DROP TABLE AccumRgDlK782

в скуле в QA или что там в новых версиях.

(152)+ Это если радикально :).

(151) Я по образвнию военный-инженер. Но вот уже 14 лет я не военный-инженер а 1сник.

(150) Чур меня чур от такого.

(155) Не понял. о чем вы.
Я удаляю чтоб понять на каком объекте у меня трабла.

Решил отписаться.
Перенос данных обработкой ВыгрузкаЗагрузкаДанныхXML
кажется помогло.
Еще проверю данные..

Но база начала загружатся в файловую.
Файловая весит 324 мб slq-ная 458 мб (mdf)

Разве такое возможно?

(157) Так размер mdf совсем не показатель того, сколько данные в скуле занимают.

(158) В скуле в свойствах показывает 402 мб А вот исходная БАЗА показывает 4.404 гб А после сжатия 1.102 ГБ

(157) давно уже известно что выгрузка в dt если в базе имеются  какие либо проблемы только увеличивает ее-эту проблему.

160 постов на тему, которая выеденного яйца не стоит. Все сказано в (51) "dt это сжатый файл и сама база может быть на порядок больше".

Плюс непонятно, нахрена выгружать dt, если скуля нет.
Просто архивировать 1CD и его кидать. 1С так и рекомендует, кстати.

(162) Как раз таки проблема встала - как из скуля делать файловую базу, когда еще предел по файловой еще очень далеко.

(161) Прошу прощения в (51) Это не корректные данные.
Я позже уточнял.

(163) С чего бы он еще очень далеко. Читай (51).

(165) Еще раз уточню что и как было.
1. Самописку начал писать 1го июня 2013го.
2. База была файловой
3. Но поняв что для количества юзеров более 10 файловая по скорости слабовата, а терминал для половины юзеров нельзя создавать принял решение перевести на скуль. На тот момент база весил быть может десятки мб. Это где-то нчачало авгутса.
4. Разработка велась в то время на файловой. И я каждый раз данные чтоб были свежими со скуля грузил в файл.
5.Но в один прекрасный день база отказался грузится со скуля в файловый.
6. Пришлось мне перейти самому в скуль. Это в октябре.
7. Но туту я прочел что у файловой ограничеиние в 4 гига на талицу. А уменя база еще до 200 мб не дошло.
8. на момент поиска проблемы (начало года 2014) у меня скуль показывал от от 2.8 до 4 гига. Но выгрузка была всегда где-то 58-59 мб
9. После решения проблемы база в выгрузке стала 43 мб. А развернутая 324 мб а в скуле 400 мб.