Re: [firebird-support] internal firebird consistency check

[LtColRDSChauhan rdsc1...@gmail.com [firebird-support]]

Thank you, Paul.
There were issues related to RAM and while attempting to upgrade RAM (and
OS from 32 to 64 Bit) I lost the corrupted database.
Regards,
Rajiv

On 13 Jun 2017 2:03 pm, "'Paul Beach' pabe...@waitrose.com
[firebird-support]"  wrote:




<<1. I got following error reported Firebird-3.0.2.32703_0_Win32 :
"internal firebird consistency check (cannot find record back version
(291), file: vio.cpp line: 4676)">>

Try a gbak using something like the following
gbak -b -v -i -g copy1.fdb{path}copy1a.fbk
using the –g switch to signify "no garbage collection"

If this succeeds then you can restore the database without the corrupt
record pointer.

Paul

Re: [firebird-support] internal firebird consistency check

[LtColRDSChauhan rdsc1...@gmail.com [firebird-support]]

Hi Alexey,
Thanks for your quick help. I think RAM is the issue.
Regards,
Rajiv

On 10 Jun 2017 1:44 pm, "Alexey Kovyazin a...@ib-aid.com [firebird-support]" <
firebird-support@yahoogroups.com> wrote:



Hi,



Usually such corruptions happen due to hardware problems.
Check you RAM

https://ib-aid.com/en/articles/how-to-check-ram-and-avoid-
database-corruptions/

Try to fix with standard means
https://ib-aid.com/en/articles/how-to-repair-a-corrupt-firebird-database/

If it fails, FirstAID will help.

It is not possible to 100% protect from all types of corruptions, but it
possible to eliminate their consequences - implement a failover solution
based on Firebird replication (VM failover does not work).

Regards,
Alexey Kovyazin
IBSurgeon
www.ib-aid.com



1. I got following error reported Firebird-3.0.2.32703_0_Win32 :
"internal firebird consistency check (cannot find record back version
(291), file: vio.cpp line: 4676)"

2. Environment:
.Net Provider 5.9.1.0
FlameRobin 0.9.3 (git hash 5ece15b)
Windows 10 Home Operating System

3. Back up reported the same error and failed. I'm not able to reproduce
the error from the copy of the corrupted database.

4. How can I avoid such corruption of database and how can I recover such
corrupted database.

Thanks and regards,
Rajiv

Re: [firebird-support] internal firebird consistency check

[Alexey Kovyazin a...@ib-aid.com [firebird-support]]

Hi,

Usually such corruptions happen due to hardware problems.
Check you RAM
https://ib-aid.com/en/articles/how-to-check-ram-and-avoid-database-corruptions/

Try to fix with standard means
https://ib-aid.com/en/articles/how-to-repair-a-corrupt-firebird-database/

If it fails, FirstAID will help.

It is not possible to 100% protect from all types of corruptions, but it 
possible to eliminate their consequences - implement a failover solution 
based on Firebird replication (VM failover does not work).


Regards,
Alexey Kovyazin
IBSurgeon
www.ib-aid.com



1. I got following error reported Firebird-3.0.2.32703_0_Win32 :
"internal firebird consistency check (cannot find record back version 
(291), file: vio.cpp line: 4676)"


2. Environment:
.Net Provider 5.9.1.0
FlameRobin 0.9.3 (git hash 5ece15b)
Windows 10 Home Operating System

3. Back up reported the same error and failed. I'm not able to 
reproduce the error from the copy of the corrupted database.


4. How can I avoid such corruption of database and how can I recover 
such corrupted database.


Thanks and regards,
Rajiv

Re: [firebird-support] internal Firebird consistency check (applied differences will not fit in record (177), file: sqz.cpp line: 127)

[Slavomir Skopalik skopa...@elektlabs.cz [firebird-support]]

Try 3.0.2, probably another situation related to

http://tracker.firebirdsql.org/browse/CORE-5392

Slavek

Ing. Slavomir Skopalik
Executive Head
Elekt Labs s.r.o.
Collection and evaluation of data from machines and laboratories
by means of system MASA (http://www.elektlabs.cz/m2demo)
-
Address:
Elekt Labs s.r.o.
Chaloupky 158
783 72 Velky Tynec
Czech Republic
---
Mobile: +420 724 207 851
icq:199 118 333
skype:skopaliks
e-mail:skopa...@elektlabs.cz
http://www.elektlabs.cz

On 20.2.2017 16:26, Roland Turcan k...@rotursoft.sk [firebird-support] 
wrote:
> Hello firebird-support@yahoogroups.com!
>
> I  am  migrating  data  and  changing  many  and  many  records in one
> transactions.  I  have  not  made anything strange just SQL editor and
> some SQL commands which forced this database corruption:
>
> DEVELOP Mon Feb 20 16:17:54 2017
>  Database: C:\EXEKUTOR\DATA\EXEKUTOR.FDB
>  internal Firebird consistency check (applied differences will not 
> fit in record (177), file: sqz.cpp line: 127)
>
> I  am  using  Firebird  3.0.1.32609  64bit on Windows 10 with SSD disk
> with new UPS.
>
> Could it be an bug in server?
>








++

Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu.  Try FAQ and other links from the left-side menu there.

Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ 

++


Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

<*> To change settings via email:
firebird-support-dig...@yahoogroups.com 
firebird-support-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
firebird-support-unsubscr...@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

Re: [firebird-support] internal Firebird consistency check (decompression overran buffer (179), file: sqz.cpp line: 239)

[Robert martin r...@chreos.com [firebird-support]]

Hi

I am no expert in these things but I thought that DB file access that 
was not 'through' the FB server while FB server is running could cause 
DB file corruption.  With our systems we always exclude the FDB from 
virus scanning and external backup applications. We have a FB backup 
(GBak) run and then have the external backup tool backup the .fbk file.  
Seems like your external backup could be causing this, which would 
explain the regularity of the issue.


Thanks
Rob



On 4/10/2016 11:00 PM, Alexey Kovyazin a...@ib-aid.com [firebird-support] 
wrote:


Hi Ian,

It seems that you have multi-volume database, is it correct?

Regards,
Alexey Kovyazin
IBSurgeon


Hi FB Support!


We have been running FB since IB4.2 days and have only previously had 
any database corruption when we've had hardware issues...until 
recently, when I've seen this error on 2 different servers that I'm 
reasonably confident are both fine! However, our setup is probably 
fairly unique. I'm not panicking at the moment as we recovered all 
the data from the backup, but as I've had this twice in a month on 
different machines I'm keen to adjust the setup so it doesn't happen 
again.



We are running about 20 customers on a server, each with their own 
set of Firebird/PHP-FPM/Nginx/custom python servers running as 
services bound to separate IP addresses – this is (in theory!) to 
keep each customer isolated from the others whilst sharing most of 
the resources on the box without too much overhead from containers or 
full visualisation.



FB is listening as a tcpsvd service but with a shared lock folder:


exec tcpsvd -c 60 -u firebird:firebird -l $remote_bind_addr 
$remote_bind_addr $remote_bind_port /usr/sbin/fb_inet_server -i -e 
"/srv/$CUSTOMER/interbase/" -el "/tmp/firebird/tmpfs"



and with a “localhost” for our own convenience:


exec tcpsvd -c 60 -u firebird:firebird -l 127.0.0.1 127.0.0.1 3050 
/usr/sbin/fb_inet_server -i -e "/var/interbase/" -el 
"/tmp/firebird/tmpfs"



I had assumed because they were using the share lock folder that this 
is allowed.



Each night we loop through all the customers and run :


for database in /customers/*.gdb

do

echo “Doing $database:”

echo -n “gbak ”

gbak -b -g localhost:$database /backupdata/$database.gbak

echo $?

echo -n “gfix ”

gfix -sweep localhost:$database

echo $?

echo -n “isql “

echo “EXECURE PROCEDURE nightlySQL;” | isql localhost$database

echo $?

done


Whilst this backup is running we don't disable any external access 
and have a mixture of python and php clients accessing throughout the 
night using the $remote_bind_addr:$database connection string rather 
than localhost:.



Over the weekend a 12GB backup finished successfully, but errors 
started appearing in the firebird2.5.log file at the same time as the 
next database was being backed up – suggesting that either the gfix 
or isql had tripped up before the script moved on. However, the 
output from the backup was:



Doing :

gbak 0

gfix 0

isql 0


The firebird log has the next customer's sweep starting immediately 
after the first “internal Firebird consistency check (decompression 
overran buffer (179), file: sqz.cpp line: 239)” on the now corrupt 
database which suggests the isql line is “to blame” - but the 
nightlySQL doesn't do a lot, just deletes from a table and 
re-populates a load of summaries from a big table. The firebird log 
error coincides with an NGINX request for the data that the 
nightlySQL is building, but I've repeated this today and it doesn't 
by itself kill the database. I've got nothing else in either syslog 
or dmesg.



I've run IBSurgeon against the file. It gives me the following output:


03/10/2016 11:23:53 INFO: Open database files: Z:\home\**-bad.gdb


03/10/2016 11:23:53 INFO: Analyzing database low-level structures...

03/10/2016 11:27:42 INFO: Actual PageCount: 1534112 found in database

03/10/2016 11:27:42 ERROR: Found 18 undefined or unrecognized pages.

03/10/2016 11:27:42 INFO: == DATABASE IS READY FOR DIAGNOSING AND 
REPAIRING. 


03/10/2016 11:27:42 INFO: == Now choose "Diagnose" or "Repair". 

03/10/2016 11:51:31 INFO: --- Starting diagnose

03/10/2016 11:51:31 INFO: Running procedure: Header page check

03/10/2016 11:51:31 INFO: ODS Major = 11 (32779)

03/10/2016 11:51:31 INFO: ODS Minor = 2

03/10/2016 11:51:31 INFO: Next transaction = 13910909

03/10/2016 11:51:31 INFO: Oldest transaction = 13910907

03/10/2016 11:51:31 INFO: Oldest active = 13910908

03/10/2016 11:51:31 INFO: Oldest snapshot = 13910908

03/10/2016 11:51:31 INFO: PageSize is Ok = 8192

03/10/2016 11:51:31 INFO: Running procedure: Checking of RDB$Pages 
consistency


03/10/2016 11:53:42 INFO: Checking of RDB$Pages consistency: Ok

03/10/2016 11:53:42 INFO: Running procedure: Low-level check of all 
relations


03/10/2016 11:53:43 INFO: Relation RDB$DATABASE (1) is OK

03/10/2016 11:53:44 INFO: Relation RDB$FIELDS (2) is OK

03/10/2016 11:53:46 INFO: Relation 

Re: [firebird-support] internal Firebird consistency check (decompression overran buffer (179), file: sqz.cpp line: 239)

[Alexey Kovyazin a...@ib-aid.com [firebird-support]]

Hi Ian,

It seems that you have multi-volume database, is it correct?

Regards,
Alexey Kovyazin
IBSurgeon


Hi FB Support!


We have been running FB since IB4.2 days and have only previously had 
any database corruption when we've had hardware issues...until 
recently, when I've seen this error on 2 different servers that I'm 
reasonably confident are both fine! However, our setup is probably 
fairly unique. I'm not panicking at the moment as we recovered all the 
data from the backup, but as I've had this twice in a month on 
different machines I'm keen to adjust the setup so it doesn't happen 
again.



We are running about 20 customers on a server, each with their own set 
of Firebird/PHP-FPM/Nginx/custom python servers running as services 
bound to separate IP addresses – this is (in theory!) to keep each 
customer isolated from the others whilst sharing most of the resources 
on the box without too much overhead from containers or full 
visualisation.



FB is listening as a tcpsvd service but with a shared lock folder:


exec tcpsvd -c 60 -u firebird:firebird -l $remote_bind_addr 
$remote_bind_addr $remote_bind_port /usr/sbin/fb_inet_server -i -e 
"/srv/$CUSTOMER/interbase/" -el "/tmp/firebird/tmpfs"



and with a “localhost” for our own convenience:


exec tcpsvd -c 60 -u firebird:firebird -l 127.0.0.1 127.0.0.1 3050 
/usr/sbin/fb_inet_server -i -e "/var/interbase/" -el "/tmp/firebird/tmpfs"



I had assumed because they were using the share lock folder that this 
is allowed.



Each night we loop through all the customers and run :


for database in /customers/*.gdb

do

echo “Doing $database:”

echo -n “gbak ”

gbak -b -g localhost:$database /backupdata/$database.gbak

echo $?

echo -n “gfix ”

gfix -sweep localhost:$database

echo $?

echo -n “isql “

echo “EXECURE PROCEDURE nightlySQL;” | isql localhost$database

echo $?

done


Whilst this backup is running we don't disable any external access and 
have a mixture of python and php clients accessing throughout the 
night using the $remote_bind_addr:$database connection string rather 
than localhost:.



Over the weekend a 12GB backup finished successfully, but errors 
started appearing in the firebird2.5.log file at the same time as the 
next database was being backed up – suggesting that either the gfix or 
isql had tripped up before the script moved on. However, the output 
from the backup was:



Doing :

gbak 0

gfix 0

isql 0


The firebird log has the next customer's sweep starting immediately 
after the first “internal Firebird consistency check (decompression 
overran buffer (179), file: sqz.cpp line: 239)” on the now corrupt 
database which suggests the isql line is “to blame” - but the 
nightlySQL doesn't do a lot, just deletes from a table and 
re-populates a load of summaries from a big table. The firebird log 
error coincides with an NGINX request for the data that the nightlySQL 
is building, but I've repeated this today and it doesn't by itself 
kill the database. I've got nothing else in either syslog or dmesg.



I've run IBSurgeon against the file. It gives me the following output:


03/10/2016 11:23:53 INFO: Open database files: Z:\home\**-bad.gdb


03/10/2016 11:23:53 INFO: Analyzing database low-level structures...

03/10/2016 11:27:42 INFO: Actual PageCount: 1534112 found in database

03/10/2016 11:27:42 ERROR: Found 18 undefined or unrecognized pages.

03/10/2016 11:27:42 INFO: == DATABASE IS READY FOR DIAGNOSING AND 
REPAIRING. 


03/10/2016 11:27:42 INFO: == Now choose "Diagnose" or "Repair". 

03/10/2016 11:51:31 INFO: --- Starting diagnose

03/10/2016 11:51:31 INFO: Running procedure: Header page check

03/10/2016 11:51:31 INFO: ODS Major = 11 (32779)

03/10/2016 11:51:31 INFO: ODS Minor = 2

03/10/2016 11:51:31 INFO: Next transaction = 13910909

03/10/2016 11:51:31 INFO: Oldest transaction = 13910907

03/10/2016 11:51:31 INFO: Oldest active = 13910908

03/10/2016 11:51:31 INFO: Oldest snapshot = 13910908

03/10/2016 11:51:31 INFO: PageSize is Ok = 8192

03/10/2016 11:51:31 INFO: Running procedure: Checking of RDB$Pages 
consistency


03/10/2016 11:53:42 INFO: Checking of RDB$Pages consistency: Ok

03/10/2016 11:53:42 INFO: Running procedure: Low-level check of all 
relations


03/10/2016 11:53:43 INFO: Relation RDB$DATABASE (1) is OK

03/10/2016 11:53:44 INFO: Relation RDB$FIELDS (2) is OK

03/10/2016 11:53:46 INFO: Relation RDB$INDEX_SEGMENTS (3) is OK

03/10/2016 11:53:47 INFO: Relation RDB$INDICES (4) is OK

03/10/2016 11:53:47 INFO: Relation RDB$RELATION_FIELDS (5) is OK

03/10/2016 11:53:48 INFO: Relation RDB$RELATIONS (6) is OK

03/10/2016 11:53:48 INFO: Relation RDB$VIEW_RELATIONS (7) is OK

03/10/2016 11:53:48 INFO: Relation RDB$FORMATS (8) is OK

03/10/2016 11:53:48 INFO: Relation RDB$SECURITY_CLASSES (9) is OK

03/10/2016 11:53:48 ERROR: DP#1533855 has wrong rel#:136

03/10/2016 11:53:48 ERROR: Found 1 record errors on datapage#1533855

03/10/2016 11:53:48 ERROR: Error on 

Re: [firebird-support] Internal Firebird consistency check (cannot find record back version (291) - how to fix and prevent?

[Alexey Kovyazin]

Hi,

The nature of errors is the following - one of record's backversions is 
missing, and Firebird cannot read chain of back versions to build actual 
(yours) version of this record.
The reason wrong transaction management, I think, is not correct, and 
we will change it - usually this happens due to hardware problem in RAM 
or disk.


I am trying to fix this error by using gfix: gfix.exe -v -f -user 
SYSDBA -password masterkey MYDB.FDB


try
gfix -mend ...
gbak -b -g -v -ig ...

And, IBSurgeon FirstAID should be able to export data from this database 
for sure.


Regards,
Alexey Kovyazin
www.IBSurgeon.com



Hello guys,

I have atleast one database on which this problem occurs when I try to 
backup the database. I do not know what caused this problem. Is it 
possible to cause this problem by executing DDL/DML statements?


On this page: http://ibsurgeon.com/articles/item69; the reason for 
this problem is explained as: Most probable reason is wrong 
transaction management. What is the wrong transaction management? How 
server could allow this problem to happen?


I am trying to fix this error by using gfix: gfix.exe -v -f -user 
SYSDBA -password masterkey MYDB.FDB


gfix is returning this:

Summary of validation errors

Number of record level errors   : 8


But it does not fix it, everytime I run this command I get the same 
response from gfix.


I've executed query SELECT COUNT(*) FROM MY_TABLE to scan all records 
in table and I've got the same message as in backup proccess. So I 
guess I could manually delete the rows from table? But why gfix does 
not fix it?


Thanks for your time.