Превышен размер внутреннего файла 1с. Ошибка БД «Превышен максимально допустимый размер внутреннего файла

28.01.2019

При использовании файлового варианта информационных баз, нередко появляется ошибка «Превышен максимально допустимый размер внутреннего файла», связанная прежде всего с особенностями реализации самого файлового режима. В его составляющую входит 4 файла:

Файл описания структуры таблицы
Файл индексов(вынесены из основного файла)
Файл значений
Файл записей

Также накладываются ограничения, такие как: максимальный размер внутреннего файла не должен превышать 4 ГБ, длина ключа в индексе не может превышать 1920 байт и наконец, количество полей для индексации не должно превышать 256 полей. Самым главным для нас является ограничение в размере файла 4 ГБ. А как же так? Скажете Вы. Есть файлы базы данных и по 10 и по 12 ГБ. Да все верно- это означает что ни один из внутренних файлов не превысил 4 Гб. Смею Вас огорчить. Все таки максимальный объем базы данных, самого того файла 1Cv8.CD все таки ограничен 16 ГБ по умолчанию(но даже это можно обойти), так как это ограничение адресации журнала файловой системы NTFS(файлы 16Гб не копируются в Windows, так как при сбое чтения/записи на фрагменте который больше этих самых 16Гб ОС не может контролировать целостность файловой системы.)

Для решения данной проблемы необходимо вычислить, какая же именно таблица занимает очень много места. Для этого можно воспользоваться сторонней программной Tool_1CD, которая и позволяет заглянуть внутрь файла 1Cv8.CD, а именно определять размер таблиц, делать выгрузку в XML формат и многое другое.

Для решения необходимо уменьшить размер этой самой таблицы или перевести в SQL вариант. Так как приобрести SQL сервер довольно затратно, опытным путем ищем эту таблицу. Обычно это бывают «тяжелые документы» с большой табличной частью, громоздкие справочники, особенно часто регистры накопления. Прежде всего удалите из базы все помеченные на удаление элементы. Затем сделайте пересчет итогов(если «косяк» в регистре накопления, то иногда помогает). Регистры остатков могут неверно закрываться, что приводит к резкому разрастанию таблиц итогов. Списание «зависших» остатков может освободить до нескольких Гб.

Бывает так, что все таблицы меньше 4 ГБ, но ошибка все равно возникает. Данная ситуация намного сложнее. Здесь кроется проблема в структуре матаданных конфигурации, а именно в индексации. В момент загрузки информационной базы из dt файла первым делом загружаются данные всех таблиц, а уж после — индексы. В какой то момент создания индекса, возникает ошибка и последующие индексы не создаются, что прекращает загрузку и вызывает ошибку. Для того, чтобы узнать какая таблица сбоит при создании индекса- делаем следующее:

Включаем технологический журнал
Cоздаем пустой файл ogcfg.xml следующего к примеру содержания

и кладем его в каталог conf, например C:\Program Files\1cv82\8.2.19.130\bin\conf

проверяем, чтобы логи и файлы создавались и перезапускаем конфигуратор и начинаем загрузку заново. после возникновения ошибки идем в log файл в нашей пвапке C:\log\error, открываем и ищем на каком индексе появилась ошибка.
Далее при помощи программы Структура хранения таблиц базы данных ищем сам объект метаданных.
Ну а дальше опытным путем ищем либо длинных реквизит этого объекта, либо свойстве приводящая к сбою построения индекса и продолжаем пробовать, пробовать и пробовать, пока не придем к решению.
После удачных манипуляций телаем тестирование и исправление. В результате чего все индексы перестроятся заново и база будет полностью работоспособна. Удачи!

Предположим, вы сформировали архив базы и теперь пытаетесь загрузить его в файловом варианте. Сначала все идет хорошо, но в какой-то момент возникает ошибка:

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

Я лично потратил ОЧЕНЬ много времени на поиск решения этой проблемы и в итоге нашел его, что позволило нам создать файловую копию базы данных размером 18 Гб и в итоге сэкономило примерно неделю времени (могу в комментариях рассказать, как было дело, но сейчас речь не о том).

