Предположим, вы сформировали архив базы и теперь пытаетесь загрузить его в файловом варианте. Сначала все идет хорошо, но в какой-то момент возникает ошибка:
Я лично потратил ОЧЕНЬ много времени на поиск решения этой проблемы и в итоге нашел его, что позволило нам создать файловую копию базы данных размером 18 Гб и в итоге сэкономило примерно неделю времени (могу в комментариях рассказать, как было дело, но сейчас речь не о том).
Итак, причин возникновения такой ошибки может быть несколько:
- Размер КАКОЙ-ЛИБО таблицы в базе данных превышает лимит для файловой версии (4 Гб). Если честно, во избежание подобных эксцессов мы проверяли размеры таблиц базы заранее с помощью обработки «SQL базомер» (или аналогов).
- Ошибка связана с глюком особенностями платформы, и вызвана определенной спецификой структуры метаданных выгружаемой конфигурации.
С первым случаем все понятно — если базомер показал превышение лимита по каким-то из таблиц базы, то эти таблицы необходимо почистить. Если речь идет о справочнике или непериодическом регистре сведений, то нужно постараться удалить оттуда ненужные элементы/записи. То же самое относится и к «тяжелым» документам с их табличными частями. В первую очередь следует заняться удалением помеченных объектов, конечно.
Регистры накопления — отдельная тема. Размеры таблиц итогов могут превышать размеры таблиц записей регистра, причем зачастую значительно. Иногда может помочь даже простой пересчет итогов.
Регистры остатков могут некорректно (не по всем измерениям) закрываться, что приводит к ОЧЕНЬ значительному и быстрому разрастанию таблиц итогов. Списание «зависших» остатков регистра накопления может при последующем пересчете итогов дать экономию до нескольких Гб, проверено на собственном опыте у «нерадивых» клиентов. ))
Что же делать, если каждая таблица вашей базы размером менее 4 Гб, но ошибка все равно возникает?
Это значит, что у вас второй случай — проблемная структура метаданных конфигурации. Вероятнее всего, ошибка возникает на этапе создания индексов.
В двух словах опишу ситуацию в целом, чтобы было понятно, словами Виктора Сосновского из 1С. Ниже цитата с партнерского форума:
«При загрузке информационной базы в файловом варианте сначала загружаются данные всех таблиц, а затем создаются индексы. Ошибка создания индекса приводит к тому, что индекс, созданный с ошибкой, и все последующие индексы не создаются. Если в базе много данных, то это приведет к существенному снижению производительности. Полноценная работа с такой базой будет невозможна.»
Нужно узнать, какая именно таблица приводит к ошибке при создании индекса.
Включаем технологический журнал — в папку «С:Program Files (x86)1cv82\__НомерВерсииПлатформы__inconf» (или аналогичную, __НомерВерсииПлатформы__ подставьте свой) кладем файл logcfg.xml примерно следующего содержания:
<?xml version=»1.0″ encoding=»UTF-8″?>
<config xmlns=»http://v8.1c.ru/v8/tech-log»>
<dump create=»true» location=»D:1CBASESdumps» type=»0″ prntscrn=»true»/>
<log history=»3″ location=»D:1CBASESlogs»>
<event>
<eq property=»name» value=»dbv8dbeng»/>
</event>
<event>
<eq property=»name» value=»excp»/>
</event>
<property name=»all»/>
</log>
</config>
Внимательно следим за тем, чтобы каталоги для дампов и логов:
- Существовали
- Различались
- Были доступны для чтения и записи тому пользователю Windows, от лица которого вы запускаете конфигуратор.
Перезапускаем конфигуратор (при этом включается технологический журнал) и заново пробуем загрузить наш .DT. После возникновения ошибки идем в каталог для логов, находим там файл лога, содержащий нашу ошибку, и внимательно читаем его.
Первое же вхождение EXCPCNTX в логе в моем случае указало на команду, которая вызвала ошибку: CREATE INDEX _Accum27148_ByDims_TRRRRRRRRRSSR (у вас название индекса будет другое).
По цифрам из названия индекса с помощью обработки «Структура хранения таблиц базы данных» (или аналогов, которые умеют показывать индексы) находим, какой таблице принадлежит данный индекс. У меня это оказалась таблица оборотов одного из нетиповых регистров накопления.
А дальше начинается самое интересное — нужно попытаться угадать, что именно в структуре вашей таблицы приводит к ошибке индексации.
В первую очередь следует смотреть, какие поля входят в индекс. Как выяснилось, платформа ОЧЕНЬ не любит, когда совокупный размер ключевых полей индекса становится значительным. В частности, она не любит индексировать длинные строки — так, в моем случае в индекс попадало измерение с типом СТРОКА (500) и оно вызывало ошибку. Другой представитель фирмы «1С» высказался на партнерском форуме еще в 2007 году:
«Если длина ключа оказывается близкой к 2К, то начинается резкий рост размера индексов с рядом неприятных последствий.«
И действительно, в 2013 году ничего не изменилось — в подобных случаях наблюдается лавинообразный рост размеров индекса на файловой базе. А когда таблица индекса превышает лимит в 4 Гб, загрузка .DT останавливается с ошибкой.
Лично мне помогло отключить для проблемного измерения флажок «Использование в итогах», т.к. в реальности итоги по нему не требовались. Оно перестало попадать в саму таблицу оборотов и, как следствие, в индекс таблицы оборотов. Есть и другие способы — более строго ограничить размер строки, например. Читал, что некоторым это помогало.
Эти изменения необходимо применить к информационной базе, при этом произойдет реструктуризация вашей таблицы.
Если изменения внесены на SQL-копии базы, то после этого нужно заново выгрузить .DT и попытаться перезагрузить его в файловой версии.
Если SQL-копии нет под рукой, то можно попробовать исправить прямо на вашей недозагруженной файловой копии. После принятия изменений запускайте «Тестирование и исправление» в режиме реструктуризации таблиц базы данных. Индексы будут созданы платформой заново и, можно надеяться, уже без ошибок.
Кому особо не повезло и ошибка вылезла снова — тому следует повторить сначала всю процедуру, начиная с анализа логов. Возможно, проблемная таблица была не одна, или вам не удалось решить проблему с размерами полей, входящих в индекс.
Удачи вам!
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Мир этому дому!
Спасибо за информацию — взял на заметку. Может пригодится.
спасибо большое за информацию
Зачем так сложно?
Качаем Microsoft SQL Server 2008 R2 Express
Здесь
Читаем раздел Установка Microsoft SQL Server 2008 R2 Express
4 часа и грузим любой DT.
Хотя… информация в статье приведена полезная.
(3) Evgen.Ponomarenko, не всегда локальная копия на сиквеле — это именно то, что нужно. Бывает, что нужна именно ФАЙЛОВАЯ база. Пример, зачем это нужно, я приводил Вячеславу Гилеву в его теме про скорость работы файловой и серверной версий
(4)
Опираясь на Ваш пост (44)
Не факт, что повышение производительности в два раза стоит таких усилий.
К стати, зачастую двойной прирост производительности можно получить:
1) Выполнив корректно сжатие скульной базы, в файловой — это достигается простой загрузкой DT.
2) Можно запустить операцию ночью, когда нагрузка на сервер минимальна
3) Можно выгнать нафиг пользователей из базы, все равно операция монопольна.
4) Можно удалить вручную без проверки целостности
5) Можно выполнить операцию на более мощном серваке, на более мощном компе.
6) Поговорить с админом, в конце концов, резервы производительности всегда есть.
Но ради двойного прироста производительности — вряд ли игра будет стоить свеч.
Но для расширения кругозора — статья полезная, спору нет!
(5) Evgen.Ponomarenko, можно и дальше перебирать варианты, но в реальности наши возможности были довольно ограниченными. На момент выгрузки в файловую базу все реально доступные нам тогда средства повышения производительности серверной базы нами уже применялись (так, ночное монопольное удаление мы практиковали и раньше, а мощностей других не было). Прирост производительности в два раза позволил нам выполнить это удаление за одну неделю вместо двух, и это было очень неплохо.
(6)
мои соболезнования… что, не ужели удаление 100000 может занимать неделю? Боже, что делается!
(7) Evgen.Ponomarenko, реально там было несколько сот тысяч объектов разных типов, а контроль ссылочной целостности приходилось делать своим алгоритмом вместо типового платформенного, т.к. типовой тупо зависал.
В общем, муторная была задача, так что соболезнования принимаются )))
Огромное спасибо за статью!
Благодаря ей нашел причину ошибки загрузки («Превышен максимально допустимый размер внутреннего файла»). Оказалось, что в одном из регистров сведений у одного из измерений стоял тип Строка (250) и из-за этого при загрузке из ДТ файла в файловую базу разбухал индекс этого поля. Теперь буду знать, что нельзя использовать длинные строки в ключевых полях, по которым строятся индексы…
Еще раз спасибо!!!
(9) DERL, я рад, что моя статья реально кому-то помогла. Я сам промучался с этой проблемой как раз из-за того, что подобной статьи нигде не было…
Спасибо, полезная информация.
(3) Evgen.Ponomarenko,
4 часа и грузим любой DT.
ну а если я хочу копию базы развернуть на своём домашнем компе?
мне с собой серверный ключ приносить каждый вечер?
(12) EarlyBird, в принципе, можно себе скачать и установить какую-нибудь бесплатную СУБД для этих целей.
Но я говорил о том, что есть ситуации, когда файловая версия работает быстрее серверной и именно поэтому предпочтительна. Не говоря уже о том, что тупо удобнее загрузить .DT в файловом варианте, чем возиться с установкой PostgreSQL под винду, например.
А такие ошибки в структуре метаданных, как индексируемые поля огромного размера, вообще полезно иногда находить и исправлять, кмк.
(13) поможет ли бесплатная СУБД ?
Я могу себе установить бесплатный MS SQL, но увы, не бывает бесплатных серверов 1С.
Клиент-серверная модель требует не только клиентской лицензии, но и серверной, значит нужен серверный ключ.
(14) EarlyBird, и то правда )))
Работа во франчайзи в этом смысле как-то расслабляет, т.к. сервера с лицензиями всегда под рукой…
Спасибо автору и низкий поклон за потраченное время и полезную статью!
У меня в том году тоже возникла проблема с загрузкой базы в файловый формат.
(В боевой базе УТ сидит до 50 активных юзеров, поэтому она конечно работает в клиент-серверной модели, но для своих программистских задач я время от времени делал файловую копию. Всё-таки она гораздо удобнее для отладки.)
Разбираться там было некогда, поэтому на проблему забили, отказались от регулярной перегрузки в файловый формат.
Чтение статьи вдохновило вернуться к проблеме и попробовать порешать.
Включил журнал, сделал загрузку, получил ошибку. Узнал имя таблицы.
Взял «SQL базомер», посмотрел размер косячной таблицы. С немалым удивлением увидел цифру 8 ГБ…
…
Оказалось, это справочник Вложения Электронных писем, 49 тысяч элементов. Просто менеджерам очень нравилось отправлять счета и договоры через менеджер контактов в УТ.
…
В общем, проблема была решена за пару часов. Спасибо автору, теперь у меня снова есть удобная для отладки, актуальная тестовая копия боевой базы 🙂
(16) Пацталоцци, всегда рад помочь!
Теперь, наверное, не только проблема с выгрузками решилась, но и база уменьшилась в размерах ))
Вдогонку: в вашем случае можно было и не возиться с техжурналом, а сразу взять базомер — эффект был бы тот же.
Спасибо за статью! Помогло!
Спасибо, помогло! В моем случае был индексный файл таблицы хранилища системных настроек (103 тыс. записей)
если я правильно понял, то если причина 2, тогда данные будут загружены полностью, но индексы не создадутся. Последующее за загрузкой тестирование исправление должно восстановить индексы. Как думаете?
у меня типовая УТ11, не хотелось бы вносить изменения в конфигурацию..
(20) a1089, если проблема в структуре метаданных, то сначала необходимо исправить ошибки, а потом делать тестирование и исправление с реиндексацией, иначе ТИИ не поможет.
Если конфигурация типовая, то проблема вряд ли в метаданных — скорее, какая-то из таблиц непомерно распухла.
У меня был недавно неудачный случай, когда большая база отказывалась загружаться в файловом варианте, хотя каждая таблица по-отдельности не превышала 4Гб. Техжурнал показал, что проблема возникла еще на этапе загрузки данных, не доходя до индексации. К сожалению, не было времени разобраться более детально, что помешало загрузке.
Вот щас у меня такая же история будем пытаться исправить
я правильно понял, что индексы создаются уже после загрузки всех таблиц данных, и если не загружены какие-то таблицы, то до индексов точно не дошло, да? просто судя по sql-базомеру все таблицы в пределах 3 Гб, но ошибка вываливается
(23) Anzati, да, правильно.
Если не загружается именно таблица, то проблема не в индексах, а в чем-то другом.
Я однажды столкнулся с такой ситуацией, но сам победить ее не смог и плюнул на это дело.
По идее, нужно снова обращаться на партнерский форум.
Там, если захотят помочь, наверняка попросят включить техжурнал и прислать логи с ошибкой (у меня в статье описано, как это сделать).
Удачи!
(24) если интересно, то проблему нашёл. В базе был документ смс-рассылок, в котором длина строки составляла 1000 символов. Хоть эта таблица весила всего 1,5 ГБ, но всё упиралось именно в неё. Как только удалил для пробы все документы, база успешно загрузилась. Причину так и не понял, слышал, что индексы длинных строк разрастаются в геометрической прогрессии, но тут ведь даже до индексов не доходило.
(25) Anzati, спасибо, это интересная информация.
У меня в статье было написано про разрастание индексов длинных строк, но что сама таблица может не загружаться из-за длинных строк — такого не слышал. Добавлю в статью в качестве еще одного предположения.
Полезно!
Добрый день. Спасибо за статью, очень помогла.
Тоже столкнулся. Строк 3 056 943. Есть индекс по строковому полю длинной 50 символов, по дате и по булево. Пробую убрать индекс по строке.
Спасибо за статью!
Статья частично помогла мне подойти к решению проблемы. У меня загрузка ДТ была с ошибками: ‘CRE ATE INDEX _SystemSett_BySepUse_LL, _SystemSett_ByKey_SSS, _SystemSett_BySepUse_LL, _SystemSett_ByKey_SSS. Это индексы таблицы _SystemSettings (хранилище системных настроек). К сожалению, что делать дальше в данной статье не рассматривается, но я решение нашёл на . Свои обработки я опубликовал в 97 сообщении темы.У кого такая-же проблема рекомендую обязательно прочитать с 1 по 14 сообщения и 36 (при желании и наличии свободного времени можно и всю ветку осилить, но в середине там в основном спам). Так-же приведённые обработки рекомендуется использовать только после анализа чисто своей проблемы и допиливания под себя.
P.S. пишу ссылку на форум в этом месте, т.к. мне после этой статьи (которую я нашёл быстро) пришлось ещё долго «плутать» перед тем как найти тему форма, где описывается решение именно моей проблемы. Надеюсь прямая ссылка отсюда кому-нибудь поможет быстрее решить его проблему))
Спасибо помогла статья!!!
Добрый день! У меня платформа 8.3. Управление торговлей. Есть выгруженная информационная база размером в 900 мб. Разворачиваю ее в файловый варианта работы. Выходит ошибка «Превышен максимально допустимый размер внутреннего файла». Размер базы составило 9,5 Гб. Попробовал установить Клиент — Сервер, все поставил но база не запускается пишет нет лицензии. Почитав на форумах понял что нужна лицензия на Сервер1С. Помогите советом разобраться. Есть только выгруженная информационная база.
База SQL весила около 70 гигов. Почистил все что можно в основном регистры самописные,письма база стала весить 20 гигов, ни одной таблицы не осталось которая превышает 4 Гб, самая большая 1 ГБ, но база упорно не хотела восстанавливаться в файловую версию!!! Благодаря этой статье запустил тех журнал, увидел там ошибку на регистр который весит 180 Мб, нашел там измерении в котором размер строки указан 500, убавил его до 100 и все загрузилось без проблем. Спасибо!!! СУПЕР!!