Subject RE: Re[2]: [ib-support] Crash recovery test ! Keep reading...
Author Leyne, Sean
Carlos,

I would strongly urge you to post a message to the editor pointing out
that the test was not a true representation of Interbase/Firebird
database integrity or recovery abilities.


Sean

-----Original Message-----
From: Carlos H. Cantu [mailto:warmbooter@...]
Sent: Friday, January 26, 2001 11:06 AM
To: Leyne, Sean
Subject: Re[2]: [ib-support] Crash recovery test ! Keep
reading...

Yes, I forgot to mention that FW was off in the 2nd test.

[]s

Carlos
WarmBoot Informatica - http://www.warmboot.com.br
Interbase-BR - http://www.interbase-br.com

LS> Carlos,

LS> In the second test, did they indicate that Forced Writes was ON?

LS> If not, than the fact that the database was "scrambled" would be an
LS> expected outcome.

LS> Database data integrity is only assured if Forced Writes = On.


LS> Sean

LS> -----Original Message-----
LS> From: Carlos H. Cantu [mailto:warmbooter@...]
LS> Sent: Friday, January 26, 2001 10:53 AM
LS> To: interbase@...
LS> Cc: ib-support@yahoogroups.com
LS> Subject: [ib-support] Crash recovery test ! Keep reading...

LS> Hello !

LS> I just found an article published in a Linux magazine in Brazil
about
LS> some
LS> tests with IB running on Linux related to IB crash recovery system.

LS> The article (in portuguese) can be found at
LS>
http://www.revistadolinux.com.br/artigos/database/20010117084829.php3

LS> Here is a resume of what they did. I would like to hear some
comments
LS> about
LS> their conclusions :

LS> They did basicly 2 kinds of crash tests :

LS> 1) Killing the main process (and its subprocess) using the linux
KILL
LS> command during some operations (insert,update,etc.)

LS> 2) RESETing the hardware during some operations (insert,update,etc.)

LS> In the first case, IB recovery system was 100% in almost all cases .
LS> Only
LS> in 1 situation an error was found : While updating 300,000 records
with
LS> forced write ON, after killing the process and trying to connect to
the
LS> database again, the connection was accepted and NO error message was
LS> reported, but when the user tried to access the table that was being
LS> updated the system freezed.

LS> In the second case, IB returned errors when trying to connect to the
LS> database :

LS> üdatabase file appear corrupt ( )
LS> wrong page type
LS> page "xxxxx" is of wrong type (expected 7, found 5)

LS> In some of them, the database could be connected but the table was
LS> inaccessible :

LS> Internal GDS software consistency check (cannot find record back
version
LS> (291)) (3 ocorrências)
LS> §Internal GDS software consistency check (wrong record length (183))
LS> §Internal GDS software consistency check (applied diferences will
not
LS> fit in record (177))
LS> §database file appear corrupt ( )
LS> wrong page type
LS> page "xxxxx" is of wrong type (expected 5, found 4)



LS> []s

LS> Carlos
LS> WarmBoot Informatica - http://www.warmboot.com.br
LS> Interbase-BR - http://www.interbase-br.com



LS> To unsubscribe from this group, send an email to:
LS> ib-support-unsubscribe@egroups.com



LS> To unsubscribe from this group, send an email to:
LS> ib-support-unsubscribe@egroups.com



To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com