Проверка базы firebird на наличие ошибок

gfix [commands and parameters] database_name

• Command line options for the gfix database utility.

• Shadow file handling.

• Cache and buffer handling.

• Transaction management.

• Cache management.

• Starting and stopping a database.

• And much, much more …​

gfix usage instructions for Firebird 3.0.7

usage: gfix [options] <database>
plausible options are:
   -ac(tivate_shadow)   activate shadow file for database usage
   -at(tach)            shutdown new database attachments
   -b(uffers)           set page buffers <n>
   -co(mmit)            commit transaction <tr / all>
   -ca(che)             shutdown cache manager
   -fu(ll)              validate record fragments (-v)
   -fo(rce_shutdown)    force database shutdown
   -fe(tch_password)    fetch password from file
   -h(ousekeeping)      set sweep interval <n>
   -i(gnore)            ignore checksum errors
   -icu                 fix database to be usable with present ICU version
   -k(ill_shadow)       kill all unavailable shadow files
   -l(ist)              show limbo transactions
   -me(nd)              prepare corrupt database for backup
   -mo(de)              read_only or read_write database
   -nol(inger)          close database ignoring linger setting for it
   -n(o_update)         read-only validation (-v)
   -o(nline)            database online <single / multi / normal>
   -pr(ompt)            prompt for commit/rollback (-l)
   -pa(ssword)          default password
   -role                set SQL role name
   -r(ollback)          rollback transaction <tr / all>
   -sq(l_dialect)       set database dialect n
   -sw(eep)             force garbage collection
   -sh(utdown)          shutdown <full / single / multi>
   -tw(o_phase)         perform automated two-phase recovery
   -tra(nsaction)       shutdown transaction startup
   -tru(sted)           use trusted authentication
   -u(se)               use full or reserve space for versions
   -user                default user name
   -v(alidate)          validate database structure
   -w(rite)             write synchronously or asynchronously
   -z                   print software version number

    Options can be abbreviated to the unparenthesized characters

-?

This switch displays the command line options and switches.
It replaces the old method in which you had to supply an invalid switch (such as -⁠help) in order to see the list of valid ones.

-fe[tch_password] <password file name> | stdin | /dev/tty

This switch causes the password for the appropriate user to be read from a file as opposed to being specified on the command line.
The file name supplied is not in quotes and must be readable by the user running gfix.
If the file name is specified as stdin, then the user will be prompted for a password.
On POSIX systems, the file name /dev/tty will also result in a prompt for the password.

-u[ser] username

Allows the username of the SYSDBA user, or the owner of the database to be specified.
This need not be supplied if the ISC_USER environment variable has been defined and has the correct value.

-pa[ssword] password

Supplies the password for the username specified above.
This need not be supplied if the ISC_PASSWORD environment variable has been defined and have the correct value.

Up until Firebird 2, any utility which was executed with a password on the command line could result in other users of the server seeing that password using a command like ps -efx | grep -i pass. From Firebird 2 onwards, this is no longer the case as the password on the command line can no longer be seen by the ps (or other) commands.

To define the username and password as environment variables on a Linux system:

linux> export ISC_USER=sysdba
linux> export ISC_PASSWORD=masterkey

Alternatively, on Windows:

C:> set ISC_USER=sysdba
C:> set ISC_PASSWORD=masterkey

This is very insecure as it allows anyone who can access your session the ability to perform DBA functions that you might not want to allow.

-role role

Supplies the role name to use for the username specified.

-tru[sted]

Use trusted authentication.

linux> gfix -validate my_employee
linux> Unable to perform operation. You must be either SYSDBA -
or owner of the database

linux> gfix -validate my_employee -user sysdba -password masterkey

linux> isql my_employee;
SQL> create shadow 1 manual '/home/norman/firebird/shadow/my_employee.shd1';
SQL> create shadow 2 manual '/home/norman/firebird/shadow/my_employee.shd2';
SQL> commit;
SQL> show database;
Database: my_employee
 Owner: SYSDBA
 Shadow 1: "/home/norman/firebird/shadow/my_employee.shd1" manual
 Shadow 2: "/home/norman/firebird/shadow/my_employee.shd2" manual
...
SQL> quit;

linux> gstat -header my_employee | grep -i shadow
Shadow count 2

4.1. Activating Shadows

The command to activate a database shadow is:

