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

max size

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

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

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

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

Tool_1CD1

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

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

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

<?xml version=»1.0″ encoding=»UTF-8″?>
<config xmlns=»http://v8.1c.ru/v8/tech-log»>
<dump create=»true» location=»C:\dumps» type=»3″/>
<log history=»72″ location=»C:\log\error″>
<property name=»all»/>
<event>
<eq property=»name» value=»excp»/>
</event>
</log>
</config>

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

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

 

Поделитесь своим мнением

Свежие записи
Советы и помощь программиста в 1с © 2018 ·   Войти   · Наверх