I am interested to understand if you can easily salvage the data files if the log files corrupt for some reason. Thus far I cannot see how this can be easilly achieved as db_backup requires a working environment, and since the log files may have vanished, the LSN of the data files will be greater than of the last log - and therefore refuse to create the environment.
Ideally I guess, I am looking for a tool that can reset the LSN in place. It would be better to have access to your 100's of GB of data and accept a small amount of inconsistency or data loss than have nothing.
Resetting LSNs can be done using db_load -r lsn or using the lsn_reset() method, and it is done in place.
If your log files are corrupted, you would need to verify the database files (you can use the db_verify BDB utility or the verify() method). The actions you will further take depend on the result of verifying the database files:
- if they verify correctly then you just need to reset the LSNs and the file IDs in the databases and start with a fresh environment,
- if they do not verify correctly, you could restore the data from the most recent backup, or you can perform a salvage dump of the data in the database files using db_dump -r or db_dump -R and than reload the data using db_load; see the Dumping and Reloading Databases doc section in the Berkeley DB Programmer's Reference Guide.
In the prior post, there was a link to our documentation, this would be a great place to look for tuning parameters. In general, parameters dealing with cache, database page size, btree/hash, comparison functions and record ordering all can have an effect on db_load performance. Each and every application is unique and you will have to tune for your environment.