1с ошибка загрузки информационной базы превышен максимально допустимый размер внутреннего файла

Содержание:

1.       Причины ошибки Превышен размер внутреннего файла

2.       Анализ и возможные варианты решения ошибки Превышен размер внутреннего файла

3.       Проверка настроек подсистем

4.       Способы анализа размеров таблиц базы данных

5.       Варианты решения ошибки Превышен размер внутреннего файла

Ошибка СУБД «Превышен максимально допустимый размер внутреннего файла 1Cv8.1CD» характерная для файловых баз данных 1С, имеющих относительно большой объем данных. В этой статье будут рассмотрены возможные причины возникновения ошибки Превышен размер внутреннего файла в 1С,способы и инструменты для ее исправления.  

1.     Причины ошибки Превышен размер внутреннего файла

Появление ошибки Превышен допустимый размер внутреннего файла возможно как в пользовательском режиме работы (рис. 1), в момент записи данных в базу, так и при попытке загрузить архив базы из dt-файла(рис.2). В обоих случаях в тексте ошибки фигурирует файл 1Cv8.1CD, но причина ошибки не в размере самого файла, а в размерах составляющих его структуру внутренних файлов.

Рис.1. Ошибка в пользовательском режиме работы

Рис.2. Ошибка при загрузке базы из dt-файла

Как Вы можете видеть на выше представленных скринах, размеры файла 1Cv8.1CD в момент возникновения ошибки Превышен максимальный размер внутреннего файла существенно разнятся, т.е. определенного лимита на его объем нет. Этим так же можно объяснить возможность работы баз, размер файла которых может значительно превышать 10 Гбайт. Ограничения есть на размер внутренних файлов1Cv8.1CD. Ознакомится с ними можно в приведенной ниже выдержке из приложения «Особенности работы с различными СУБД» к документации1С:Предприятие. Руководство разработчика.

Структура файловой баз данных

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

Размер каждого из внутренних файлов ограничен:

● для формата версии 8.2.14 ‑ 4 Гигабайта.

● для формата версии 8.3.8 с размером страницы 4 096 байт ‑ 4 Гигабайта.

● для формата версии 8.3.8 с размером страницы 8 192, 16 384, 32 768 и 65 536 байт ‑ 6 Гбайт.  

2.     Анализ и возможные варианты решения ошибки Превышен размер внутреннего файла

Утилита CNVDBFL.EXE 

Начиная с версии 8.3.9в новых информационных базах по умолчанию установлен реализованный в версии 8.3.8 оптимизированный формат файловой СУБД. Проверить какая версия формата используется в вашей базе, можно с помощью утилиты командной строки CNVDBFL.EXE, которая включается в комплект поставки технологической платформы «1С:Предприятие» начиная с версии 8.3.8 и расположена в каталоге «bin» установленной версии(например C:ProgramFiles1cv88.3.18.1334bin).

Рис. 3 Получить информацию о файле 1Cv8.1CD

Выполните команду: C:< путь установки 1С:Предприятие>CNVDBFL.EXE-i<путь к 1CV8.1CD>

Утилита выведет информацию о версии формата файла и размере страницы. Если версия формата ниже8.3.8 или размер страницы равен 4096 байта, то самое простое временное решение, позволяющее быстро восстановить работоспособность, увеличив ограничение на размер внутренних файлов с 4 Гбайт до 6Гбайт – выгрузить информационную базу в dt-файлдля последующей его загрузки в созданную в новой папке информационную базу, либо конвертация в формат 8.3.8 со страницей по умолчанию:

cnvdbfl -c -f 8.3.8 <путь к 1CV8.1CD>

ВНИМАНИЕ! Перед выполнением любых операций с информационной базой сделайте резервную копию.  

3.     Проверка настроек подсистем

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

Настройки подсистемы Работа с файлами

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

Рис.4 Настройки работы с файлами

Настройки хранения истории изменений

Проведите аудит настроек подсистемы хранения истории изменений. Особое внимание следует уделить часто изменяемым объектам с бессрочным хранением версии, т.к. каждая версия – это новая отдельная запись, занимающая место в специальной таблице базы дынных. И точно не стоит включать «на всякий случай» бессрочное сохранение версий, создаваемых при записи, для всех объектов.

Рис.5 Настройки хранения истории изменений

Удаление помеченных объектов

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

Рис.6 Настройка расписания удаления помеченных объектов  

4.     Способы анализа размеров таблиц базы данных

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

К сожалению, готовых утилит для анализа размеров таблиц баз данных в комплекте поставки «1С:Предприятие» не предусмотрено. Тем не менее есть несколько способов определить виновника ошибки.

Загрузка dt-файла в клиент-серверную базу данных

Разберем на примере файловой СУБДMSSQL.

В SQL ServerManagementStudio выберем в обозревателе объектов исследуемую базу и сформируем стандартный отчет «Использование дисковой памяти таблицами». Включив сортировку по убыванию значения в колонке «Данные», мы увидим самые большие таблицы. В моем случае явный лидер -«dbo._InfoRg10162»

Рис. 7 Анализ размера таблиц базы данныхвSQLServerManagementStudio

Далее нам потребуется определить какие данных хранятся в этой таблице. В этом нам поможет метод глобального контекста ПолучитьСтруктуруХраненияБазыДанных(). Вызвать данный метод можно установив точку остановки в любой процедуре, выполняемой в контексте сервера, например в процедуре ПриСозданииНаСервере формы внешней обработки. Указав в табло выражение ПолучитьСтруктуруХраненияБазыДанных(), мы получим таблицу значений с описаниями структуры таблиц, индексов и полей базы данных. Посмотреть ее можно нажав «F2»,либо выполнив команду контекстного меню «Показать значения в отдельном окне». В открывшемся окне выполняем поиск значения «InfoRg10162» в колонке ИмяТаблицыХранения и определяем по колонкам ИмяТаблицы или Метаданные имя, соответствующее объекту метаданных конфигурации — «РегистрСведений.ДвоичныеДанныеФайлов»

Рис. 8 Просмотр структуры хранения базы данных

Стоит отметить, что данный метод требует серверной лицензии 1С.

На момент написания статьи действует акция: антикризисные льготные поставки «1С:Предприятия 8» для разработчиков.

В качестве СУБД для разработки и тестирования удобно использовать следующие версии:

SQL Server 2019 Express является бесплатным выпуском SQL Server, который идеально подходит для разработки приложений для использования на настольных компьютерах, веб-серверах и других небольших серверах.

SQL Server 2019 Developer — это бесплатный выпуск с полным набором функций, лицензируемый для использования в качестве базы данных для разработки и тестирования и не предназначенный для применения в рабочей среде.

Использование сторонних программ для анализа файла базы

Для определения размеров таблиц базы данных, можно воспользоваться программой для просмотра файлов базы 1Сv8.1CD. Tool_1CD позволяет увидеть структуру БД 1С и узнать размер внутренних таблиц. Tool_1CDверсии 0.3.0, поддерживает работу только с базами в формате не выше 8.2.14.

Рис. 9 Tool_1CDверсии 0.3.0

Tool_1CD версии 0.4.0поддерживает работу с базами версии формата 8.3.8.0 и не требует дополнительных операций с базой.

Рис. 10 Tool_1CDверсии 0.4.0

Определив имя «проблемной» таблицы, далее поступаем аналогично первомупримеру(Рис. 8).Выполняем поиск значения «InfoRg10162″в колонке ИмяТаблицыХранениятаблицы, полученной методом ПолучитьСтруктуруХраненияБазыДанных()и определяем по колонкам ИмяТаблицы или Метаданные имя соответствующее объекту метаданных конфигурации.

Подсистема «Инструменты разработчика» 1С 8

На практике меня часто выручает подсистема «Инструменты разработчика» 1С 8

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

