I will ask them why in the first test they tested both with FW ON and OFF
and in the second test only with FW = OFF. Anyway, what do you think about
the failured in the first test when FW was ON ?

[]s

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

LS> Carlos,

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


LS> Sean

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

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

LS> []s

LS> Carlos
LS> WarmBoot Informatica - http://www.warmboot.com.br
LS> 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
LS> 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>>
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
LS> 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
LS> 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
LS> with
LS>> forced write ON, after killing the process and trying to connect to
LS> 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
LS> 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
LS> 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



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