Есть проблема: при долгой работе сервера размер БД растет. Даже при очистке устаревших данных. Характер хранимых у нас данных таков, что через некоторое время эксплуатации системы количество записей выходит примерно на постоянную цифру - разную для каждого клиента. Старые данные удаляются/новые добавляются. Однако - размер базы растет постоянно!!! При стартовом объеме БД примерно в 25-30 мб за 4-5 месяцев она выросла до 700 (!!!) мегабайт! Помогает reload базы - из старой с созданием новой. Объем уменьшился на порядоук... Однако вручную таким заниматься не очень хочется... Может кто-то смог автоматизировать этот процесс???
Или есть какие-то советы по решению сложившейся проблемы??

А как посмотреть в Централе фрагментацию?? Это какой-то параметр, или есть графическая утилита?

В последнее время вообще появилась непонятная проблема: нам привезли базу на испытания. Мы ее подняли. После попыток поанализировать данные централом (не помню уже куда ткнул) появилась ошибка об IO error. После переподнятия база доступна. Однако после того, как опускаешь сервер, она не хочет переписываться!! Что происходит??

ASCRUSПопробуйте после удаления делать REORGANIZE TABLE, это дефрагментирует таблицы и освободит пустые страницы, а далее уже вставка записей и пойдет по этим пустым страницам.

А кто пользовался REORGANIZE TABLE??
Такая ситуация: есть постоянно открытая сессия, которая вначале выполнила select из некоторой таблицы - пусть она называется indval. Есть желание эту таблицу отREORGANIZE'ить. Однако при выполнении команды
REORGANIZE TABLE indval;
происходит зависание процесса, выполнившего эту команду. Есть предположение, что все происходит из-за блокирования таблицы в результате select. Так ли это? Как с этим бороться?

Александр Гoлдун
Это все асбстрактные слова, пока не приведены номера версий, хотя бы
упрощенная структура БД, скрипты для "обычных INSERT" и статистика роста
размера.


Вот наша таблица:

create table INDVAL
(
NCHANNEL_ID numeric(30,0) not null,
VACPER varchar(1) not null,
VVALTYPE varchar(1) not null,
NVALUE numeric(30,6) not null,
VQUALITY varchar(1) not null,
DDATE timestamp not null,
DINPUT timestamp not null
);

/*==============================================================*/
/* Index: RELATION_100_FK */
/*==============================================================*/
create index RELATION_100_FK on INDVAL (
NCHANNEL_ID ASC
);

alter table INDVAL
add foreign key FK_INDVAL_RELATION__CHANNEL (NCHANNEL_ID)
references CHANNEL (NCHANNEL_ID)
on update restrict
on delete restrict;

она практически единственная изменяющаяся в нашей бд (хранит показания счетчиков электричества). Есть процедура очистки, выполняется раз в день. Удаляет примерно 5-10 тыс. записей в день по признаку устаревания (дата показания). Средний объем - 300-400 тыс. записей.
Primary key отсутствует для экономии места на диске.
Вставка записей идет потоком простыми insert'ами.
За время эксплуатации с сентября по январь выросла до 750 мегабайт вместе с лог-файлом. Без него занимала примерно 450 мегабайт. В конце-концов отказалась выполняться на Cyrix 800/256 мб (такое паршивое семейство процессоров из-за одноплатного исполнения - все на борту кроме памяти). Точнее база конечно запускалась, но инициализация приложения происходила за 20 минут, в то время как после unload-reload эта же самая процедура занимала несколько _секунд_. После unload-reload стала занимать 61 мегабайт. По-моему совввввершенно конкретные цифры.

ASCRUS Vadim RomanenkoТакая ситуация: есть постоянно открытая сессия, которая вначале выполнила select из некоторой таблицы - пусть она называется indval. Есть желание эту таблицу отREORGANIZE'ить. Однако при выполнении команды
REORGANIZE TABLE indval;
происходит зависание процесса, выполнившего эту команду. Есть предположение, что все происходит из-за блокирования таблицы в результате select. Так ли это? Как с этим бороться?
Ну вообще то желательно после выполнения SELECT и полного получения курсора делать COMMIT. Это снимет SHARED блокировку с таблицы и позволит выполнять над ней DML команды и REORGANIZE TABLE.

