vas700добрый день всем....ну неужели никто не "дефрагментировал, сжимал" базу...может быть хоть ссыльку дадите где можно почитать про это....
заранее благодарен..... Вам может помочь реорганизация данных в базе данных. При длительной эксплуатации таблицы и индексы могут занимать больше места, чем это необходимо. При этом частично заполненная страница с данными или индексами бэкапится целиком, что даёт потенциал для уменьшения размера бэкапа. Кроме того, такие частично заполненные страницы могут снизить производительность за счёт увеличения высоты индекса и за счёт уменьшения эффективности кэширования.
Сведения о том, как таблица и её индексы лежат на диске, вы можете получит командой oncheck -pT имя_базы_данных.имя_таблицы (например, oncheck -pT mydatabase.mytable). Более подробно можно поискать в Information Center для IDS 10
Явной команды для реорганизации данных в Информиксе нет, но того же эффекта можно добиться перестройкой индекса для индекса или любым физическим переупорядочением таблицы (кластеризацией индекса, выделением таблицы в отдельный dbspace - alter fragment on table tab_name init in dbspace_name) для таблицы. При этом можно столкнуться с целым рядом технических препятствий, поэтому я всегда стараюсь проверить замысел на тестовом окружении (например, может случиться длинная транзакция при alter fragment on table init in , если база данных с журналированием транзакций, а таблица - велика; например, если индекс обслуживает ограничение (constraint), то команда удаления индекса покажет, что индекс был удалён, но физически индекс не будет ни удалён, ни перестроен - он станет неявным; попытка же создать заново такой индекс будет неуспешной - сервер скажет, что индекс на таком наборе столбцов уже существует). Да и сама команда oncheck -pT ставит shared-лок на таблицу, что делает её недоступной для модификаций.
Дело, однако, стоит того, потому что уже на ваших масштабах возможно получить значительный выигрыш и в дисковом пространстве, и в производитености.

P.S. Наиболее радикальным способом описанной выше идеи является экспорт базы данных и последующий её импорт, но продолжительное время простоя делают его малопривлекательным.