Add switch to gbak to specify initial "Oldest Transaction Number" value on Restore [CORE6121]

[firebird-automations]

Submitted by: @livius2

Votes: 2

Please add switch to gbak to restore database with specified transaction number.
E.g. Interbase have this as "-START(ING_TRANS)" the name can be different.
I suppose it is very simple to implement as already during restore Firebird start this numbering from 1. Now it should take into account if start it from 1 or specified value from the parameter.

gbak -c -v -START 123456789

and database after restore looks like

Database header page information:
Flags 0
Checksum 12345
Write timestamp Aug 9, 2019 15:17:08
Page size 4096
ODS version 16.0
Oldest transaction 123456790 <- THE SPECIFIED NUMBER +1
Oldest active 123456791
Oldest snapshot 123456791
Next transaction 123456850
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 2048
Next header page 0
Database dialect 3
Creation date Aug 9, 2019 15:17:07
Backup timestamp Aug 9, 2019 15:17:08
Attributes force write

Variable header data:
    Sweep interval:         20000
    \*END\*

[firebird-automations]

Commented by: Sean Leyne (seanleyne)

The implementation of this feature would first require changes to the backup process to record the last committed transaction number associated with each data row. So, the feature request should be framed in the larger context.

[firebird-automations]

Commented by: @mrotteveel

@sean This wouldn't need a change to the backup process. As far as I understand the requirement, instead of starting the new database with transaction nr 1, the restore will start with the provided transaction nr. It will restore the same data whether your provide the starting transaction id or not.

[firebird-automations]

Modified by: Sean Leyne (seanleyne)

summary: Add switch to gbak to restore database with specified transaction number => Add switch to gbak to specify initial "Oldest Transaction Number" value on Restore

[firebird-automations]

Commented by: Sean Leyne (seanleyne)

@mark, sorry, I got this mixed up with the IB feature of allowing partial restores... have edited the description/summary to better reflect the requested change.

[firebird-automations]

Commented by: @hvlad

This feature request is to allow user applications to deal with big transaction numbers.
OK.

But i don't understand - why it should be done using gbak\restore ???

Why not add special option to the CREATE DATABASE statement ?
Or, introduce special SQL statement, say SET NEXT TRANSACTION TO <number> ?

Note, to implement it it is not enough to increment Next on header page.
Engine expects to see *all* TIP pages, even actually unused (with last tx number less than OIT).

[firebird-automations]

Commented by: @livius2

>> But i don't understand - why it should be done using gbak\restore ???

it looks for me a simplest possible place for such feature and require almost no changes in the Firebird itself.

>> Why not add special option to the CREATE DATABASE statement ?

this can work only for new db but normally someone need to test already existed database.

>>Or, introduce special SQL statement, say SET NEXT TRANSACTION TO <number> ?

this will be good but i suppose it will be harder to implement.

[firebird-automations]

Commented by: @hvlad

Karol,

believe me - possible implementation have nothing common with restore task.
It anyway could be done inside engine\create_database (or as new SQL statement).

Please, forget about "simplest possible place" and " harder to implement"

[firebird-automations]

Commented by: @livius2

Ok Vlad, this was not my intention to make this bad but fast ;-)
I only know that team have limited time and the functionality has limited use.

[firebird-automations]

Commented by: @asfernandes

If the feature is implemented in engine (create database or something else), it will probably be needed to be also exposed in gbak so records are restored with the high ids.

[firebird-automations]

Commented by: @hvlad

Adriano,

sure, it could be exposed to gbak. But first it must to be implemented at engine - this is my point.