Честно говоря с такой глупостью мы встретились впервые. На АСА. Мы тоже дошли до этого решения. Но как-то не очень мне кажется хорошо, когда простой select лочит таблицу так, что с ней ничего нельзя сделать... Непонятны мотивы.

ASCRUS
Ну вы даете - сэкономили на PK, зато сделали FK с неявным индексом, да еще явный индекс на то же поле :)

м-м-м-м... а где там два индекса на одно и то же поле?? насколько я понимаю, тот индекс генерится автоматически при создании FK. Мы его вручную не добавляли... Скрипт сгенерил мне PowerDesigner. Я честно говоря его даже не смотрел... Да и в студии в списке индексов нет индекса по полю NCHANNEL_ID

ASCRUS[quot michael_]Отстутсвие PK - это плохо.

Но! Причем здесь отсутсвие PK и разбухание БД, если после удаление данных страницы памяти освободились и уже не принадлежат таблице? Не вижу логики.
При вставке записей ASA будет стараться их вставлять по PK или кластерному индексу. Соотвествующе если удаление соотносится с этим же порядком (я так понимаю в приведенном примере записи в основном будут вставлять и удаляться по CHANNEL) - то даже приблизительная физическая сортировка записей в таблице будет давать преимущества в виде меньшей дефрагментированности таблицы и при удалении будут чаще освобождаться страницы до состояния пустых. Из чего я делаю вывод, что самый большой повод разрастаться БД - это допускать сильную дефрагментацию таблиц.


ASCRUS
P.S. Кстати REORGANIZE TABLE по моему нельзя делать на таблицы, у которых нет PK.
Таки да, таки нельзя. Но для экспериментов на стенде добавили индекс - и обнаружили проблемы с блокированием.
Скажу все же, почему мне это кажется дикостью. Потому, что приличные СУБД предоставляют средства для дефрагментации он-лайн. При подключенных пользователях.
По поводу блокирования select'ом таблицы... Например в Оракле по-моему такой глупости нету, как-то решается этот вопрос. Там даже есть такая возможность - зафиксировать состояние БД для сессии. Точнее, данных в БД. (ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE) И чего бы кто ни вставлял в базу, человек, выполнивший эту команду, увидит лишь данные, которые были на момент сериализации сессии. А тут... Обычный селект открывает транзакцию что-ли раз ее нужно закрывать? Коммитом???

ASCRUS Ну тогда это PD "намутил" :)
дело в том, что в списке индексов в студии тоже не видно такого индекса как RELATION_100_FK. Не может так быть, что он просто автоматический??

хотя... я только что сделал unload базы - там почему-то этот индекс (RELATION_100_FK) отсутствует... Мда.

Vadim Romanenko
хотя... я только что сделал unload базы - там почему-то этот индекс (RELATION_100_FK) отсутствует... Мда.
Извиняюсь за дезинформацию. Индекса в базе таки нет. Видать появился глюк в PD при переходе с одной версии на другую. На физическом уровне этот индекс отсутствует... Так что вариант с двумя индексами на одно поле просьба больше не рассматривать...

ASCRUSГм - с чего бы это нам сравнивать версионник Oracle и блокировочник ASA ? Разные архитектуры, разные возможности.
ну да, согласен, я немножко неудачное сравнение привел :) ни к чему конечно. Разные вещи...

Но по поводу селекта... Дело в том, что у нас есть служебная сессия, которая все время висит в бэкграунде и иногда вычитывает некоторые данные из базы. Вот эта сессия и оказалась блокирующей для REORGANIZE TABLE. Никто никаких транзакций не открывал особо. Обычный селект. Просто я никогда не встречал такого тупичка, что после селекта нужно закрывать транзакцию. Как-то специфично уж очень... Это надо как-то пересмотреть наше приложение... Которое впринципе не привязано к конкретной БД. Считается, что если переписать пару процедур - то все будет работать на любом сервере... А ради селектов в АСА грубить такое... Ладно, поглядим. Но все равно это выглядит странно.