Работа с БД при круглосуточной активности пользователей

[pami]

Вобщем задача такая : БД на FB, не на выделенном сервере. Работа с базой круглосуточно (отпуск топлива и товаров на АЗС), т.е. понятия "ночные B/R" неприемлемы. Администраторов как таковых нет. Данные в таблицах храняться определенное кол-во суток и в пересменку хвосты удаляются (где-то за смену удаляется примерно по 3000 записей в каждой из 4-6 таблиц). В пересменку перед удалением делается бэкап без свипа (о ресторах вообще речи нет в течении года, если только не форс-мажор), т.к. пересменки могут быть и 30 мин, а могут и 5. Хотелось услышать мнения гуру о приемлемости такой работы на FB, и если да, то каким оразом организвать свип без последствий для операторов ?

[Лысый]

какой размер базы?

[hvlad]

3000 делитов из 4-6 таблиц - фигня, если конечно там нет десятков сильно неуникальных индексов и длинных цепочек версий.

Бекап делай минимум раз в сутки, по расписанию (т.е. не по желанию юзеров - они могут забить на это дело).
На работе юзеров бекап сильно не скажется (потормозят чуть-чуть), поэтому его можно не привязывать только к пересменке.

Свип - тоже >= 1 раз в сутки по расписанию, лучше когда активность минимальна (думаю с 2:00 до 5:00 можно найти 5-20 мин)

[pami]

Размер БД за год будет не велик... думаю до 500 мегабайт.
С бэкапом вроде нормально - в пересменок по приему/сдачи смены автоматически будет делаться. А вот свип.... В чедулере низя... будет окно выдавать - распугивать операторов... ФибПлюс, не знаете, позволяет запускать фоновый свип через свой API ? Или надо gfix будет запускать как процесс какой-нть фоновый, чтоб не пугать юзеров ?

[hvlad]

С бэкапом вроде нормально - в пересменок по приему/сдачи смены автоматически будет делаться. А вот свип.... В чедулере низя... будет окно выдавать - распугивать операторов...

От него можно элементарно избавиться

ФибПлюс, не знаете, позволяет запускать фоновый свип через свой API ?

Да

Или надо gfix будет запускать как процесс какой-нть фоновый, чтоб не пугать юзеров ?

Тоже можно

[eugeney]

Hi

Вобщем задача такая : БД на FB, не на выделенном сервере. Работа с базой круглосуточно (отпуск топлива и товаров на АЗС),

Судя по задаче тебе не надо удалять, а надо вести лог. В таком случаее можеш использовтаь две базы первая к которой есть справочники во второй веделся лог отпуска товара. После этого данные гленибуть сливаються в омсновную базу. Файл с логом отпуска можеш менять в пересменку т.е. своя база лога для каждой смены.

[pami]

Вобщем попробывал несколько вариантов
1) select count после массового удаления в пересменок. На машинке P3 1200 с 512 Мб сборка мусора занимает где-то минуты 3. Т.е. впринципе не так много, за это время можно покурить. (однако хозяева АЗС жмуться на компютерах... и на слабых машинах будет ж....) И еще, на сколько я понимаю, не происходит продвижения транзакций.
2)Создал отдельный поток и попробывал запускать в нем sweep (компонент pFIBValidator) по расписанию. Тормоза сильные На АЗС это не есть хорошо.
Может есть какой спопсоб заставить свип работать с очень маленьким приоритетом ? Или может есть что-то еще, что поможет ? Заранее благодарен.

[Merlin]

2)Создал отдельный поток и попробывал запускать в нем sweep (компонент pFIBValidator) по расписанию. Тормоза сильные На АЗС это не есть хорошо.

Это говорит либо об очень большом накопившемся за время неделания sweep разрыве, либо о наличии очень плохих индексов, либо о том, что в программе криво организовано управление транзакциями, есть долгоживущие write-транзакции, существование которых не обусловлено требованиями предметной области. При правильной организации sweep на базе такого объёма должен пролетать мухой. Для сравнения - у меня на 10-гиговой с 100 000 транзакций в день (разрыв не превышает 2000 и то главным образом из-за раздолбайства некоторых программеров, висящих в Эксперте на боевой базе) вечерний свип проходит меньше чем за 5 минут.

[pami]

Да делаю на тестовой БД. Разрыв м/у транзакциями маленький 5-6.
Долгоживущих write-транзакций нет. Но специально делаю в БД мусора мегабайт на 8 (т.к. в реальной задаче каждую смену будут массовые удаления...я писал выше). Вот из-за сборки этого мусора свип и тормозит. Можно конечно сразу собирать мусор после удаления (select count), но хрен его знает сколько он будет делаться на слабых машинках, а пересменок невелик. Поэтому и решил попробывать сбор мусора сделать свипом в фоне... Не понравилось...

[Merlin]

Но специально делаю в БД мусора мегабайт на 8 (т.к. в реальной задаче каждую смену будут массовые удаления...я писал выше). Вот из-за сборки этого мусора свип и тормозит.

Ну не верю, не верю. У меня за день его набегает наверное на всю твою базу размером. Машина двухголовая, но свипу без юзерской активности это без разницы, к тому же 5 летней давности, Xeon 900. Индексов по полям типа Yes-No на замусоренных таблицах нет ли? Мусор как создаёшь - не 100 000 апдейтов одной и той же записи? Сколько времени он продолжается? Попробуй ещё не через сервисы по сети, а gfix-ом прямо на сервере. А ещё - насколько я понимаю, слив бензовоза у тебя по любому блокирует работу касс минут на 30-40, тут вообще b/r можно успеть сделать для 500 метровой-то базы.

[pami]

Индексов по полям типа йес-но нет.
Индексов с дубликатами нет - вообще на тестовой БД генерил случайные числа
Мусор создается в основном массовыми удалениями.
Попробывал gfixом запустить параллельно с работой системы - то же самое. (Дело осложняется еще тем, что работа идет с конкретными устройствами и в режиме почти реал-тайм, а они иногда ждать не будут).
Слив бензовоза просто не разрешает продавать из той емкости, куда сливают. Остальное все крутится.
Вобщем пока вижу более-менее приемлемую вещь - свип не в фоне, а сразу в пересменок после удаления хвостов. Попробывал - удаление из 6 баз по 3000 записей и из одной 15000 записей занимает где-то 1.5 минуты (использую команду DELETE... ORDER BY ... DESC ROWS ... из 2-го FB... правда индексов DESC у меня нет... может ли это сильно тормозить удаление ?), а потом запускаю свип из FIBValidatora - тоже где-то 1.5 минуты. Вот такие мысли...

[hvlad]

Попробывал - удаление из 6 баз по 3000 записей и из одной 15000 записей занимает где-то 1.5 минуты (использую команду DELETE... ORDER BY ... DESC ROWS ... из 2-го FB... правда индексов DESC у меня нет... может ли это сильно тормозить удаление ?), а потом запускаю свип из FIBValidatora - тоже где-то 1.5 минуты. Вот такие мысли...

Если уж пользуешь FB2 - БД с какой ODS ?
В FB2 SELECT COUNT делать не нужно - он сам удалит мусор.
Свип запускай только если OIT застряла, т.к. мусор в твоих условиях должен просто отсутствовать.

[hvlad]

2)Создал отдельный поток и попробывал запускать в нем sweep (компонент pFIBValidator) по расписанию. Тормоза сильные На АЗС это не есть хорошо.

Что значит тормоза ? Параллельные запросы тормозят, или просто ЦПУ на 100% загружен ? Если второе - то это ок

Может есть какой спопсоб заставить свип работать с очень маленьким приоритетом ? Или может есть что-то еще, что поможет ? Заранее благодарен.

Он и так имеет пониженный приоритет (внутри сервера)

[Merlin]

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

Так не делают ни с какой СУБД. Данные с датчиков пишут в лог-файлы, а робот их закачивает махом в удобное время.

Вобщем пока вижу более-менее приемлемую вещь - свип не в фоне, а сразу в пересменок после удаления хвостов.

Разумно.

использую команду DELETE... ORDER BY ... DESC ROWS ...

Не въехал, но чё-то оторопь берёт. А чё бы не традиционным способом, типа Delete From Table Where DateRegistration<:Param? Или тем же макаром от засечки по ID? Насчёт Desc индекса - попробовать надо. Удаление быстрее, сборки мусора больше, совокупный эффект оценивается практицки.

