Internal gds software conisitency check (...)

Е това нещо ми изяде главата....
Значи имам си база на Interbase приложението е за маркиране на касов компютър вързан с баркод четец, фискален принтер и клиентски дисплей...
значи през 2-3 дни ми избива тази грешка, и спира работата на програмата.
Най странното е че като се архивира базата и деархивира , проблема се оправя, но пак работи 2-3 дни.
Хванахме и пренабихме 7 дни, но тази грешка не се появи..
Доколкото информацията в нета показва че има сериозен проблем в базата и е трудно да се намери къде е, някои ако има идея как да го преборя, ще черпя много....

Възможно е при много операции update, insert, delete в една тразакция
Вж. [линк]

хм
при архивиране се освобождават ресурси....да не би да са кът?
от друга страна - да не си достигнал някой лимит - брой операции в една транзакция, памет, TEMP база данни (не знам как е в интербейса?) нещо такова...
от трета - да нямаш хардуерен проблем - лоши сектори (или нещо друго) по диска? много рядко ама се случва...ако е друго - памет, видео или нещо подобно ще се дъни постоянно и няма да има връзка с архивирането...ако щеш вярвай, но сме сменили ПЕТ диска....докато си закрепим сървъра да бачка...

ами оглеждах транзакциите, но няма такова наслагване, сега ражгледам по обстойно, и ми прави впечатление, че нещо прави sweep интервала...
в лог файла грешка от типа Cannot start Sweep... и я повтаря по 20 пъти на секунда..
а там е натоварено, и сега ще го търся, дали не се получава някакво такова преплитане...
другата грешка е че, май доста информация се пише и базата доста набъбва, но категорично в транзакцията няма толкова писане изтриване и ъпдейтване....

много странно набъбва големината... сега разглеждам подробно сорса, но немога да рабера защо го помпа така...
примерно от база 30МБ, след архив деархив, става на 9МБ....
или версията на сървъра е бъглива, или нещо в структурата не е наред...

transaction log говори ли ти нещо ?

За такова "набъбване" пробвай да си поиграеш с Page size
Аз винаги установявам Page size=8192
При проблеми със захранването също са възможни проблеми
Ако няма UPS донякъде помага forced writes=enabled, но това забавя.

е до са се дзверих в лог-а....
ама нейсе.. нищо интересно не открих...
май ще взема една празна БД, ще преналея всичко в нея, и тогава ще пробвам пак да видя дали ще изникне проблем...

е при архивиране транзакшън лога се орязва доколкото е възможно
ако имаш много, но ситни транзкции....тогава ефекта е поразяващ...))

Предполагам, че едва ли сте пипали конфигурацията - т.е. sweep се прави by default на 20000 транзакции - предполагам, че при интензивен обмен това става на 2-3 дни ;-))) - то4но за това ти и расте файла - само, че при sweep на базата той не се намалява - просто пространството се маркира за reuse. Явно има проблем със сървъра - ето и няколко идеи :

1. Коя версия на Interbase използваш - съвет - нищо под 6.5 или последните на firebird - предните (между 5.x май и 6.5 ) версии създаваха доста проблеми - смени сървъра с firebird за проба ?!
2. Погледни какво се появява в лога на interbase !!!! - преди и след грешката.
2. С какво е разработена програмата- т.е. ако си с борландски продукт - кои компоненти използваш - за някои(като IBX ) има доста updates вече - поддържай си версиите максимално опреснени.

Ако дадеш повече информация - IB версия, среда, библиотеки - може да се опитам да помогна повече - в момента се ровя в неща за IB - но ползвам последната версия( е не 7 все още ;-)))) .

Мерси за съветите :))
Аз още се ровя и издирвам от къде може да се получи, имам съмнения че записвам много ненужна информация в базата, но сега го преработвам това.

Прави ми впечатление че Log файла на InterBase 6.0 (open source) е пълен със следните грешки :
INET/inet_error: read errno = 10054
internal gds software consistency check (Too many savepoints (287))
INET/inet_error: select in packet_receive errno = 10038
и ги реди тези грешки докато не гръмне накрая и спира да работи.

