Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2004.10.03;
Скачать: [xml.tar.bz2];

Вниз

Как можно поддерживать фиксированный объем базы 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), или наоборот в конце дня смотреть сколько добавилось - столько старых и удалить?


 
sniknik ©   (2004-09-06 20:33) [8]

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


 
Soft ©   (2004-09-07 22:28) [9]

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

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

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



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2004.10.03;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.47 MB
Время: 0.031 c
3-1094115304
DAron
2004-09-02 12:55
2004.10.03
ADOQUERY фильтрация с "and" и "or"


3-1094220146
Thunder
2004-09-03 18:02
2004.10.03
Импорт txt в таблицу БД


1-1095156943
aleks-ran
2004-09-14 14:15
2004.10.03
FastReport 2.46 Не работает переменная COLUMN#


14-1095169635
PVOzerski
2004-09-14 17:47
2004.10.03
Что с анкетой?


3-1094014169
NewDelpher
2004-09-01 08:49
2004.10.03
результат работы sp_lock в таблицу





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский