IBPhoenix Development

Gbak Bugs

Brief Description

List of bugs fixed in this release of GBAK

GBAK is slow
See performance section for product changes that corrected this problem.

Field with scale would not allow restore
If you create a column with a scale, load data, define an unique index, change the global field to drop the scale, backup database, then restore may fail because a column may get duplicate value.

Since changing the field definition can be done only using qli or gdef which are unsupported tools, we can just fix the restore procedure to continue restoring a database even if we failed to build an index. If an index restoration fails (either due to out of disk space or unique violation) we will deactivate the index that failed and try to commit again. If any index was deactivated, we will NOT bring the database on line after the restore, and issue a message to that effect. gbak will return a status code to the shell in this event:

0==no errors
1==error, database not restored
2==error, database restored, not online, needs sysdba attention

Regression in several tests using "gbak -verbose"

GBAK would write extra information at the end of a GBAK file. This was noticed when the size of the GBAK IO buffer was increased as a performance improvement - GBAK previously would always write only full buffers - even for the last buffer of the file.
GBAK now properly terminates the file, by writing out only the "used" amount of the IO Buffer, without padding to the size of the IO buffer.

This MAY change behavior when gbak'ing to tape - previously, only tape records of size 1K were ever written to the tape. In the new IO buffer setup, tape records of size 16K are written to tape, and the last record is written in a size from 1 - 16K bytes, depending on data in the last IO buffer

Cannot transliterate between character sets error

Gbak could not restore a V3.3 if database had an index definition with comment field. This was an acceptable GDEF/GDML operation

The attribute which indicates that an index contains a comment field and is equal 8 under IB3.3 was accidently getting a new value of 9 under InterBase 4.0. At the same time, a new attribute, att_index_foreign_key, had been added with value 8. Thus, when gbak V4.0 faces index attribute with value 8 during restore procedure of a v3.3 database, it will recognize this attribute as att_index_foreign_key instead of att_index_description2.

As part of the fix to this bug , 5.0 GBAK now writes backup files in new format 5. GBAK will read backup files in format 4 & 5. Format 4 was used for InterBase 3.3 through InterBase 4.2. It is believed that GBAK will continue to read format 1,2,3 backup files (much older than InterBase 3.0), but this will not be tested or supported.

Format 5 is functionally equivalent to format 4. However, the root of bug 8183 was a difference in how version 3.3 GBAK interrupted the backup file format vs. how 4.0 would read it. The 4.0 format is now distinguished as backup format 5.

Once customers backup in Format 5, their backup files cannot be read by a GBAK version prior to 5.0. Which means a customer trying InterBase 5.0 cannot migrate back to an older version using GBAK.
Workaround: Use 5.0 GBAK with a 4.0 backend or backup databases using V4.0 before migrating to 5.0. Then, if they wish to return to the V4.0 product, they should use the V4.0 .gbak files to restore their V4.0 databases. Using this method, all work done under 5.0 would be lost when they restore their older V4.0 version of the database.

GBAK doesn't ABORT if Stored Procs. w/PLAN clause depend on INACTIVE index

The problem is that we restore the procedures before we restore the indices referenced in the plan. This order is somewhat determined by the order things are written to the backup file. The fix was to restore the procedures in their regular order, but restore them under a different transaction that was not committed until after the indices were activated. An affect of this change was that we are now unable to restore views on stored procedures. This is tricky since views are backed-up just like regular relations, except they have 2 extra properties. The solution here was to restore the regular relation properties in the regular transaction and restore the view properties in the same transaction as the stored procedures

Similar changes were applied to allow the restore of objects when dependent objects were not located. Examples: Missing UDF library, missing external file, Missing blob filter library, inactive or missing index.

In these events, GBAK will issue a warning message, but will continue with the restore.
The database will be brought on-line after conclusion of the restore if only warning messages were issued.