gfix -ac[tivate_shadow] shadow_file_name

This makes the shadow file the new database file, and the users are able to continue processing data as normal and without loss.

In the event that your main database file(s) become corrupted or unreadable, the DBA can activate a shadow file.
Once activated, the file is no longer a shadow file, and a new one should be created to replace it.
Additionally, the shadow file should be renamed (at the operating system prompt) to the name of the old database file that it replaces.

Once a shadow file has been activated, you can see the fact that there are active shadows in the output from gstat:

linux> gstat -header my_employee | grep -i shadow
Shadow count 2
Attributes   active shadow, multi-user maintenance

4.2. Killing Shadows

The command to kill all unavailable database shadows, for a specific database, is:

gfix -k[ill_shadow] database_name

In the event that a database running with shadow files loses a shadow, or a shadow becomes unusable for some reason, the database will stop accepting new connections until such time as the DBA kills the faulty shadow and, ideally, creates a new shadow to replace the broken one.

The following (contrived) example, shows what happens when the database loses a shadow file, and an attempt is made to connect to that database.
There are two sessions in the following example, one is connected to the database while the second deletes a shadow file and then tries to connect to the database.
The command line prompts shows which of the two sessions we are using at the time.

First, the initial session is connected to the database and can see that there are two shadow files attached:

linux_1>isql my_employee
Database: my_employee
SQL> show database;
Database: my_employee
   Owner: SYSDBA
Shadow 1: "/home/norman/firebird/shadow/my_employee.shd1" manual
Shadow 2: "/home/norman/firebird/shadow/my_employee.shd2" manual
 ...

In the second session, we delete one of the shadow files, and then try to connect to the database

linux_2> rm /home/norman/firebird/shadow/my_employee.shd2
linux_2> isql_my_employee
Statement failed, SQLCODE = -901
lock conflict on no wait transaction
-I/O error for file "/home/norman/firebird/shadow/my_employee.shd2"
-Error while trying to open file
-No such file or directory
-a file in manual shadow 2 in unavailable
Use CONNECT or CREATE DATABASE to specify a database
SQL> quit;

The second session cannot connect to the database until the problem is fixed.
The DBA would use the gfix -⁠k[ill_shadow] command to remove details of the problem shadow file from the database and once completed, the second (and subsequent) sessions would be able to connect.

linux_2> gfix -kill_shadow my_employee

linux_2> isql my_employee
Database: my_employee
SQL> show database;
Database: my_employee
   Owner: SYSDBA
Shadow 1: "/home/norman/firebird/shadow/my_employee.shd1" manual
...

The database now has a single shadow file where before it had two.
It is noted, however, that gstat still shows the database as having two shadows, even when one has been removed.

linux> gstat -header my_employee | grep -i shadow
Shadow count 2
Attributes   active shadow, multi-user maintenance

gfix -b[uffers] BUFFERS database_name

linux> gstat -header my_employee | grep -i "page buffers"
Page buffers    0

linux> gfix -buffers 4000 my_employee

linux> gstat -header my_employee | grep -i "page buffers"
Page buffers 4000

6.1. Listing Limbo Transactions

The gfix command -⁠l[ist] will display details of transactions that are in limbo.
If there is no output, then there are no transactions in limbo and no further work need be done.
The command is:

gfix -l[ist] database_name

An example of listing limbo transactions is shown below.
This command is run against the local database on the server named linux where a multi-database transaction had been run connected to databases [email protected]_employee and remote:testlimbo.
Both of these database names are aliases.

linux> gfix -list my_employee
Transaction 67 is in limbo.
 Multidatabase transaction:
 Host Site: linux
 Transaction 67
has been prepared.
 Remote Site: remote
 Database path: /opt/firebird/examples/testlimbo.fdb

If the command is run against the remote database then nothing will be listed because that database does not have any limbo transactions — the transaction that went into limbo, when the network failed, for example, was initiated on the local database.

You may also supply the -⁠pr[ompt] option to the command, and you will be prompted to COMMIT or ROLLBACK each detected limbo transaction.
In this case, the command would be:

gfix -l[ist] -pr[ompt] database_name

An example of this is shown below.

linux> gfix -list -prompt my_employee
Transaction 67 is in limbo.
 Multidatabase transaction:
 Host Site: linux
 Transaction 67
