Добрый день.
Друзья выручайте.

База данных 2Гб. 7-8 коннектов. страница 4096
Firebird 2.5 SuperClassic, force write = on
Операционная система Ubuntu 14
Сервер Firebird 2.5 SuperClassic для unix запускается на ubuntu 14
Клиентский софт для Windows запускается под wine, соответственно стоит клиент 2.5 windows, как на сервере так и на клиентских машинах.

Куда копать не знаю поэтому описываю что имею.

Проблема следующая:
Потеря документов за пол дня у одного коннекта, в это время другие коннекты данные не потеряли. Точнее сказать документы сохранились в БД у всех кроме одного коннекта.

Алгоритм работы программы следующий:
Начала работы:
1. При открытии программы запускается хранимая процедура которая считывает не завершённый документ этого рабочего места, если его нет, тогда создаёт документ без позиций.
2. Производим commit transaction.
3. Для отображения на экране открываем другую транзакцию и считываем данные по документу.
Добавление позиции:
1. Добавление позиции производится при помощи хранимой процедуры в таблицу БД.
2. Производим commit transaction.
3. Для отображения на экране открываем другую транзакцию и считываем данные по документу.
Уменьшение остатков в БД:
1. Запускаем хранимую процедуру проведения документа.
2. Производим commit transaction.
3. Создаём хранимой процедурой новый документ.
4. Производим commit transaction.
5. Для отображения на экране открываем другую транзакцию и считываем данные по документу.

Торговый документ обрабатываемый пользователем, на определённом рабочем месте, запоминается в БД и работать с другим торговым документом, с этого рабочего места, запрещено до полного проведения.

Описание последовательности действий пользователя при котором второй раз возникает такая ошибка:
1. Человек работал без закрытия клиентской программы 2-е суток.
2. Вечером пользователь не успевает провести торговый документ и оставляет его на следующий день. Компьютер и программа на ночь не выключается.
3. Утром, новый пользователь не закрывая программу проводит торговый документ (оставленный с предыдущего дня). После этого компьютер не перезагружается.
4. Долее создаются и проводятся, без ошибок в БД, новые торговые документы в количестве 15 штук.
5. Параллельно на других компьютерах: принимали товар, создавали торговые документы.
6. Когда решили добавить в торговый документ только что принятый товар, программа не обнаружила остаток в БД. Одновременно с этим на других компьютерах товар числился на запасах.
7. Пользователь корректно закрывает программу и перезагружает компьютер.
8. При запуске программы она считывает текущий торговый документ из БД как прописано в алгоритме "Начало работы".
9. Пользователь видит торговый документ который был утром.
10. Проверка списка торговых документов на этом компьютере показывает что все торговые документы отсутствуют т.е. как будто ни кто не работал пол дня на данном рабочем месте.
11. В тоже самое время список торговых документов за этот день на других компьютерах есть и верен.

После проверки в БД документы не обнаружили.

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

Заранее спасибо.

Dimitry SibiryakovBad_boY351Куда копать не знаю поэтому описываю что имею.
Лично я бы начал с того, что сменил пароль SYSDBA и владельца БД. Потом повесил на таблицу
пропадающих документов триггер в лучшем случае выбрасывающий исключение при попытке
удаления, а в худшем - протоколирующий этот факт где-нибудь.

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

Структура базы не простая удалить данные руками не так то просто следы останутся.
Логи операций пишутся в текстовый лог. И ошибок там нет. Тригер бесполезно делать, как так похоже что все что делается в этой транзакции не сохраняется, вопрос почему? не понятно. Так как ошибок транзакции не выдает.
По текстовому логу все чисто и без ошибок.

kdvBad_boY351,

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

Bad_boY3511. Человек работал без закрытия клиентской программы 2-е суток.
в программе в это время активных транзакций (не read read_committed) быть не должно. проверить можно в mon$transactions.

Ну и посмотрите вот это
http://www.ibase.ru/devinfo/optimize.htm
с "Транзакции" (посередине).

50 торговых точек. 2-а случая за 2-е недели на разных точка. Ставить везде FBScanner, покупать на все торговые точки накладно. А аудит-трейс под Linux я так понял не работает. FBScanner есть и бесплатный но не сохраняет работу в файл, а без этого проблема отследить, так как о факте узнаем через день в лучшем случае.

NikolayV81А не может быть ситуации что программа не отрабатывает ошибки коммита, и продолжает работать в той же транзакции? Или ещё какие ошибки скрываются, как то очень подозрительно выглядит...
С точки зрения программы, ошибки коммита всегда выводились, по крайней мере на windows, сейчас перешли на Linux софт работает по wine и параллельно перешли с firebird 2.1.3 на 2.5 SuperClassic (потому что тесты показали увеличение производительности).
Как я уже и писал текстовые логи пишутся ошибок коммита или других ошибок из транзакции не было.
В логах firebird бала только одна ошибка об обрыве соединения. Время обрыва совпадает с перезагрузкой компьютера перед тем как обнаружилась потеря данных.

m7mBad_boY351.... Тригер бесполезно делать, как так похоже что все что делается в этой транзакции не сохраняется....
В триггере пиши в external table
Не нашел описания, Разве external table не требуют commit?

dimitr,

Я с ним не работал по гуглил, не нашел примеров работы под Linux. Может не тот софт нашел, плиз на название программы правильно как пишется?
Да и у меня около 50 торговых точек, на каждой свая база данных, на какой выстрелит не знаю. Можно конечно поставить на все, но
аудитом-трейсом есть бесплатная версия и умеет ли она записывать монитор в файл? Так как онлайн отслеживать 50 баз не реально,
только просматривать логи постфактум.

wadmanBad_boY351пропущено...

