Database warnings/errors

[Tomasz Dubiel]

Hello.

What can be the reason for those messages? Firebird 3.0.10 or newer 3.0.

Plenty of such ones:

Warning: Page 1088717 has SCN 3 while at SCN's page it is 6

Warning: Relation has 8 orphan backversions {0 in use} in table RDB$RELATIONS (6)

Warning: Pointer page 56 {sequence 0} bits {0x09 full, secondary} are not consistent with data page 609 {sequence 9} state {0x08 secondary} in table RDB$PROCEDURES (26)

Warning: Index 7 has inconsistent left sibling pointer, page 621758 level 1 at offset 280 in table NAGLPK (238)
Warning: Index 8 misses node on page 621785 level 1 at offset 273 in table NAGLPK (238)

Warning: Pointer page 56 {sequence 0} bits {0x09 full, secondary} are not consistent with data page 609 {sequence 9} state {0x08 secondary} in table RDB$PROCEDURES (26)

Warning: Relation has 197 orphan backversions {0 in use} in table RDB$INDEX_SEGMENTS (3)
Warning: Pointer page 12 {sequence 0} bits {0x09 full, secondary} are not consistent with data page 461765 {sequence 45} state {0x08 secondary} in table RDB$INDICES (4)
Warning: Relation has 1829 orphan backversions {0 in use} in table RDB$INDICES (4)
Warning: Relation has 2 orphan backversions {0 in use} in table RDB$RELATION_FIELDS (5)

Messages about normal tables is one thing, but messages about RDB$ tables look suspicious. When do such messages appear? We start to see such messages when we validate databases.

Best regards,

Tomek.

[Dimitry Sibiryakov]

Tomasz Dubiel wrote 12.02.2026 10:11:
> When do such messages appear? We start to see such messages when we validate
> databases.

These messages are result of the validation.
It looks like your database is messed at physical level by non-synchronised
writes.
Have you considered switch to superserver with exclusive database file
access? With Firebird 3+ the classic mode has less sense because of
multithreading support.

--
WBR, SD.

[Tomasz Dubiel]

When we moved to Firebird 3.0, we primarily use Superserver. Those are examples of Superserver.

[Dimitry Sibiryakov]

Tomasz Dubiel wrote 12.02.2026 10:26:
> When we moved to Firebird 3.0, we primarily use Superserver. Those are examples
> of Superserver.

Is it result of online or offline validation?

--
WBR, SD.

[Tomasz Dubiel]

Offline. with exclusive access.

[Tomasz Dubiel]

And one more thing - sometimes in those messages we see:

Warning: Pointer page 1034 {sequence 0} bits {0x09 full, secondary} are not consistent with data page 22944 {sequence 64} state {0x08 secondary} in table NAGL (235)

Warning: Pointer page 1034 {sequence 0} bits {0x01 full} are not consistent with data page 23877 {sequence 77} state {0x00 } in table NAGL (235)

What is the difference between "full" and "full, secondary"?

Best regards.

[Dimitry Sibiryakov]

Tomasz Dubiel wrote 12.02.2026 11:11:
> What is the difference between "full" and "full, secondary"?

Bit "full" means that the data page is full and no new records can be put
into it.
Bit "secondary" means that this page is intended for tails of long fragmented
records that don't fit into primary page.

--
WBR, SD.

[Vlad Khorsun]

What can be the reason for those messages? Firebird 3.0.10 or newer 3.0.

  Usually, such minor inconsistences happens when database file was not closed properly and page cache was not flushed. 

Could happen when server process crashed or killed. Can't say more without a way to reproduce it. 

Plenty of such ones:

Warning: Page 1088717 has SCN 3 while at SCN's page it is 6

Warning: Relation has 8 orphan backversions {0 in use} in table RDB$RELATIONS (6)

Warning: Pointer page 56 {sequence 0} bits {0x09 full, secondary} are not consistent with data page 609 {sequence 9} state {0x08 secondary} in table RDB$PROCEDURES (26)

Warning: Index 7 has inconsistent left sibling pointer, page 621758 level 1 at offset 280 in table NAGLPK (238)
Warning: Index 8 misses node on page 621785 level 1 at offset 273 in table NAGLPK (238)