has been prepared.
 Remote Site: remote
 Database path: /opt/firebird/examples/testlimbo.fdb
Commit, rollback or neither (c, r, or n)?

6.2. Committing Or Rolling Back

When a limbo transaction has been detected, the DBA has the option of committing or rolling back one or more of the transactions reported as being in limbo.

When more than one transaction is listed, the DBA can either commit or roll back all transactions in limbo, or a specific transaction number.

The following commands show the -⁠co[mmit] option being used, but the -⁠r[ollback] option applies as well, it all depends on what the DBA is trying to achieve.

To commit every limbo transaction on the database, the following command would be used:

gfix -co[mmit] all database_name

If the DBA wanted to commit a single transaction, then the command would change to the following:

gfix -co[mmit] TXN database_name

Where TXN is the transaction number to be committed.

When either of these options are used, there is no feedback from gfix to advise you that the commit actually worked.
You would need to rerun the gfix -⁠list command to make sure that all, or the selected, limbo transactions had indeed gone.

You cannot commit or rollback a transaction that is not in limbo.
If you try, the following will occur:

linux> gfix -commit 388 my_employee
failed to reconnect to a transaction in database my_employee
transaction is not in limbo
-transaction 388 is active
unknown ISC error 0

When committing or rolling back all limbo transactions, the -⁠pr[ompt] option can be specified.
It is, however, not permitted when processing a single transaction.
An example of using the -⁠pr[ompt] option has been shown above under listing limbo transactions.

6.3. Automatic Two-phase Recovery

Gfix can be used to perform automatic two-phase recovery.
The command for this is -⁠tw[o_phase] and, like -⁠co[mmit] and -⁠r[ollback] above, requires either all or a transaction number.

The output of the -⁠l[ist] command shows what will happen to each listed transaction in the event that the DBA runs the -⁠tw[o_phase] command.

The command also takes the -⁠pr[ompt] option, as above, when used to process all transaction.

The command line to carry out automatic two-phase recovery is:

gfix -tw[o_phase] TXN database_name

or

gfix -tw[o_phase] all database_name

As above, TXN is a single transaction number from the list of limbo transactions.

...
-ca[che]      shutdown cache manager
...

gfix -mo[de] MODE database_name

linux> gfix -mode read_only my_employee

linux> isql my_employee
Database: my_employee

SQL> create table test(stuff integer);
Statement failed, SQLCODE = -902
Dynamic SQL Error
-attempted update on read-only database

SQL> quit;

linux> gfix -mode read_write my_employee

linux> isql my_employee
Database: my_employee

SQL> create table test(stuff integer);

SQL> show table test;
STUFF      INTEGER Nullable

SQL> quit;

linux> gfix -mode read_only my_employee
lock time-out on wait transaction
-lock time-out on wait transaction
-object my_employee is in use

linux> echo $?
0

linux> gfix -mode read_only my_employee
lock time-out on wait transaction
-object /opt/firebird/databases/my_employee.fdb is in use

linux> echo $?
0

• Dialect 1 stores date and time information in a DATE data type and has a TIMESTAMP data type which is identical to DATE.
  Double quotes are used to delimit string data.
  The precision for NUMERIC and DECIMAL data types is less than a dialect 3 database and if the precision is greater than 9, Firebird stores these as DOUBLE PRECISION.
  BIGINT is not permitted as a data type.

• Dialect 2 is available only on the Firebird client connection and cannot be set in the database.
  It is intended to assist debugging of possible problems with legacy data when migrating a database from dialect 1 to 3.
  This dialect cannot be set for a database using gfix.
  (See below.)

• Dialect 3 databases allow numbers (DECIMAL and NUMERIC data types) to be stored as BIGINT when the precision is greater than 9.
  The TIME data type is able to be used and stores time data only.
  The DATE data type stores on date information.
  Double quotes can be used but only for identifiers that are case dependent, not for string data which has to use single quotes.

gfix -s[ql_dialect] DIALECT database_name

linux> gfix -sql_dialect 3 my_employee

linux> gstat -header my_employee | grep dialect
Database dialect    3

linux> gfix -sql_dialect 1 my_employee

linux> gstat -header my_employee | grep dialect
Database dialect    1

remote> isql my_employee -user norman -password whatever
Database: my_employee

SQL> show sql dialect;
Client SQL dialect is set to: 3 and database SQL dialect is: 3

