Ошибка загрузки из dt. Превышен максимальный размер
Пытаюсь загрузить dt-шку в файловую базу получаю в общем-то обычную ошибку - превышен максимальный размер. Первым делом проверил размеры таблиц в БД (MS SQL). Самая большая была 2.5 гига - РС "Версии объектов". Глянул настройку версионирования. Уменьшил срок хранения по некоторым метаданным с 3 месяцев до 1. Размер таблицы не проверял после этого (нет личного доступа в серверу SQL), но dt'ка уменьшилась с 1,2г до 0.8г. Но даже в таком виде база отказывается загружаться.
Я посмотрел статью и решил проверить вариант номер 2 - ошибку создания индекса. Настроил техжурнал согласно публикации и получил следующее (см скриншот). Как видно ошибка происходит в момент десериализации таблицы РС «Версии объектов». В статье ошибка была связана с создание индекса. И там в логах была строка «CRE ATE INDEX…». Здесь такой нет. Получается ошибка просто при распаковке этой таблицы. Но она сейчас скорее всего меньше даже 2 гигов. Не пойму в чем проблема. У вас есть какие либо мысли? Заранее спасибо всем откликнувшимся.
Загружаю 64-битным клиентом, разумеется.
Я посмотрел статью и решил проверить вариант номер 2 - ошибку создания индекса. Настроил техжурнал согласно публикации и получил следующее (см скриншот). Как видно ошибка происходит в момент десериализации таблицы РС «Версии объектов». В статье ошибка была связана с создание индекса. И там в логах была строка «CRE ATE INDEX…». Здесь такой нет. Получается ошибка просто при распаковке этой таблицы. Но она сейчас скорее всего меньше даже 2 гигов. Не пойму в чем проблема. У вас есть какие либо мысли? Заранее спасибо всем откликнувшимся.
Загружаю 64-битным клиентом, разумеется.
Прикрепленные файлы:
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(5)Судя по описанию, в базе(*.dt) куча версий объектов, для этого нужно столько же индексов "файлов" внутри таблицы размещения данных, этих индексов спокойно может не хватать при малом размере страницы файла.
Аналогия с FAT16 и FAT32, если будет угодно.....
Аналогия с FAT16 и FAT32, если будет угодно.....
(8) Если размер внутренних файлов 1Cv8.1CD по факту больше предельно допустимого для файлового варианта, то увеличение размера страниц, ТИИ, сжатия, реструктуризации и прочие танцы с бубнами скорее всего не помогут.
Единственный выход запустить в файловом - это свернуть базу с удалением документов предыдущих периодов в изначальной базе под SQL.
Если свертка не подходит, то запустить эту базу можно будет только под SQL.
Единственный выход запустить в файловом - это свернуть базу с удалением документов предыдущих периодов в изначальной базе под SQL.
Если свертка не подходит, то запустить эту базу можно будет только под SQL.
(14) Ну я думал, что смогу докопаться до физической причины такого поведения. Ибо ругается на регистр версий объектов. Настройки хранения в нем не меняли уже год или полтора и там максимальная дальность хранения 3 месяца была. То есть размер регистра должен был быть относительно стабильный. Ща еще подрезали до месяца. Не совсем понимаю, что могло с ним произойти за последние месяца 2.. Ибо 2 месяца назад все выгружалось нормально.
Но видимо, придется попросить у тимлида серверную базу с отладкой для работы её копией.
Но видимо, придется попросить у тимлида серверную базу с отладкой для работы её копией.
(11) Очень печально. Надо думать как побороть. Увеличение страницы, как писал выше, не помогло.
Попробовал загрузить в тестовую серверную - все прошло хорошо. Выгрузил из неё дт-шник и опять загрузил в файловую - та же самая ошибка. Если честно, не совсем понимаю физическую природу такой ошибки. Можете хоть как-то объяснить что не так при распаковке этой таблицы?
Я думал, что это не ошибка создания индекса, так как в автор указывает, что в этом случае в техжурнале есть соответствующая строка «CRE ATE INDEX…». А тут получается что ошибка происходит в момент самой распаковки таблицы, еще до построения индекса. Или я ошибаюсь?
Попробовал загрузить в тестовую серверную - все прошло хорошо. Выгрузил из неё дт-шник и опять загрузил в файловую - та же самая ошибка. Если честно, не совсем понимаю физическую природу такой ошибки. Можете хоть как-то объяснить что не так при распаковке этой таблицы?
Я думал, что это не ошибка создания индекса, так как в автор указывает, что в этом случае в техжурнале есть соответствующая строка «CRE ATE INDEX…». А тут получается что ошибка происходит в момент самой распаковки таблицы, еще до построения индекса. Или я ошибаюсь?
(1)
(12)
Загрузили в серверную копию. Запустите в конфигураторе Администрирование - Тестирование и исправление. Выберите Реструктуризацию. Она должна пересоздать таблицы. Уже после пробуйте выгружать в dt и загружать в файловую.
Глянул настройку версионирования. Уменьшил срок хранения по некоторым метаданным с 3 месяцев до 1. Размер таблицы не проверял после этого (нет личного доступа в серверу SQL), но dt'ка уменьшилась с 1,2г до 0.8г.
(12)
Попробовал загрузить в тестовую серверную - все прошло хорошо.
Загрузили в серверную копию. Запустите в конфигураторе Администрирование - Тестирование и исправление. Выберите Реструктуризацию. Она должна пересоздать таблицы. Уже после пробуйте выгружать в dt и загружать в файловую.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот