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

hvlad · Сообщение **hvlad** » 22 июн 2005, 11:10

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

Ну вот - а то "сборка мусора, сборка мусора"

pami · Сообщение **pami** » 22 июн 2005, 16:50

Тэкс... рано радовался
Весь день ковырялся с потоками, крит. секциями и т.д. и т.п. и все же прихожу к выводу, что какие то бяки есть в FB2. Вобщем, как бы я потоки не запускал, какие бы синхронайзы, мьютексы и т.д. не делал, если в базе в фоне идет сборка мусора, либо отваливается клиент, либо БД, либо зависание (но я думаю, это следствие). Если сборки нет, работает как часы, как не изголяйся !

gfix -v -f после моих экспериментов показывает :
Number of record level errors : 1
Number of index page erors : 45
вот 2 последних записи из лога
PAUL (Server) Wed Jun 22 16:42:52 2005
Database: D:\DEVELOP\DATA\STATIONDATA.GDB
Index 5 is corrupt (missing entries) in table STATIST (161)
PAUL (Server) Wed Jun 22 16:42:52 2005
Database: D:\DEVELOP\DATA\STATIONDATA.GDB
Relation has 4 orphan backversions (493835 in use) in table STATIST (161)

hvlad · Сообщение **hvlad** » 22 июн 2005, 16:52

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

pami · Сообщение **pami** » 22 июн 2005, 16:54

Бррр... проблематично... но попробую

pami · Сообщение **pami** » 23 июн 2005, 15:00

Все ! Разобрался ! Тяжелое наследие прошлого. FB не причем, сборка мусора в 2-ке вообще песня !

hvlad · Сообщение **hvlad** » 23 июн 2005, 15:38

pami писал(а):Все ! Разобрался ! Тяжелое наследие прошлого. FB не причем, сборка мусора в 2-ке вообще песня !

Ну вот - хоть кому-то сборка мусора угодила

Поручик

2 pami

На АЗС обязательно должна быть пересменка с соответствующей процедурой в управляющем ПО - сдача отчетов перелогинивание и т.п. Тогда можно запускать долгоиграющие обслуживающие процедуры.

Мне приходилось писать прогу для АЗС. Поачалу были проблемы, что операторы ночью в определенный момент RESETили тачку, а потом списывали все на сбои в программе. Пришлось вести логи работы программы пока самых продвинутых операторов не уволили.

При грамотном проектировании баз удалять данные с технической точки зрения нет необходимости. Если нет других причин (типа хозяева не хотят держать большую базу на заправке), лучше с удалением не связываться.