[pami]

FB 2.0 Alpa 2 ODS 11.00
Опа ! Для меня оч. приятное откровение, что 2-ка сама мусор будет убирать ! И в каких случаях ? И тогда вопрос - по каким причинам в 2-ке будет накапливаться мусор ?
Тогда запускать свип только если OIT застряла, это вообще для меня иделальный вариант ! Спасибо !

[hvlad]

FB 2.0 Alpa 2 ODS 11.00

Мусор из 3000 записей на ODS11 должен убираться очень быстро, за считанные секунды. Если у тебя, конечно, не десятки версий в цепочках. Есть многократные апдейты одной и той же записи в течение дня ?
Скорми статистику IBAnalist'у

Опа ! Для меня оч. приятное откровение, что 2-ка сама мусор будет убирать ! И в каких случаях ? И тогда вопрос - по каким причинам в 2-ке будет накапливаться мусор ?

В идеале - всё время, если он есть и если OST позволяет. Т.е. SELECT COUNT 2-ка делает сама. Естествено не по всей таблице, а только по тем страницам, на которых мусор был замечен (с момента старта сервера) и опять же OST позволяет. Ещё обрати внимание на новый пар-р GCPolicy в конфиге. По умолчанию он стоит в combined, возможно для тебя будет разница во что его ставить

Тогда запускать свип только если OIT застряла, это вообще для меня иделальный вариант ! Спасибо !

Попробуй и нам расскажи На то она и альфа

[pami]

3000 - это в одной только таблице.
всего где-то по моим подсчетам всреднем будет 30000 - 40000 - 50000.... где то так

Попробывал (БД на той же машине, где и софтинка сама работает) : после удаления мусор на 2-ке автоматически удаляется в фоне примерно за 30 - 50 сек и, что самое главное, практически не напрягая работу опертора (!). Правда, во время сборки мусора, если одновременно несколько колонок заканчивают налив и скидывают инфу в БД, программа отваливается нафик от БД , и соответсвенно сыпятся ошибки (когда мусор не собирается, все работает чудесно). Не знаю, может что-то у меня, а может и в FB что-то...

В логе только это :
PAUL (Server) Tue Jun 21 16:21:48 2005
XNET error (xnet:1891) connection lost: another side is dead

[hvlad]

Попробывал (БД на той же машине, где и софтинка сама работает) : после удаления мусор на 2-ке автоматически удаляется в фоне примерно за 30 - 50 сек и, что самое главное, практически не напрягая работу опертора (!).

Вот и хорошо

Правда, во время сборки мусора, если одновременно несколько колонок заканчивают налив и скидывают инфу в БД, программа отваливается нафик от БД , и соответсвенно сыпятся ошибки (когда мусор не собирается, все работает чудесно). Не знаю, может что-то у меня, а может и в FB что-то...

А вот об этом я хотел бы поподробнее:
1. Какие ошибки выдаёт программа ?
2. Какой номер билда FB2 ?
3. Чему равен GCPolicy в конфиге ?
4. Судя по приведенной записи из лога - падает клиент. это так ? Т.е. сервер остаётся жить ?
5. что после этого говорит gfix -v -f ?
6. Можешь сделать тест, чтобы я у себя воспроизвёл ?

[pami]

Билд 10834
GCPollicy = combined
gfix -v -f ничего не выдает
Падает клиент. Но один раз упала БД.
Выяснил, что проблемы возникают в параллельном потоке, печатающем чеки. Этот поток кое-что и в базу пишет. Однако пока поймать не могу. Пару раз на ExecQuery зависал. Когда его закоментировал, еще где-то. Времени разбираться было некогда - вот сегодня этим займусь. Дело в том, что проект с парадокса переписывался. Там крутилось все отменно и проверено фик знает на скольких АЗС. Вобщем буду сегодня разбираться, если что найду или будут непонятки, сообщу.

[pami]

Так. Кажись FB не причем ! Это наши косяки, появившиеся в результате перехода с одной БД на другую... вобщем исправили старые ошибки, внесли новые. Спасибо огромное, мужики, за помощь, особенно Владу !