Как можно поддерживать фиксированный объем базы FB/IB

← →
Влад (2004-09-05 20:04) [0]

Здравствуйте уважаемые.

В общем есть FB база, в нее входит табличка событий events куда постоянно добавляются какие-то сообщения. База большая на текущий момент составляет примерно 30Gb. 99% места занимает таблица events... По ТЗ админ должен иметь возможность задать ограничения на объем. Например, установить, что размер базы не более 5Gb или скажем 1Gb.

Если я буду проверять текущий объем базы, и при достижении граничного значения, удалять наиболее старые записи, то по идее эти записи не удалятся физически. Как сказано в документации по FB, будет использоваться место занятое мусором (удаленными записям) для размещения новых записей.. Здесь самое интересное.. Как мне определить когда исчерпается мусор в базе?? И когда придется удалять следующую пачку устаревших данных? Ведь если вовремя не удалить, тогда размер базы опять увеличится.

Backup/Restore здесь неподходят, сильно много времени требуется чтобы сделать backup и еще больше времени отнимает Restore.. Плюс база на момент Restoring база будет недоступна для добавления поточных событий, а такого нельзя допустить.

Может быть есть какой-то способ который позволяет изменять (сокращать) физический объем базы? Или хотя бы способ узнать сколько места в базе занимает мусор (удаленные записи)?

Спасибо за внимание.

← →
Zacho © (2004-09-05 20:25) [1]

Мусор<>удаленные записи. На http://ibase.ru есть статья о версионной архитектуре, почитай.
А в общем случае способа ограничить размер БД нет. Просто, например, определись, записи за какой период времени тебе нужны и периодически удаляй старые.

← →
sniknik © (2004-09-05 23:28) [2]

вопрос, а как у тебя база в 30Gb образовалась? вроде в firebird/ib она 2 или 4 максимум равна, больше может быть если только она многофайловая.

и странное условие события размером базы ограничивать... логичнее если временем, удалять старые неактуальные уже события... и задавать также, нужны к примеру только события за месяц, остальное в отвал.
(и все автоматом устаканится, для примера, удаляем с утра событие за 1 день предыдушего месяца и пишем сегодняшний, пишется естественно с использованием освободившегося места. точно места конечно не равны но +- и через какоето время база выйдет на рабочий обьем после которого расти не будет)

← →
Влад (2004-09-06 01:18) [3]

на NTFS ограничение 64TB!!
36Gb максимально возможный объем таблицы FB. Потому-то я и заволновался (уже предел скоро).

ну там малость не все так просто. Хранить-то надо по возможности все события. Просто нельзя допустить, чтобы было переполнение, тогда - гайки...

Спасибо за советы, придется так и поступить.

sniknik © (05.09.04 23:28) [2]
Вы меня успокоили!
вариант с удалением 1-го старого события на каждое новое мне особо понравился. Спасибо!

← →
PEAKTOP © (2004-09-06 02:58) [4]

Ну удалите вы события, а толку ?
Если я не ошибаюсь, когда в ИнтерБазе удаляются записи, то всего-лишь их страницы помечаются как пустые, а для новых записей соответственно выделяются новые.
А чтобы удаление старых логов помогло, надо еще как минимум SWEEP делать или Backup=>Restore.
У меня тож когда-то стоял так вопрос по удалению ненужных логов, то проблему решил написанием на основе компонент BacupService и RestoreService проги, которая по таймеру например в 04:00 утра делала Backup, а затем Restore.

← →
sniknik © (2004-09-06 08:30) [5]

> на NTFS ограничение 64TB!!
знакомая цифра ;о), только она относится вроде именно к многофайловым базам. (но в общемто спорить не буду, у меня то таких баз на FB/IB нет, т.что не в курсе)

> вариант с удалением 1-го старого события на каждое новое мне особо понравился. Спасибо!
не одного, видно не достаточно ясно выразился, а периода (в один день к примеру), сделать чтото вроде job-а (как в MSSQL) на 12.00 (начало дня) и удалять по нему 1 самый старый день (Now - 31, при установке сохранять 30дней) а сегодняшний уже без проверок, только добавлять (если по однму событию и каждый раз проверка, удаление это затормолит добавление).
или принять период неделю, тогда джоб установить на воскресенье и удалять данные за неделю. (лутше конечно не точно неделю а все что с датой меньше Now - 30, на случай если по какимто причинам пропустили срабатывание одного/пары предидущих). при установке сожранять не 30 дней а 365 например естественно плясать от этого.

← →
sniknik © (2004-09-06 08:40) [6]

> PEAKTOP © (06.09.04 02:58) [4]
не может быть. это стандартное поведение серверов, использование свободного места от удаленных записей. MSSQL/Access/Perwasvile/даже Paradox так делают, у всех страничная организация, врядли Firebird отличается в этом плане.
добавить к удалению Backup/Restore конечно не проблема но именно после него база будет только возрастать (и притормаживать на реструктуризации), в общем я бы этого не делал (вернее делал бы но гораздо реже чем каждый день после удаления, раз в полгода бы например)

← →
Влад (2004-09-06 20:12) [7]

sniknik © (06.09.04 08:30) [5]

понял, спасибо.
а как быть если день пустой (скажем, был праздник и никаких событий не было). Может лучше раз в день по X самых старых событий удалять (тока вот как определить X), или наоборот в конце дня смотреть сколько добавилось - столько старых и удалить?

> а как быть если день пустой (скажем, был праздник и никаких событий не было).
ну и что? пустой так пустой (где густо где пусто, в середнем будет примерно одинаково).
> Может лучше раз в день по X самых старых событий удалять (тока вот как определить X),
> или наоборот в конце дня смотреть сколько добавилось - столько старых и удалить?
как сделаеш так и будет. а как мне казалось лутше я уже сказал. (хранить данные за период это както оправдано, а вот так плаваюше как у тебя тогда получится то за день то за месяц, для чего это может понадобится?)

Можно сделать двойное условие.

1) При вставке обрабатывается триггер, если количество записей превышает X то удаляем Y.

2) раз в день чистим записи старше определенного промежутка времени.

Как можно поддерживать фиксированный объем базы FB/IB Найти похожие ветки