Alexander V.Nevsky wrote:

> --- In firebird-support@yahoogroups.com, Bradley Tate <btate@o...>
> wrote:
> > Hi all,
> >
> > For the second time the backup of our 3G Firebird 1.0.3 database has
> > been corrupted. We do a backup and restore nightly for QA and for
> use
> > in other systems. All tables in the restored database then appear
> empty
> > i.e. result sets from selects are empty and the roles have
> disappeared.
> > We suspected a permission problem but even when we add permissions
> back
> > using grant all we still cannot get access to any data from any
> table
> > even logging in as sysdba. There are no errors reported from the
> backup
> > or restore process, and gfix reports nothing wrong with either the
> > restored database or the original.
>
> Looks strange. I haven'nt failed restore since FB1 RC2 so can't
> assure you that FB1.0.3 g-utilities always return error message, but
> it's really doubtful.
>
> > To try and track down the problem we did the restore in Firebird 1.5
> RC8
> > and it tells us that one of our tables has a duplicate on the
> primary
> > key. The problem is if we go back to our original database and do a
> > select it performs as expected and there is no evidence of this.
>
> What kind of select did you do? Something like
>
> Select Count(*), ID
> >From This_Table
> Group By ID
> Having Count(*)>1 ?
>
> Don't forget to add Plan (This_Table Natural) to such a query. Most
> probably engine used index and this index have no link to duplicated
> row. Check this table for NULLs in PK too, again forcing natural scan.

Any and all queries work on the "original" database. There is no
indication of any problem.
It is only on the restored gdb that any select returns nulls, regardless
of table (of which there are about 200)
Am I misunderstanding?

>
> > Given
> > that we know what the problem is we can fix it (copy table, drop
> > original, copy back) but does anybody have any idea what could be
> > causing it so we can stop it happening again? We're suspicious that
> the
> > backup is getting too much data i.e. records which should not exist
> any
> > more.
> > The original database is running on Linux (RedHat 7.3)
>
> Don't think so. 3Gb is'nt very large database, my own is about 8 and
> run on Red Hat too, survived many versions of both RH and FB. In my
> practice such a corruptions were sometimes caused by killing processes
> of Classic server. I think crash of Super can make the same damage.
> Another reason I know is file access to database in use, third -
> hidden hardware defects, usually RAM or disk controller. BTW, in FB1.5
> were fixed several ancient bugs around savepoints and mass
> inserts/updates which seldom could lead to such a corruptions.
>
> Best regards,
> Alexander.
>

Hmmm. No crashes lately. RAM is ECC. We run SS version and never kill
processes.
Disk controller is new but I can't discount hardware problems entirely.

>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
> * To visit your group on the web, go to:
> http://groups.yahoo.com/group/firebird-support/
>
> * To unsubscribe from this group, send an email to:
> firebird-support-unsubscribe@yahoogroups.com
> <mailto:firebird-support-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <http://docs.yahoo.com/info/terms/>.
>
>