В рамках рассматриваемой в статье ошибки, нам будет интересна обработка «Структура хранения БД», в которой есть опция получения размеров таблиц и индексов для файловой СУБД.

Рис. 11 Запуск обработки Структура хранения БД в толстом клиенте

Почти все обработки входящие в подсистему выполнены на обычных формах и потому работают только в толстом клиенте и обычном приложении.

Рис. 12 Выбор варианта запуска подсистемы

Рис. 13 Запуск обработки Структура хранения БД в обычном приложении

По умолчанию опция «Показывать размеры» выключена. Включим этот флаг и выполним сортировку по убыванию в колонке «Размер общий»

Рис. 14 Анализ данных в обработке Структура хранения БД

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

Обратите внимание, опция «Показывать размеры» работает только в 32-битныхприложениях

Рис. 15 Настройка разрядности клиента  

5.     Варианты решения ошибки Превышен размер внутреннего файла

Выбор способа решения ошибки Превышен размер внутреннего файла зависит от результатов анализа и сводится к двум вариантам:

·         Уменьшение размера базы данных;

·         Переход на клиент-серверный вариант работы;

Если анализ выявил таблицы, занимающие «львиную долю» от общего размера внутреннего файла 1Cv8.1CD, то в первую очередь надо разобраться с ними. Как правило это объекты конфигурации, имеющие реквизиты с типом значения Хранилище Значения, в которых хранятся связанные файлы, версии объектов, вложения писем и т.д.

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

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

Взаимодействие между клиентским приложением и файловой СУБД осуществляет кластер серверов «1С:Предприятия 8».

Так же клиент-серверный вариант работы будет решением проблемы при загрузке архива базы из dt-файла

Рис. 16 Загрузка из dt-файла заведомо большой ИБ

Специалист компании «Кодерлайн»

Александр Бачурин

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

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

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

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

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

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

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

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

Что же делать, если каждая таблица вашей базы размером менее 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>

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

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

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

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

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

А дальше начинается самое интересное — нужно попытаться угадать, что именно в структуре вашей таблицы приводит к ошибке индексации.

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

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

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

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

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

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

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

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

Удачи вам!

06.01.14 — 09:18

101 — 09.01.14 — 09:19

102 — 09.01.14 — 09:24

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

103 — 09.01.14 — 09:38

(102) С пустой базы выгрузка загрузка работает

Но то что в (100) не дал положительного результата.

104 — 09.01.14 — 09:43

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

105 — 09.01.14 — 09:46

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

106 — 09.01.14 — 09:56

107 — 09.01.14 — 10:19

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

108 — 09.01.14 — 10:23

(106) Кстати, а размер файла ‘C:UsersmaratDocumentsInfoBase1/1Cv8.1CD’ когда выдало ошибку — не смотрел сколько? И еще можно посмотреть — размер свободного дискового пространства до загрузки и в момент ошибки — чтобы точно узнать — с размером файла связана ошибка или с чем другим.

109 — 09.01.14 — 10:26

110 — 09.01.14 — 12:04

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

Осталось выяснить истинную причину.

111 — 09.01.14 — 12:39

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

112 — 09.01.14 — 12:46

113 — 09.01.14 — 12:48

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

114 — 09.01.14 — 12:50

1. Взял свежую копию скульной базы
2. В нем создал План обмена - назвал "КЛОН"
3. Включил полную миграцию всех объектов.

6. Загрузил в скуль

115 — 09.01.14 — 12:53

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

116 — 09.01.14 — 12:57

А вот почему произошел то что в теме я так и не узнал.

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

1. Демоническое обновление

2. копипаст (имопорт из конф) неторых документов с обычных форм с их обычными формами из 8.2

3. База какое-то время жила на ссд. может быть там что-то было. Хотя сервак новый и до сих пор пашет.

4. Проблема релиза 8.3.3.687…

5. разрабатывали конфу 2-3 человека при чем удаленые помощники быть может они какое то время разработывали в другом релизе….