linux> gfix -sql_dialect 2 my_employee
Database dialect 2 is not a valid dialect.
-Valid database dialects are 1 and 3.
-Database dialect not changed.

linux> isql my_employee
Database: my_employee

SQL> set sql dialect 2;
WARNING: Client SQL dialect has been set to 2 when connecting -
to Database SQL dialect 3 database.

SQL> show sql dialect;
Client SQL dialect is set to: 2 and database SQL dialect is: 3

10.1. Garbage

Garbage, for want of a better name, is the detritus that Firebird leaves around in the database after a rollback has been carried out.
This is basically a copy of the row(s) from the table(s) that were being updated (or deleted) by the transaction prior to the rollback.

Almost all garbage is created by committed transactions.
Since around V2.5 transactions that rollback are cleaned up immediately — assuming that Firebird is still running.

The major cause of garbage build-up is long-running transactions that require Firebird to keep old versions of records that are frequently updated.
Another source of garbage is an application strategy that deletes records and never revisits them.

What actually happens on delete is that Firebird stores a «deleted stub» with the full record as a back version.
Until the delete is mature — meaning that all active transactions started after the delete was committed — the old version must be preserved.

Imagine a table that’s indexed and accessed by date.
On some schedule, records age out and are deleted.
In the application, records are accessed by date, and the deleted records are so old no query ever asks for them.
So there they sit, taking up space and doing no good to anyone.
Even with a garbage collect thread, some active transaction has to stumble over deleted records or records with unneeded back versions before the record will be garbage collected.

In cooperative garbage collection, that particular record will be cleaned up immediately (or at least when the transaction gets some cycles).
The dedicated garbage collection thread should clean up all the records on a page, but not until an active transaction tells it that there’s a page that needs cleaning.

Because Firebird uses multi-generational architecture, every time a row is updated or deleted, Firebird keeps a copy in the database.
These copies use space in the pages and can remain in the database for some time, especially if there are no active transactions stumbling across them!

There are a number of causes of garbage:

With regard to the remnants from aborted or rolled back transactions, Firebird (now) carries out record-keeping to facilitate save points.
This housekeeping allows Firebird to identify and, if necessary, undo all changes made by a transaction in the event that it is rolled back, or which failed due to a lost connection.

If a failed transaction is rolled back in either manner, its state is set to committed as there are no differences between a failed transaction and one in which it committed after making no changes.

These remnants are simply older copies of the rows that were being updated by the respective transactions.
The differences are that:

Firebird will automatically sweep through the database and remove the remnants of rolled back transactions and this has two effects:

In the Super Server version of Firebird 2.0, garbage collection has been vastly improved.
There are now three different ways of operation and these are configurable by setting the GCPOLICY parameter in the firebird.conf configuration file.
By default, Super Server uses combined while Classic Server uses cooperative.
The other option is background.

10.2. Setting Sweep Interval

The default sweep interval for a new database is 20,000.
The sweep interval is the difference between the Oldest Snapshot Transaction, or OST and the Oldest Interesting Transaction or OIT.

An interesting transaction is one which has not yet committed.
It may be still active, in limbo or may have been rolled back.
(Limbo transactions are never garbage collected.)

The sweep facility runs through the database and gets rid of old rows in tables that are out of date.
This prevents the database from growing too big and helps reduce the time it takes to start a new transaction on the database.

You can check if a manual sweep may be required by running the gstat utility to check the database header page and extract the Oldest Transaction (OIT) and Oldest Snapshot (OST) numbers from the output.
If OST — OIT is small (less than the sweep interval) then a manual sweep may be in order.
The SHOW DATABASE command in isql will also show the details you need.

Alternatively, another idea is to run gstat with the switches set to show old record versions.
If that shows a problem, then it may be a good idea to start looking for long running transactions.

The options for this are:

gstat database -r[ecord]
gstat database -d[ata] -r[ecord]
gstat database -r[ecord] -t[able] table_names

For example:

tux> gstat test.fdb -r -t NORMAN

...
Analyzing database pages ...
NORMAN (142)
    Primary pointer page: 268, Index root page: 269
    Average record length: 0.00, total records: 15
    Average version length: 9.00, total versions: 15, max versions: 1
    Data pages: 1, data page slots: 1, average fill: 16%
...

