Re: [Firebird-devel] Firebird Transaction ID limit solution - Email found in subject

[Ann H. <aha...@nu...>]

Sean,
>
>> The problem is not downtime is how much downtime. Backup and restore is
>> so much downtime.
>
> There are a couple of possible solutions which would reduce the downtime;
> - a new backup/restore tool which would use multiple readers/writers to minimize execution time,

Here we're talking about a logical backup that can be used to restart
transaction numbers.  Record numbers are based loosely on record
storage location.  Since a logical backup/restore changes storage
location and thus record numbers and indexes link values to record
numbers, indexes must be recreated.

The problem with a multi-threaded logical backup is that all the
threads contend for the same I/O bandwidth and possibly the same CPU
time.  Much of the restore time is spent sorting keys to recreate
indexes and multiple threads would contend for the same temporary disk
I/O.


> - a "data port" utility which would allow for data to be ported from a live database to a new database while live is active but would need a finalization step where the live database is shutdown to apply the final data changes and add FK constraints.

It's not immediately obvious to me how that sort of backup/restore
could reset transaction numbers.

> There are, however, certain "realities" which cannot be overcome; disk throughput/IO performance.
>
>