6. короче фиг знает.

117 — 09.01.14 — 13:01

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

118 — 09.01.14 — 15:02

(115) Я типа такого и предположил в (107).

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

119 — 09.01.14 — 17:25

Обломс

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

Видать данные покоцаны или же все таки конфа виновата.

120 — 09.01.14 — 17:27

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

121 — 09.01.14 — 17:30

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

122 — 09.01.14 — 17:56

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

123 — 09.01.14 — 20:05

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

124 — 09.01.14 — 21:37

(123) Все чисто

125 — 09.01.14 — 21:52

126 — 09.01.14 — 22:31

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

127 — 09.01.14 — 23:37

128 — 10.01.14 — 08:27

  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

Модератор

129 — 10.01.14 — 08:31

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

130 — 10.01.14 — 08:32

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

131 — 10.01.14 — 08:42

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

132 — 10.01.14 — 09:11

Вот картина и что с ним делать не пойму. все вроде ок.

Хотя при отпочковании базы в ПБ в скуле база выросла до 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

133 — 10.01.14 — 09:16

1. Опять создал РИБ
2. Настройка миграции полная
3. Выгрузил в это раз в скульную периферийку.
4. БАза отпочковалась но заняло 28,5 ГБ (MDF)

134 — 10.01.14 — 09:18

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

135 — 10.01.14 — 09:20

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

136 — 10.01.14 — 09:21

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

137 — 10.01.14 — 09:28

138 — 10.01.14 — 09:31

(134) Как вариант.

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

139 — 10.01.14 — 09:34

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

140 — 10.01.14 — 09:39

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

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

141 — 10.01.14 — 09:40

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

142 — 10.01.14 — 09:44

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

143 — 10.01.14 — 09:52

144 — 10.01.14 — 10:01

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

145 — 10.01.14 — 10:01

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

146 — 10.01.14 — 10:32

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

147 — 10.01.14 — 10:42

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

148 — 10.01.14 — 10:44

И еще меня смущает что ревизиты названы "Объект" "ИмяФайла"

149 — 10.01.14 — 11:27

Они у меня до сих пор висят. Пример
AccumRgAggDict1h446;
AccumRgAggDict2h447;
AccumRgAggDict3h448;
AccumRgDlK449;
AccumRgBfK450;
AccumRgSt451;
AccumRgAggDict1h461;
AccumRgAggDict2h462;
AccumRgAggDict3h463;
AccumRgDlK464;
AccumRgBfK465;
AccumRgSt466;
AccumRgAggDict3h478;
AccumRgDlK479;
AccumRgBfK480;
InfoRgOpt546;
InfoRgOpt559;
InfoRgOpt670;
AccumRgAggDict1h781;
AccumRgDlK782;

150 — 10.01.14 — 11:31

Или я не правильно их удаляю???

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

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

151 — 10.01.14 — 11:33

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

152 — 10.01.14 — 11:39

153 — 10.01.14 — 11:40

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

154 — 10.01.14 — 12:06

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

155 — 10.01.14 — 12:30

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

156 — 10.01.14 — 12:37

(155) Не понял. о чем вы.

Я удаляю чтоб понять на каком объекте у меня трабла.

157 — 11.01.14 — 10:56

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

158 — 11.01.14 — 11:48

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

159 — 11.01.14 — 12:03

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

160 — 11.01.14 — 12:09

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

161 — 11.01.14 — 13:22

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

162 — 11.01.14 — 13:24

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

Просто архивировать 1CD и его кидать. 1С так и рекомендует, кстати.

163 — 11.01.14 — 13:37

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

164 — 11.01.14 — 13:38

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

Я позже уточнял.

165 — 11.01.14 — 13:49

(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 мб.

Превышен максимально допустимый размер внутреннего файла

Автор RomanSKV, 21 мар 2015, 16:03

0 Пользователей и 1 гость просматривают эту тему.