The information is shown in the ‘record versions’ statistic.
In this example, there are 15 versions and as the ‘total records’ is also 15, then all the records have been deleted and need garbage collecting.

A manual sweep can be run by using the -⁠s[weep] command.
(See below).

To alter the database’s automatic sweep interval, use the following command:

gfix -h[ousekeeping] INTERVAL database_name

The INTERVAL parameter is the new value for the sweep interval.
The database name parameter is the database upon which you wish to alter the setting for automatic sweeping.
The following example shows the setting being changed from the default to a new value of 1,000.

linux> gfix -h 1000 my_employee

linux> gstat -header my_employee | grep Sweep
Sweep interval:     1000

10.3. Manual Garbage Collection

If automatic sweeping has been turned off, or only runs rarely because of the sweep interval setting, the DBA can manually force a sweep to be performed.
The command to carry out this task is:

gfix -s[weep] [-i[gnore]] database_name

This command will force the garbage left over from old rolled back transactions to be removed, reducing the database size and improving the performance of new transactions.
Rolled back transactions are less of a problem than old versions from committed transactions, however, when the newest versions is being used by all current and future active transactions.

The -⁠i[gnore] option may be supplied.
This forces Firebird to ignore checksum errors on database pages.
This is not a good idea and should rarely need to be used, however, if your database has suffered some problems it might be necessary to use it.

The following example shows a manual database sweep being implemented:

linux> gfix -sweep my_employee

10.4. Disabling Automatic Sweeping

If you set the sweep interval to zero then automatic sweeping will be disabled.
This implies that there will be no automatic housekeeping done so your database performance will not suffer as a result of the processing requirements of the automatic sweep.

If you disable sweeping you are advised to run a manual sweep at regular intervals when the database is quiet.
Alternatively, simply make sure you take regular backups of the database and as this is something you should be doing anyway, it shouldn’t be a problem.

11.1. Database Shutdown

If there is maintenance work required on a database, you may wish to close down that database under certain circumstances.
This is different from stopping the Firebird server as the server may well be running other databases which you do not wish to affect.

The command to close a database is:

gfix -sh[utdown] OPTION TIMEOUT database_name

The TIMEOUT parameter is the time, in seconds, that the shutdown must complete in.
If the command cannot complete in the specified time, the shutdown is aborted.
There are various reasons why the shutdown may not complete in the given time, and these vary with the mode of the shutdown and are described below.

The OPTION parameter is one of the following:

When a database is closed, the SYSDBA or the database owner can still connect to perform maintenance operations or even query and update the database tables.

linux> gfix -shut -attach 5 my_employee
lock conflick on no wait transaction
-database shutdown unsuccessful

linux> isql my_employee -user norman -password whatever
Statement failed, SQLCODE = -901
database my_employee shutdown
Use CONNECT or CREATE DATABASE to specify a database
SQL>

linux> gfix -shut -tran 5 my_employee
lock conflick on no wait transaction
-database shutdown unsuccessful

SQL> select * from test;
Statement failed, SQLCODE = -902
database /home/norman/firebird/my_employee.fdb shutdown in progress
Statement failed, SQLCODE = -902
database /home/norman/firebird/my_employee.fdb shutdown in progress
Statement failed, SQLCODE = -901
Dynamic SQL Error
-SQL error code = -901
-invalid transaction handle (expecting explicit transaction start)

11.2. Starting a Database

Once all maintenance work required on a database has been carried out, you need to restart the database to allow normal use again.
(See shutdown option above for details of closing a database.)

The -⁠o[nline] command allows a database to be restarted.
It takes a single parameter which is the database name as follows:

gfix -o[nline] database_name

The following example shows a closed database being started.

linux> gfix -online my_employee

11.3. New Startup and Shutdown States in Firebird 2.0

The above discussion of stopping and starting a database apply to all versions of the server up to version 2.0.
From 2.0 the commands will work as described above, but a new state has been added to define exactly how the database is to be stopped or started.
The commands change from those described above to the following:

gfix -sh[utdown] STATE OPTION TIMEOUT database_name

gfix -o[nline] STATE database_name

STATE is new in Firebird 2.0 and is one of the following:

There is a hierarchy of states for a database.
The above list shows them in order with normal at the top and full at the bottom.

This hierarchy is important, you cannot shutdown a database to a higher or equal level that it currently is, nor can you startup a database to a lower or equal level.

