vvskFirebird 2.1
После некорректного закрытия программы на клиенте, сервер получает ошибки, которые, впрочем, исправляются через BackUp/Restore или gfix -commit all , однако такая зависимость от клиента делает сервер неустойчивым. Особенно актуально в многопользовательском режиме, когда из-за кривых ручек пользователей, компьютеры то перегружаются на горячую, то свет прыгнет, то терпения не хватает и т.д.

Как снизить вероятность возникновение подобных ошибок? Может какой-то кэш уменьшить или отключить?

Перестать врать. Ошибки клиента не приводят к порче БД.

vvskpastorПерестать врать. Ошибки клиента не приводят к порче БД.

Ну вот попробуйте, например в цикле вставлять или менять записи на сетевом компе, и снять эту задачу в процессе.
И не возникнет ошибок БД?

Разумеется, нет.

vvskDarkMastervvsk,

Ну накопишь некоторое кол-ко мусорных версий... Ты кстати не рассказал, что подразумеваешь под "порчей БД".

Это значит, что беспричинно перестают выполняться корректные запросы в том числе и SELECT, или зависают транзакции.
Чаще всего просто перестают выполняться запросы. BackUp/Restore помагает, но это уже надоело, когда каждый день, приходится таким образом сжимать базу у 1-2 клиентов из ~ 300.

Бред какой-то. Каждый "сетевой" комп работает со своей локальной БД?

vvskZeroMQ,

Такая бурная фантазия у форумчан))


Приходится компенсировать недостаток информации.

vvskZeroMQ,
В процессе эксплуатации возможны обрывы соединения по локальной сети, зависание компов, зависание программы или прочие ситуации, при которых возможны дисконнекты в самом непредсказуемом месте.



На клиентских местах - фиолетово.
vvskZeroMQ,

Симптомы:
1. Перестают выполняться запросы к наиболее загруженным таблицам. Т.е. в момент их выполнения сервер возвращает ошибку, хотя при выполнении этого запроса к другой тестовой БД ошибок не происходит. При этом некоторые другие запросы к другим таблицам могут и не вызывать ошибок. При BackUp / Restore ошибка исчезает.



Если падает и сервер тоже, то таки да.

vvskZeroMQ,

2. Также попадаются случаи с зависшими транзакциями, "Stuck In Limbo". Т.е. часть запросов возвращают ошибку, но при этом выдаётся сообщение о причине ошибки. Её исправляю с помощью [src DELPHI]
gfix -commit all FB.FDB



Это двухфазные транзакции, обломавшиеся на одной из фаз. Бывают ТОЛЬКО В КОНФИГУРАЦИЯХ БОЛЕЕ ОДНОЙ БД.
Ну или в клинических случаях.

vvskZeroMQ,


Так вот вопрос заключается в том, каким образом можно максимально снизить риски таких вот заболеваний.

Один из полезных рецептов, подчерпнутых в комментариях выше:
Enable Forced Writes



Паллиатив. При отсутствии бесперебойника НА СЕРВЕРЕ гарантий не даст.

vvskZeroMQ,

Второй - это почистить мусор
Sweep Database



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

vvskZeroMQ,

Третий - обновиться до Firebird версии 2.1.7



Содержит довольно большое число исправлений, для весьма редких случаев.

vvskZeroMQ,

Очистка мусора, как я понял должна осуществляться периодически и при монопольном доступе к БД (вместо BackUp / Restore), установка Forced Writes производится единожды.

Пример глюка постараюсь в ближайшее время предоставить. Пока всё работает как на зло)

Очистка от мусора стартует сама, если настроена. Если счетчики зависают по причине частых и резких rollback/отвалов, то таки да, нужно иногда пнуть. Лучше шедулькой ночью.
Если есть долгоиграющие подключения, с транзакциями, незакоммиченными неделями - то хоть обзапускайся, мусор собрать не получится.