iBase.ru Forum

В общем обстановка:
4 ядра (2х2) Xeon, 2 Gb RAM, 4х36 Gb SCSI 320 RAID (stripe - о ужас!!! Почему не спрашивайте - сам бы так однозначно не сделал.... ).
Операционная - 2003 сервер (не R2). На машине крутится еще 1с с ее SQL базой, терминал сервер и принт сервер. Антивируса нет (еще один ужас:))
Firebird 1.5.3.4870 Superserver, использует одно ядро, все остальное под любимую 1с.
Сервер работает круглосуточно, но у него как положено дохлый ЮПС , а на выходные там часто вырубают электричество.
База:
В общем скромная, размер 600 Мб. Количество транзакций - около 7000 в день. Дневной разрыв между oldest и всеми остальными небольшой. Сборка мусора отключена (сделана попытка обойти барабашку), ночью делается принудительный свип. Бекап/рестор делается раз в две недели. Размера страницы 4096 байт. Ошибок нет (наверное ) - gfix ничего не показывет.
Проблема (барабашка):
1. Есть таблица которая часто апдейтится (например текущие остатки по товару, по экспедитору). Периодически возникает проблема, мною лично наблюдаемая - с одного компьютера видны одни остатки, с другого - другие. У одного и того же экспедитора. Запрос делался через IBExpert на клиентских машинах (select * from current_stocks where van_code = 123456). На обоих разный набор данных. Если на сервере перезапустить Firebird, то они начинаю видеть третий набор данных отличный от предыдущих двух - проверено экспортом конечных данных в Excell. Разумеется говорить о коррекной работе программы в данном случае не приходится - данные потеряны. Причем которые из трех наборов данных правильный тоже непонятно.
2. Есть таблица с ценами по категориям. Пишется через связку грид-датасет в единственном месте - в справочнике. Писано на IBExpress. Периодически цены меняются оператором, но с таким же упорством они возвращаются на место (не оператором конечно, проверено по логам) , изменяются только те цены которые меняли и ровно на старое значение, причем происходит это раз в 3-4 дня. После редактирования таблицы в программе делается Commit (транзакция закрывается). Вопрос - как такое может произойти?

1) Битый первичный ключ?
2) Не бывает!
Проверь тем же экспертом или isql-ем
Если всё чисто - значит прога лажает.
Можно попробовать запретить изменения отключаемыми генератором триггерами.
Тогда в месте изменения явно отрубаешь запрет, делаешь комит, врубаешь запрет.
На несанкционированные изменения получишь исключение.

1. База чистая (по gfix)- если ключ битый, то как проверить? Таблица кстати периодически полностью вычищается. Однако на конечный результат это не влияет - разнонабор все равно вылазит. Но редко.
2. Бывает, бывает , я этот цирк уже вторую неделю наблюдаю. Причем случай уникальный - программа работает и в других местах, но чтоб такого.... потому и барабашка! Я так думаю что проблема все таки не в самом FB, просто думал может у кого такая же пробегала. Насчет триггера уже пробовал - не матюгает! Потому что программу писал сам и знаю откуда ноги растут. Вот и думаю. . А еще вспомнил - на той
неделе ставил свип интервал в 0 - а через пару дней он вернулся в прежнее значение. Кроме меня такое никто не мог сделать.

Расширение у файла базы данных не gdb часом?
Может винда его тебе восстанавливает?

Расширение то GDВ и про эту хохму виндовую я знаю. Однако у клиента на сервере в Свойствах Мой Кампутер вкладки System Restore вообще нет! Или ее отсутствие еще не означачает что восстановление не рабоатет? Сейчас поменяю расширение - если поможет - будете в Алмате - напою пивасиком по самое нехочу!