Не нашел описания, Разве external table не требуют commit?
А искал?
Искал, и явного сказания, что коммит не требуется не видел. Да есть описание что типа можно в одном запросе создать таблицу записать данные и удалить таблицу. По идеи файл должен остаться, ну и конечно данные запишутся.
Так что да искал просто хотел узнать наверняка и не догадками.

hvladВот тебе пример, чисто гипотетический, т.е. без претензий на истину:
Bad_boY3512. Вечером пользователь не успевает провести торговый документ и оставляет его на следующий день. Компьютер и программа на ночь не выключается.Сетевой стек рвёт idle соединение, сервер откатывает тр-цию, программа понятия об этом не имеет
Bad_boY3513. Утром, новый пользователь не закрывая программу проводит торговый документ (оставленный с предыдущего дня). После этого компьютер не перезагружается.Программа получает и "глотает" ошибку потери связи и "прозрачно для пользователя" устанавливает новый коннект.
Ошибки потери связи программа не глотает и программа так построена, что на протяжении проведения документа данные сохраняются в базу коммит, после читаем стоимость всего документа и только после это проводим. Следовательно если бы бы RollBack стоимость бы не пересчиталась.
А обрыв связи не теряет состояние документа на данном рабочем месте все сохраняется. Максимум последнее действие, а не 30 последующих документов.

Больше похоже на то, что действительно ошибка коммита и прога ее не показала, причем софт не менялся а на винде все ошибки выводились, может глюк из за wine?

Ребят понимаю что инфы мало, но проблема есть, что написать о проблема кроме того что уже написано не знаю.

Может кто сталкивался с проблемами в связке сервер linux клиент windows под wine. Может здесь где проблема?
Я лично больше грешу на firebird client под wine.
Так же может быть из за перехода с classic server на SuperClassic.
Прошу мысли что может быть и варианты как решить?

roadsterBad_boY351может глюк из за wine?с логгированием?
это да, может и с ним.
никто вам никогда не гарантирует 100% совместимость и поддержку виндовых прог в вайне.
ЗЫ перевод клиентов с винды на линукс - дело сомнительное, ИМХО.
Согласен полностью, но задача стояла за месяц, приложение которое писали несколько лет перевести на linux.
Причем используется драйвер ККМ АТОЛ а он только под wine работает. АТОЛ в принципе с linux не работают.

roadster,
вот и разгребаю.

m7mBad_boY351Может кто сталкивался с проблемами в связке сервер linux клиент windows под wine. Может здесь где проблема?
Я лично больше грешу на firebird client под wine.
Таких проблем не замечал.
зы. уточняю
В такой связке ведется разработка
и в такой связке работают некоторые наши заказчики
ззы. Это конечно не означает что их не может быть
можно информацию по версиям Linux, wine на чем работаете, для сравнения чтобы минимизировать вероятность именно в этой связке.

m7mBad_boY351Может кто сталкивался с проблемами в связке сервер linux клиент windows под wine. Может здесь где проблема?
Я лично больше грешу на firebird client под wine.
Таких проблем не замечал.
зы. уточняю
В такой связке ведется разработка
и в такой связке работают некоторые наши заказчики
ззы. Это конечно не означает что их не может быть
Читаем алгоритм описанный в первом сообщении. Больше про комита писать не буду.

Все спасибо за советы.
external table для логов прикручу конечно.
Коммиты перепроверил на 10 раз уже.
Буду искать решение.
Как найду причину и решение напишу может пригодится кому то.

Жесть конечно, но я разобрался в чем проблема была.
Держитесь чтобы со стула не упасть.
Раз в ночь на торговой точке производится операция бакуп/ресторе со следующим алгоритмом (о необходимости каждую ночь делать бакуп/рестре все понятно сделано админом, с его слов работает быстрее):
1. сперва база переименовывается для того чтобы проверить а есть ли к ней коннекты.
2. Создается бакуп.
3. База данных переносится в другую папку.
4. Делается ресторе на измененное имя.
5. Переименовываем базу после ресторе на нормальное имя.

В windosw все так и работало, но в Ubuntu все не так.

1. при активном коннекте переименовать базу можно.
2. при активном коннекте переместить базу можно.
3. и самое интересное, что после всех этих действиях коннект к базе данных сохраняется (к перемещенной в другую директорию).

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

Вот так умеет firebird 2.5 под ubuntu 14.

roadsterBad_boY3511. сперва база переименовывается для того чтобы проверить а есть ли к ней коннекты.базу в даун надо отправлять
проверять наличие коннектов иным способом, через mon$ например (так корректнее)
Знаю даже написано приложение отдельное серверная часть которая выполняет все эти операции, но перевести еще не успел. Так как админ пока linux - ом занят.

Dimitry SibiryakovBad_boY351Вот так умеет firebird 2.5 под ubuntu 14.
"О, сколько нам открытий чудных готовит просвещенья дух..." (с)

1. Это поведение ФС в юнихах всем известно.
2. "ДБА", делающего бэкап-рестор ежедневно "для ускорения" надо гнать поганой метлой.

Ну а почему не посоветовали проверить то это?

Dimitry SibiryakovBad_boY351Ну а почему не посоветовали проверить то это?
Потому что приняли тебя за вменяемого человека и поверили на слово вот этому:
Bad_boY351Левых баз данных нет. (если кто то предположит что подключились к
копии)

Мой косяк, согласен.
Но при этом "если кто то предположит что подключились к копии" к копии то не подключались, подключались к оригиналу. Просто коннект "уезжал" вместе когда оригинал становился копией.

roadsterhvladпропущено...
БЕКАП, млин !понял, исправлюсь.
ЗЫ а как правильно рестор или ресторе?
Ребят у Вас что работы нету?