Есть проблема: при долгой работе сервера размер БД растет. Даже при очистке устаревших данных. Характер хранимых у нас данных таков, что через некоторое время эксплуатации системы количество записей выходит примерно на постоянную цифру - разную для каждого клиента. Старые данные удаляются/новые добавляются. Однако - размер базы растет постоянно!!! При стартовом объеме БД примерно в 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. Никто никаких транзакций не открывал особо. Обычный селект. Просто я никогда не встречал такого тупичка, что после селекта нужно закрывать транзакцию. Как-то специфично уж очень... Это надо как-то пересмотреть наше приложение... Которое впринципе не привязано к конкретной БД. Считается, что если переписать пару процедур - то все будет работать на любом сервере... А ради селектов в АСА грубить такое... Ладно, поглядим. Но все равно это выглядит странно.

ASCRUS
Не верю, что можно написать приложение, которое одновременно эффективно с разными СУБД будет работать - у каждой будут свои ньюансы. В данном случае для ASA COMMIT после SELECT и есть такой "ньюанс" :)

:) ну да, наверное. Это именно "ньюанс" АСА. Оооочень такой специфичный ньюанс...

АСА 9.0.1

Александр Гoлдун
P.S.
ASCRUS, может стоит внести в FAQ пункт сам знаешь о чем? Я устал
повторять одно и то же. Все, с этого момента выдача информации о том,
исправлена ли ошибка, и если да, то в каком EBF - платная услуга :)
Posted via ActualForum NNTP Server 1.1
М-м-м... А при чем тут - исправлена ошибка или нет?? Я не видел тут никакой ошибочности. Все растут впринципе. Просто у разных СУБД есть свои средства дефрагментации. И изначально вопрос был об этом.
А потом - о том, что селект лочит таблицу. И Reorganize Table тогда не работает.
Вроде нигде ни о каких ошибках речь не шла...

А не обновили базу до АСА 9.0.2 по одной единственной причине - когда ее ставили на необслуживаемую станцию, тогда был только 9.0.1. И после этого еще туда не ездили. Но обновление естественно будет произведено как только появится возможность.

Александр Гoлдун
Постоянный рост базы при отсутствии роста объема хранимых данных я
считаю ошибкой сервера. У себя такого не наблюдаю. Повторить на свежем
ASA 9.0.2 не смог. Отсюда предположение, что возможно эта ошибка уже
исправлена.


Мммм... А не могли бы Вы сделать такое: посмотреть сколько занимает база с установившимся размером (при удалении/добавлении одинакового кол-ва записей) и после reload??

Интересно - сколько засоряет АСА при таком подходе. Возможно, она тоже сократится в несколько раз? После релоада? Просто в этом случае вопрос с автоматизацией unload/reload все равно остается... В связи со спецификой наших задач необходимо минимальное место для БД...

Интересно... Что-ж. Попробуем перевести проект на новую версию АСА. Спасибо за тестирование.

А как правильно рубить log-файл? Например, можно ли сделать так, чтоб он был не больше определенного размера??? А то я говорил - у нас лог получился гораздо больше самой базы... Вернее - не гораздо, но очень даже сравнимо.

Спасибо всем за комментарии!! Будем разбираться дальше :)

Dim2000А может быть, всё-таки купить винт побольше? Или речь идёт о БД для тамагочи (в смысле, КПК :))?

Нет, все гораздо хуже - речь идет о компе, который грузится и работает на флешке :) Это наверное еще хуже... хотят впихнуть Линукс и АСА с базой на 128 метров. А это знаете ли... Думаешь о каждом лишнем мегабайте :)

Кстати! Я там выше кажется упоминал, что больше винт не помогает. На определенном этапе фрагментации приходит ТАКОЕ затупление при обращении к базе... Что то, что выбиралось за пару секунд после ребилда, выбирается минут 15. Так что наверное стоит грести в сторону Reorganize Table в любом случае.

michael
Поэтому unload/relad хотя бы раз в квартал - хорошее решение практически для любой базы.
Так вот - вернемся к моему вопросу :) Как бы это автоматизировать??? :)