Is it possible to recover the database without any transaction logs at
all (no log.* files).

Our actual binary tree data files *.db etc, are uncorrupted, and in
this current case we don't mind lost transactions, we simply want to
bring the datbase back online with it's current data.

However when we run recovery with -c it complains that it can't
recover, with:

Database environment corrupt; the wrong log files may have been removed
or incompatible database files imported from another environment
<my_db_file.db> unable to flush page: 0
txn_checkpoint: failed to flush the buffer cache Invalid argument
PANIC: Invalid argument

We can do something similar in sybase where we say ok, I don't care
what has been added to the transaction log but not committed, I'm happy
with my data in the binary tree, just forget logs and bring online the
current data. Is this possible or I am relegated to losing my db files?

I know that we should have a backup of the log.* files ( at least the
files that the archive command spews out ), but we haven't and we think
it's an interesting case that may happen on our live system.

thanks for listening.

When BDB says 'recovery' it specifically means applying txn log
records to bring a database into a consistent state. So you can't
run recovery because you no longer have all the necessary log
records (BTW in passing I wonder if this is because you're not
taking checkpoints often enough, or not at all ?).

But...you can attempt to regain the data that remains in the
data files (essentially the exact same process as sybase offers).

Let's consider what exactly you have in those data files:
pages that happened to have been written to disk before the
application exited. If you are lucky, the files will not contain
any inconsistencies, either at the BDB metadata level, nor at
the application data semantics level.

So the first thing to do is to check for inconsistencies at the
BDB level. To do this run db_verify on the database. This tool will
tell you if the files are consistent (or not) from a b-tree and page
level perspective. If they are, proceed to the next step.

If not then your only option is to run db_dump on the files to
extract the set of readable keys. Then run db_load with the resulting
flat files to re-build new data files that are not broken.
This process may loose some data but unless you want to break
out your hex editor it was lost anyway.

Once you have a set of files that db_verify says are ok
you then have to consider if the data is consistent from
the application's perspective. This is something that only
you can do since it's your application. An example would be
where a secondary index is out of sync with the primary index.

Check for and fix any such errors (re-loading from only the primary
index may be an option here).

Finally delete any log files and the region files (__xxx files)
and you should be able to run db_recover (which won't actually
do any recovery as there are no log files).

Now you can re-start your application.

If you are sure that the data files are already consistent
(e.g. you know for sure that the application was shut down
gracefully and you simply lost some log files), then it's
ok to just delete the log and region files and re-start.

David,
thanks for the input there, I've gained some useful knowledge from
that.

I've checked out the db files with verify and they all check out ok, my
problem still persists so I assume the issue is firmly with the
application and not BDB.

Our application provider cannot recover their application either so it
looks like I'm off to rebuild the system.

And we'll sort out our backup strategy.

Thanks

Jack


david.boreham (AT) gmail (DOT) com wrote: