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

Добрый день. Есть распределенка УТ10.2, в офисе SQL-вариант, в регионе файловый, размер базы ~16Гб. В регионе начало выдаваться сообщение (сабж) при попытке провести/записать документ. Сдается мне, что это один злосчастный РС, доставщийся мне по наследству, упирается в ограничение файловой версии. Проблема в том, что физического доступа в регион нет, терминалки тоже, только телефона, почта и аська. Что можно посоветовать людям, чтобы они смогли хотя бы спокойно доработать день? Поможет ли сжатие таблиц через ТИИ?

Одна из внутренних таблиц занимает слишком много места. Либо оперативно уменьшить её (так же нужно выяснить какая именно), либо sql.

сделать тестирование с режимом "сжатие"

А пока база в регионе сжимается база, с вашего позволения, расскажу о своем горе: Есть регистр сведений, который фиксирует изменение всех объектов ИБ с детализацией до реквизита. Структура его выглядит так: "Основной отбор" по всем измерениям, "Ответственный" и "Ссылка" являются "Ведущими". И вот этот регистр хранит данные с середины 2007 года, записей -- пара десятков миллионов! И этоПри этом трогать его ни в коем случае нельзя, так как "постоянно возникают спорные ситуации" и бла-бла-бла! Может быть есть вариант как-то оптимизировать этого монстра? Ибо если встанут регионы (из-за сабжа), то я себе слабо представляю, как его вычищать.

Up

>>Ресурсы строки неогр. длины валяются в одной таблице, вот она и забита наверно под завязку

вместо того, чтобы нормально настроить права доступа, решили пристроить костыль с квадратными колесами..

Да я как бы прекрасно это понимаю, но писал же -- не мое это! Досталось по наследству!

В регионе поднять Lunux. Поставить туда сервер приложений (вроде для линукса ключ не нужен, но лицензионность нужно проверить. не уверен.). Поставить DB2. И вперед. Или купить ключ на сервер лицензий.

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

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

Тоже склоняюсь к этому варианту, но что делать через, скажем, год? Перебрасывать изменения в копию? Делать вторую копию? Или мы будем уже далеко через год? )))

За год можно написать обработку :) За основу можно взять принцип работы конфы с журналом регистрации действий пользователей.

Сорри, "глубоко" мысль не обдумывал :( зачем он, и нужели онвообще :) Но, если ничего не менять в конфе с этим регистром, - тогда этот регистр нужно периодически выгружать и "обрезать". Однозначно :(

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

"выход один" - не согласен. "Выходов" всегда много. Только не все, и не всегда они приемлемы :( Советы дельные были. Это - избавиться от строк неограниченной величины и оптимизировать регистр. И - ставить прингвина. Кстати, так моему админу и пришлось "выкручиваться" когда вопрос застрял по деньгам :(

ставить пингвина проще чем вести журнал во внешней базе?

Проблема на самом деле несколько обширнее. Например, когда я сюда пришел, обнаружил узел обмена, который не использовался где-то полгода. Изменения озвученного регистра, естественно, регистрировались для выгрузки в этот узел. Я этот узел удалить даже не смог на SQL-ной базе -- 8-ке тупо не хватало памяти. Кое-как извернулся, чтобы его снести. Сейчас даже с обрезкой "раскорячиваться" придется. Причем сейчас на всякий случай еще раз поинтересовался -- регистр этот таки ну очень-очень-очень нужен. К чему я и спрашивал про оптимизацию? Может основные отборы чему-нить поотключать? Чтобы как бы пошустрее работало и на индексы меньше жрало (пальцем в небо, в индексах ни бум-бум).

пингвинистый скуль - тоже скуль... а вот прлезет ли он - ХЗ.  Скольк в филиале юзеров?

"выносить" надо все это г.вно наружу...

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

"Три карты, три карты..."(с) Три таблицы файловой БД - в одной из них строки неограниченной величины хранятся. Мне так кажется именно она сейчас переполняется. Тут уж отборы отключай, не отключай - поможет как "от дохлого осла уши" (Коллайдер)

Измерения --------------------------------------------------------- то-есть персональная ответственность за строку целиком, а не за отдельное поле

Сжатие, кстати, не помогло :( Думаю остановиться таки на таком варианте: создать конфу с одним подобным регистром и запустить его в офисе на SQL'е. Из рабочей базы периодически регламентным заданием вычищать записи и перебрасывать туда сей "журнал". Думаю, оптимальное решение в данном случае. Осталось только вычистить то, что уже имеется :) Всем спасибо за участие.

Как вариант: по данному регистру сделать обмен "однонаправленный". Из файловой версии, через обмен, записи передаются в базу на SQL и после подтверждения обмена - удаляются в файловой версии.