Subject Re: RE: [firebird-support] Re: Database Corrupt ?
Author liviuslivius
as was mentioned earlier - successful backup restore did not mean that source database was without errors.
To test source database run:
gfix -validate -full ....
PS. will be good to see that you have most recent version of firebird from some part (2.1.X, 2.5.X, 3)
Karol Bieniaszewski
W dniu 2016-04-22 09:19:38 użytkownik 'Christine S' christine.sanjaya@... [firebird-support] <> napisał:

Dear Intelrullz,

Thanks for your respond.

Yes, I have ever backup, restore and validate it, and its ok, no errors found. Still don’t have clue why it could be happen.. and how to avoid it..


Christine Sanjaya - MIS

From: []
Sent: Thursday, April 21, 2016 9:23 AM
Subject: RE: [firebird-support] Re: Database Corrupt ?

Hi Christine,

Successful restore does *not* mean your original database is ok. It just means the backup contains consistent data, which (I believe) means it did not touch any corrupt pages. I assume it could be 'truncated just the right way' and remain valid, but I'd love to see it actually happen. Generally, corruption may go unnoticed for months, depending on the workload/data/moon-phase/so-on

If you have the option of downtime - I'd suggest a full validation on the files. File copy is possible with some NBackup magic, but it seems risky on a DB with an unknown state.

A few hours of RAM testing won't hurt too.

As for the CPU - nothing weird about that. A lot of machines have cpu power management on powersave by default, which keeps the freq lower (that 4GHz cpu is a descent room heater at full speed). You'll probably want to change that on a DB server, though :)

[Non-text portions of this message have been removed]