From: <ri...@dr...> - 2003-08-05 06:05:25
|
Cees de Groot wrote: > On Mon, 2003-08-04 at 21:09, Alex Boisvert wrote: > >>Hence, you cannot only backup the main database file. You would risk >>getting an incoherent snapshot of your data. > > Or, at least an old snapshot. While the transaction log is being > appended to, the db file is usually in a consistent state. A bit of > tweaking (keep the txn log growing while you are backing up the db) > might give an easy on-line backup tool. That would be great! In other words: when db is put into backup mode the tx log is flushed and then grows until backup mode is off. During that time the file can be safely copied. If you can do this, and also make the log a temp file (i.e. I don't want to see it, just put it in /tmp somewhere), then that'd be terrific. > So I don't think it's a real requirement - stability and a stable file > format are probably more important than compaction. Compaction is not > nice anyway, it sits in the way of 24x7-ness - it's probably better to > make the allocation algorithms incrementally smarter so that bigger > holes are produced in the database, etcetera. If the above is implemented, with tx logs that can grow when the db is being used, then the data can be safely transferred into a new file during that time. That'd work for me. Usually compaction is more useful at the beginning of a production environment, when objects are being created and removed quite frequently. Later on objects most just created and updated, so compaction doesn't help as much. (this is for CMS-type functionality, and along lines of the experiences we have had anyway. YMMV) /Rickard |