Warning: Pointer page 56 {sequence 0} bits {0x09 full, secondary} are not consistent with data page 609 {sequence 9} state {0x08 secondary} in table RDB$PROCEDURES (26)

Warning: Relation has 197 orphan backversions {0 in use} in table RDB$INDEX_SEGMENTS (3)
Warning: Pointer page 12 {sequence 0} bits {0x09 full, secondary} are not consistent with data page 461765 {sequence 45} state {0x08 secondary} in table RDB$INDICES (4)
Warning: Relation has 1829 orphan backversions {0 in use} in table RDB$INDICES (4)
Warning: Relation has 2 orphan backversions {0 in use} in table RDB$RELATION_FIELDS (5)

  All of this warnings are harmless for database consistency.

 

Messages about normal tables is one thing, but messages about RDB$ tables look suspicious. When do such messages appear? We start to see such messages when we validate databases.

  A lot of backversions in system relations means many DDL operations and blocked garbage collection.

Regards,

Vlad

[Vlad Khorsun]

And one more thing - sometimes in those messages we see:

Warning: Pointer page 1034 {sequence 0} bits {0x09 full, secondary} are not consistent with data page 22944 {sequence 64} state {0x08 secondary} in table NAGL (235)

Warning: Pointer page 1034 {sequence 0} bits {0x01 full} are not consistent with data page 23877 {sequence 77} state {0x00 } in table NAGL (235)

What is the difference between "full" and "full, secondary"?

  "full" bit show that data page have no more space for new records. It allows to skip data page when looking for space for new record.

  "secondary" bit show that data page can't contain primary record versions. It allows to skip data page by natural scan.

  These (and other) bits put on pointer pages for every data page and should be consistent with actual state of data page.

Minor inconsistency could happen when page cache was not written properly, for ex. due to server process crash.

Regards,

Vlad

[Tomasz Dubiel]

Are you completely sure such warnings about RDB$ tables are harmless? We decided not to ignore such warnings, because a few weeks ago on such database we performed changes in its structure and some time after it the database was damaged, with plenty of corrupted indexes.

There was "Schroedinger's cat" problem. We got plenty of errors: Cannot create foreign key constaint... Partner index does not exist or is inactive.

We couldn't drop such foreign key, because we got an error: constraint ... does not exist. When we tried to create it, we got an error that it already exists.

Best regards.

[Vlad Khorsun]

Are you completely sure such warnings about RDB$ tables are harmless?

  I'm completely sure about warnings you show above.

 

We decided not to ignore such warnings, because a few weeks ago on such database we performed changes in its structure and some time after it the database was damaged, with plenty of corrupted indexes.

  Have you validate that database ?

 

There was "Schroedinger's cat" problem. We got plenty of errors: Cannot create foreign key constaint... Partner index does not exist or is inactive.

We couldn't drop such foreign key, because we got an error: constraint ... does not exist. When we tried to create it, we got an error that it already exists.

  Try to SET corresponding index of FK constraint to ACTIVE - it should rebuild index. I hope it can. If it can't - you need to backup and restore such database.

And be careful with DDL, especially on production database. Use transaction with limited lock timeout: not WAIT, not NO WAIT.

And better if there will be no other connections.

Regards,

Vlad

[Tomasz Dubiel]

Its normal offline validation.

That were errors at the time of a restore (Schroedinger). We couldn't fix it. We had to revert to a healthy backup.

[Vlad Khorsun]

That were errors at the time of a restore (Schroedinger). We couldn't fix it. We had to revert to a healthy backup.

  I.e. you have corrupted database right after restore and there was no errors during restore ?
And restoring from another backup was OK ?

Regards,

Vlad 

[Tomasz Dubiel]

Restore went "successfully", apart from indexes.

Restore from earlier backup, before changes to database structure was ok.

[Dimitry Sibiryakov]

Tomasz Dubiel wrote 13.02.2026 15:03:
> Restore went "successfully", apart from indexes.
> Restore from earlier backup, before changes to database structure was ok.

What kind of changes touched anything around the indexes that failed during
the restore?

--
WBR, SD.