Open firebird-automations opened 21 years ago
firebird-automations
commented
18 years ago Commented by: Alice F. Bird (firebirds)
Date: 2006-01-23 21:17 Sender: kpalagin Logged In: YES user_id=838827
I absolutely agree. And this is not only Oracle feature, but MS's too - ESE has it. Redo log can provide significant performance improvement in disk access by allowing separation of sequential uncached writing of transaction log and random buffered writes and reads.
firebird-automations
commented
16 years ago Commented by: ohenri (ohenri)
Every well-designed DBMS has this feature, except Firebird - but the lack of this logging makes a Firebird databse easy to handle.
So I would like to extend this request as follows:
- Choosed on a "per database" way, it should be possible to switch on/off a full logging system (in addition to the normal generation system).
- Logs shall be written to local drives
- Dual-Logging shall be possible too (where at least one log may be placed on a network drive), where logging continues if one log is lost (zero space conditon, for example).
- Partially failed dual-logs shall be merged by a tool to a healthy single log.
- Having a backup and all consecutive (single) logs (from that point), a roll forward shall be possibe.
- The roll forward shall be limited to (stopped at) any specified date/time .
firebird-automations
commented
16 years ago
Submitted by: mgast (mgast)
Votes: 1
SFID: 819330# Submitted By: mgast
Description of the current state:
1. In Firebird all data changes applied to a database after the time of starting the last database backup a lost in case of a failure that corrupts one of the database files.
2. If your last database backup is corrupt, you only can switch to the state stored in an older backup.
What i would like to have is a kind of REDO LOG facility as it exists in Oracle RDBMS. In Oracle it is realized as a buffer that works on a set of files (organized as flat sequence or as ring buffer) in which all statements changing the content of the database are stored.
In the case of a corrupt database file, you can rebuild a state of your database later than the point of time, where you started your last database backup.
If you backup all redo log files used since the starting time of a given backup you can rebuild your database to every state after this backup. A corrupt database backup does not longer result in uncontrolled data loss.