If you need to identify which level a database is currently running at, gstat will supply the answers.
The following example puts a database fully online then progressively shuts it down to fully offline.
At each stage, gstat is run to extract the Attributes of the database.

linux> gfix -online normal my_employee
linux> gstat -header my_employee | grep Attributes

        Attributes

linux> gfix -shut multi -attach 0 my_employee
linux> gstat -header my_employee | grep Attributes

        Attributes              multi-user maintenance

linux> gfix -shut single -attach 0 my_employee
linux> gstat -header my_employee | grep Attributes

        Attributes              single-user maintenance

linux> gfix -shut full -attach 0 my_employee
linux> gstat -header my_employee | grep Attributes

        Attributes              full shutdown

linux>

gfix -u[se] USAGE database_name

linux> gfix -use full my_employee
linux> gstat -header my_employee | grep Attributes
Attributes no reserve

linux> gfix -use reserve my_employee
linux> gstat -header my_employee | grep Attributes
Attributes

13.1. Database Validation

Sometimes, databases get corrupted.
Under certain circumstances, you are advised to validate the database to check for corruption.
The times you would check are:

When a database is validated the following checks are made and corrected by default:

There are options to perform further, more intensive, validation and these are discussed below.

gfix -v[alidate] database_name

gfix -v[alidate] -fu[ll] database_name

gfix -v[alidate] -fu[ll] -n[o_update] database_name

gfix -v[alidate] -n[o_update] database_name

gfix -v[alidate] -fu[ll] -i[gnore] -n[o_update] database_name

gfix -v[alidate] -i[gnore] database_name

13.2. Database Recovery

If the database validation described above produces no output then the database structures can be assumed to be valid.
However, in the event that errors are reported, you may have to repair the database before it can be used again.

gfix -me[nd] database_name

gfix -v[alidate] -fu[ll] -i[gnore] database_name

gfix -me[nd] -i[gnore] database_name

gbak -backup -ignore database_name  backup1.fbk

gbak -create  backup1.fbk new_database_name

gbak -b -skip_data country,currency  localhost/3050:C:Datainventory.fdb C:data111.gbk  -user SYSDBA -pass masterkey

gfix -w[rite] MODE database_name

sync

Data is written synchronously.
This means that data is flushed to disc on COMMIT.
This is safest for your data.

async

Data is written asynchronously.
The operating system controls when the data is actually written to disc.

gfix -nol[inger] database_name

linux> gfix -z
gfix version LI-V2.0.0.12748 Firebird 2.0

18.1. Shadows

The gstat seems to take some time to respond to the addition of shadow files to a database.
After adding two shadows to a test database, gstat still showed that there was a Shadow count of zero.

Even worse, after killing the second shadow file and running the DROP SHADOW command in isql to remove the one remaining shadow file, gstat decided that there were now three shadow files in use.

18.2. Response Codes Are Usually Zero

Even using Firebird version 2 it appears that many commands, which fail to complete without an error, return a response of 0 to the operating system.

For example, the following shows two attempts to shut down the same database, the second one should fail — it displays an error message — but still returns a zero response to the operating system.
This makes it impossible to built correctly error trapped database shutdown scripts as you can never tell whether it actually worked or not.

linux> gfix -shut -force 5 my_employee
linux> echo $?
0

linux> gfix -shut -force 5 my_employee
Target shutdown mode is invalid for database -
"/home/norman/firebird/my_employee.fdb"
linux> echo $?
0

18.3. Force Closing a Database

Under classic server, using the -⁠fo[rce_shutdown] option to the -⁠sh[utdown] command acts exactly the same as the -⁠at[tach] option.

18.4. Limbo Transactions

There are a couple of problems with limbo transactions as discovered by Paul in his testing.

linux>cd /home/norman/firebird
linux>cp my_employee.fdb my_new_employee.fdb

linux> mv my_employee.fdb my_old_employee.fdb

linux> gfix -list /home/norman/firebird/my_new_employee.fdb
Transaction 67 is in limbo.
Could not reattach to database for transaction 67.
Original path: /home/norman/firebird/my_employee.fdb

Enter a valid path: /home/norman/firebird/my_old_employee.fdb

 Multidatabase transaction:
 Host Site: linux
 Transaction 67
has been prepared.
 Remote Site: remote
 Database path: /opt/firebird/examples/testlimbo.fdb