Итак, причин возникновения такой ошибки может быть несколько:

Размер КАКОЙ-ЛИБО таблицы в базе данных превышает лимит для файловой версии (4 Гб) . Если честно, во избежание подобных эксцессов мы проверяли размеры таблиц базы заранее с помощью обработки " " (или аналогов).
Ошибка связана с глюком особенностями платформы, и вызвана определенной спецификой структуры метаданных выгружаемой конфигурации.

С первым случаем все понятно - если базомер показал превышение лимита по каким-то из таблиц базы, то эти таблицы необходимо почистить. Если речь идет о справочнике или непериодическом регистре сведений, то нужно постараться удалить оттуда ненужные элементы/записи. То же самое относится и к "тяжелым" документам с их табличными частями. В первую очередь следует заняться удалением помеченных объектов, конечно.

Регистры накопления - отдельная тема. Размеры таблиц итогов могут превышать размеры таблиц записей регистра, причем зачастую значительно. Иногда может помочь даже простой пересчет итогов.

Регистры остатков могут некорректно (не по всем измерениям) закрываться, что приводит к ОЧЕНЬ значительному и быстрому разрастанию таблиц итогов. Списание "зависших" остатков регистра накопления может при последующем пересчете итогов дать экономию до нескольких Гб, проверено на собственном опыте у "нерадивых" клиентов.))

Что же делать, если каждая таблица вашей базы размером менее 4 Гб, но ошибка все равно возникает?

Это значит, что у вас второй случай - проблемная структура метаданных конфигурации. Вероятнее всего, ошибка возникает на этапе создания индексов.

В двух словах опишу ситуацию в целом, чтобы было понятно, словами Виктора Сосновского из 1С. Ниже цитата с партнерского форума:

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

Нужно узнать, какая именно таблица приводит к ошибке при создании индекса.

Включаем технологический журнал - в папку "С:\Program Files (x86)\1cv82\__НомерВерсииПлатформы__\bin\conf\ " (или аналогичную, __НомерВерсииПлатформы__ подставьте свой) кладем файл logcfg.xml примерно следующего содержания:

Внимательно следим за тем, чтобы каталоги для дампов и логов:

Существовали
Различались
Были доступны для чтения и записи тому пользователю Windows, от лица которого вы запускаете конфигуратор.

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

Первое же вхождение EXCPCNTX в логе в моем случае указало на команду, которая вызвала ошибку: CREATE INDEX _Accum27148_ByDims_TRRRRRRRRRSSR (у вас название индекса будет другое).

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

В первую очередь следует смотреть, какие поля входят в индекс. Как выяснилось, платформа ОЧЕНЬ не любит, когда совокупный размер ключевых полей индекса становится значительным. В частности, она не любит индексировать длинные строки - так, в моем случае в индекс попадало измерение с типом СТРОКА (500) и оно вызывало ошибку. Другой представитель фирмы "1С" высказался на партнерском форуме еще в 2007 году:

"Если длина ключа оказывается близкой к 2К, то начинается резкий рост размера индексов с рядом неприятных последствий. "

И действительно, в 2013 году ничего не изменилось - в подобных случаях наблюдается лавинообразный рост размеров индекса на файловой базе. А когда таблица индекса превышает лимит в 4 Гб, загрузка.DT останавливается с ошибкой.

Лично мне помогло отключить для проблемного измерения флажок "Использование в итогах", т.к. в реальности итоги по нему не требовались. Оно перестало попадать в саму таблицу оборотов и, как следствие, в индекс таблицы оборотов. Есть и другие способы - более строго ограничить размер строки, например. Читал, что некоторым это помогало.

Эти изменения необходимо применить к информационной базе, при этом произойдет реструктуризация вашей таблицы.

Если изменения внесены на SQL-копии базы, то после этого нужно заново выгрузить.DT и попытаться перезагрузить его в файловой версии.

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

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