There are additional considerations when using sybdumptran.
During a load sequence of a database dump and one or more transaction log dumps, SAP ASE verifies that the transaction log dump is loaded in sequence based on a sequence number stored in the dump header.
If you do not use the most recent dump as a metadata file for a transaction log dump generated by sybdumptran, the sequence number will be incorrect, causing the load of this transaction log dump to fail. The load transaction option with override=sequence ignores this error and allows the load of an out-of-sequence transaction log dump.
If the sequence number sybdumptran created for the dump does not match the new sequence number of the previous dump, restore the database using the load tran command with the with override=sequence option. You cannot use this option when loading transaction dumps created by SAP ASE, but only when loading transaction logs created with sybdumptran.
When using the override=sequence option, make sure the transaction log to be loaded is indeed the next in the sequence. Since the sequence number is there to protect the sequence, overriding it means the task must be performed correctly. Loading a transaction log out of sequence can corrupt the database (for example, if an earlier dump transaction is omitted during the load, so that the load sequence would need to be repeated, this time, in the correct order).
If a partially logged operation (such as select into without the enable full logging for select into database option) was done between the last transaction log that was dumped normally, and the transaction log that is created by sybdumptran, then a sequence error will not be reported during the load of the latter, even when using the most recent transaction log dump as a metadata file. Normally, a partially logged operation deliberately breaks the sequence to make sure that a subsequent dump transaction does not take place.
In such a case, do not load the dump from sybdumptran. sybdumptran dumps the transaction log, irrespective of whether partially logged operations have taken place or not, because the utility does not have access to the metadata information held within the database. If the sequencing is overridden when the transaction log is loaded, the load may fail, or worse, the database may become corrupted.
If you make use of partially logged operations and you are unsure whether such an operation took place before the sybdumptran operation, make sure to run database consistency checks after the transaction log created by sybdumptran, has been loaded.
In this example, when you omit the -m metadata file option and specify the dump history file, sybdumptran locates the metadata file in the dump history file:
> sybdumptran -o /dumps/db.trn_sdt -h /dumps/dump_hist -d db
Opening output-file '/dumps/db.trn_sdt'.
Opening dump-history-file '/dumps/dump_hist'.
Option 'metadata-file' is not supplied, using last dump '/dumps/db.trn1' from dump history file.
Opening metadata-file '/dumps/db.trn1'.
Opening log devices used by database:
Opening device "db_log1", path "/sdc1_eng/devices/db.log1".
Opening device "db_log2", path "/sdc1_eng/devices/db.log2".
Building run-lists using first log page=10894.
Finished building run-lists, number of log pages=1, first log page=10894, last log page=10894.
Dumping log pages to output file "/dumps/db.trn_sdt".
Finished dumping 1 log pages.
Sybdumptran completed without errors.