Сървъра е под XP Home Edition, работната станция е на win98, вързани са директно с UTP кабел,
софтуера съм го писал на Delphi 6 с IBX компоненти.
За ъпдейти немога да си спомня дали съм качвал, че скоро си преинсталирах всичко, но ще ги накача...

Интересното ми е, че в петък, казах на персонала, през 2-3 часа да затварят програмата и да я пускат пак, и в момента вс еоще всичко си работи и е наред... а забравих да кажа че там е денонощно и се работи на тежък режим... просто е много натоварено...

Направи архив на библиотеката на IB- то - и инсталирай FireBird <> IB6 opensource - голяма разлика !!!! Май това ти е проблема. Друго което мога да ти кажа - е да инсталираш SP1,2 + updates за IBX - от codecentral - има вси4ко - доста промени ;-)))

Но първо пробвай дали gdb файла ще се отвори под firebird - има някои разлики във формата на файла - може да си попадна то4но на "куция" формат - но за това трябва да ми кажеш версията на gds32.dll.

---
Е т'ва е живот!

на тежък режим, толкоз ли няма париз за нещо, което не прави въртели...
сървър на ХР хоум едишън и база данни опен сорс не ми звучи много сериозно...

хех... Верно не е много сериозно...
ама нема паре.....
вместваме се в рамките колко дават и се чудиме какво да смукаме от пръстите и как да го нагласиме... нещо като - ем вълка сит, ем агнето цало... нали се сещаш!

избрали сте най невъзможното от най невероятното.....

има добри решения на баз на безплатен софтуер - Linux + Appache + MySql например....ако ти трябват тригери, ще се намери и база данни с тригери....

ако не ти пука от проверки и не светиш като крушка в интернет - лиценза за микрософтските сървъри е сто пъти по малко от проблемите, дето може да си навлечеш с някоя изпращяна база данни, дето може да ти затрие всичките данни, или още по лошо....да ги омеша хубавичко.....

поне за търговия ли става дума или за някакъв процес?
за мен лично доверието е нещо доста ценно, за това бих работил с продукти, на които имам доверие...

Не виж сега...
значи от доста години работа под тази форма - Вин+Интербасе
(нямам гадна латиница в тези клубове)
ресторанти и заведения работят с модул за реално маркиране и никога не е имало проблем.. или ако има проблем, то истачката или дж-я са изклюили хуба, или някой прекъснал кабела...
просто в момента гадоста е , че е информацията която се обработва е митническа, и трябва да има постоянно справка за пред митниците....
но сега съм се заел да минимизирам базата данни, за да има колкото се може по малко информация която да се пише и ъпдейтва...
ама ще видиме какво ще стане накрая....

е, вече знаеш какво мисля.....

От [линк]
E: INET/inet_error: send errno = 10054
D: Обрыв клиентского соединения. WNET - по NetBEUI, INET - по TCP/IP.
S: Для начала надо сделать upgrade на максимально последнюю версию IB (например для 5.x это 5.6, для 6.x это 6.0.1.6 или 6.5, для Firebird - релиз v1 и так далее). Затем убедиться, что на сервере, если это NT (или W2K), стоит самый последний Service Pack. Если клиенты - NT (или W2K) Workstation, то на них поставить тот же сервиспак, что и на сервере. Если клиенты - Windows 95/98, то скачать с [линк] самые последние обновления для netbeui и tcp/ip.

Вообще при работе по tcp/ip таких ошибок должно быть существенно меньше, чем по netbeui.
Если ошибки 109 или 10054 продолжают появляться, то нужно искать дефектное сетевое оборудование - хаб, свитчер, или сетевую карту. Теоретически в этом может помочь использование какого-либо SNIFFER, но методика пока неизвестна. Также см. утилиту ibconsvc.zip, которая заносит информацию о коннектах и дисконнектах (только tcp) прямо в interbase.log, что позволяет отследить станции или хабы, генерирующие ошибку 10054.

Почти то же самое написано в документе: [линк]

Еще один вариант, который иногда помогает устранить обрывы коннектов - изменение параметров CONNECTION_TIMEOUT и DUMMY_PACKET_INTERVAL в IBCONFIG (или isc_config на UNIX) на значения, отличные от умолчательных, например 170 и 50 соответственно. В некоторых случаях на UNIX помогает установка connection_timeout в 0.

E: INET/inet_error: accept errno = 10093
E: INET/inet_error: read errno = 10038
D: ошибка при попытке инициализации подсистемы tcp/ip (NetBEUI), вызвана частыми появлениями ошибок 10054 (109). Как правило после этой ошибки сервер аварийно завершает работу. Для перезапуска сервера возможно требуется рестарт NT.
S: решение такое же, как и для ошибок 10054 или 109 (см. выше).


E: internal gds software consistency check (Too many savepoints (287))
D: Возникает при большом количестве insert/update/delete (явном или косвенном, через триггеры) в одной длительной транзакции. Возможно влияние количества вызываемых триггеров и процедур в этой транзакции.
S: отсутствует.


Вж. съвета на PhantomAS (стар ерген®) 13.01.03 17:59 за Firebird
Ще добавя само да не се опитваш да използваш директно gdb-то, а първо в IB да направиш Backup и след това в FireBird да Restor-неш

За Topбaлaн:
Въпреки разпространеното тук мнение, IMHO e че за корпоративни цели IB/Firebird е за предпочитане пред MySQL. Върви еднакво добре под Win и Linux.

Пропуснах да добавя
От [линк]

1.59 Как часто нужно делать Database Sweep ?

БД имеет по умолчанию параметр начала Sweep в 20000 транзакций. Это может показаться большим, но для реальных приложений 20000 транзакций - именно то число, когда в БД скапливается достаточно "мусора".

Количество "мусора" в БД определяется тем, насколько часто происходят вставки, изменения и удаления. Версии записей удаляются только тогда, когда они не нужны старейшей активной транзакции (OAT).

Вообще "sweep interval" - это разница между OAT и OIT (старейшей активной и старейшей заинтересованной транзакцией), при котором необходимо делать sweep. Если номер OIT увеличивается также, как и OAT, автоматический sweep может и не наступить. Одной из наиболее вероятных причин увеличения номера OIT является завершение транзакции операцией ROLLBACK.

При выполнении Sweep освободившиеся страницы не возвращаются операционной системе - они будут использоваться IB как свободные страницы.

Если вы хотите самостоятельно и регулярно делать Sweep, то можно это делать, например в ночное время когда нет работающих пользователей, при помощи утилиты GFIX. Кроме того, выключить автоматический sweep можно установив "sweep interval" = 0.

примечание: следить за OAT-OIT можно периодически получая статистику по конкретной БД при помощи Server Manager (или утилиты GSTAT).

примечание: например если вы вставите в таблицу 1000000 (миллион) записей, завершая вставку каждой операцией commit, то автоматический sweep запущен не будет (OAT-OIT постоянно и очень мало). Однако так поступать тоже не стоит, т.к. вставка будет происходить очень медленно - лучше всего в одной транзакции вставлять 100-200 записей.

примечание: в IB 5.5 есть баг, который приводит к падению сервера при SWEEP, если в базе данных есть индексы по полям, возможно содержащим значения NULL. В этом случае необходимо отключить автоматический SWEEP (установить в 0), а операцию backup производить с установленным флагом Disable garbage collection. Данный баг исправлен в IB 5.6.

тъкмо щях да пусна обеснението за гршката - че предния път забравих...

---
Е т'ва е живот!

Мерси за помоща :))
ще се реванширам някой път, но май проблема е в софтуера, или в запаметените процедури, ще пренапиша едната част и ще махна процедурите.
Значи грешките дето се появяват са следствие от други неща, който в момента се опитвам да разбера защо стават.
Примерно, като се напррави една продажба, незнайно защо, файла набъбва с 80К, при 5-6 продажби, набъбва 2 МБ.... за мен това е ненормално...
а в сорса, и като трасирам и като включа Монитора на транзакциите, там всичко е нормално няма толко много записи и ъпдейти... от къде нараства, сега се тормозя...

пс. Качих ъпдейти на Делфи и Компонентите, подмених Интербейса с Файрбърд... и дерзая ...