1) Need to add this option in Derby maybe as some property
2) Also from discussions on the list, Mike suggested that
- that the logging system be changed to somehow
record that the database has operated in this manner, so that if
the database goes corrupt we don't waste effort trying to figure out
what when wrong. Probably need some way to mark the log records, the
log control file and write a message to the user error log file.
Description
Dan Debrunner posted a fix to allow for relaxed durability changes in http://article.gmane.org/gmane.comp.apache.db.derby.user/681/match=relaxed+durability
1) Need to add this option in Derby maybe as some property
2) Also from discussions on the list, Mike suggested that
- that the logging system be changed to somehow
record that the database has operated in this manner, so that if
the database goes corrupt we don't waste effort trying to figure out
what when wrong. Probably need some way to mark the log records, the
log control file and write a message to the user error log file.
A little background: Sometime earlier on the list, Dan posted a fix to make derby go faster with relaxed durability with some flags. The post is at http://article.gmane.org/gmane.comp.apache.db.derby.user/681/match=relaxed+durability
This mode is very useful for unit testing or at development time when recoverability is not required.
Basically in this mode, syncs are disabled for logs, data writes at checkpoint, page allocation when file is grown; - what this means is that data is not flushed all the way to the disk and in most cases i/o cost is not involved. Note, code already exists in Derby to do this.
So for Derby 218, This patch addresses the following requirements: 1) Have a single property to enable this relaxed durability mode, so it is easy for users to enable it.
2) Print message to derby.log that this mode is enabled
3) A way to report boot errors that may be because of this option being enabled. What this maps to is - have a marker to recognize that database was booted in this mode, and then on subsequent boot; if errors happen during recovery - report a message that it could have happened because of this mode being set.
Thanks Suresh for your comments. I have attached a new patch that takes care of them and as well as the property name change as discussed on the list.
So now,
1)To enable this no syncs mode, the property setting is derby.system.durability=test If it is set to any other value other than test, then this property setting is ignored and the system will default to the usual mode where all syncs happen correctly.
2) If database is booted in this mode then the flag to indicate this mode is being used is set in log.ctrl file and it will not change after that.Thus there wont be any switching between this mode ( no syncs) to default ( all syncs) mode because we cannot guarantee that the database will be in a consistent state once its booted in this no sync mode..
3) This flag is now written out as part of the log control flags in log.ctrl file instead of using a spare byte.
committed this change with svn 169538.
Changes include:
1)To enable this no syncs mode, the property setting is derby.system.durability=test If it is set to any other value other than test, then this property setting is ignored and the system will default to the usual mode where all syncs happen correctly.
2) If database is booted in this mode then the flag to indicate this mode is being used is set in log.ctrl file and it will not change after that.Thus there wont be any switching between this mode ( no syncs) to default ( all syncs) mode because we cannot guarantee that the database will be in a consistent state once its booted in this no sync mode..
3) This flag is now written out as part of the log control flags in log.ctrl file instead of using a spare byte.
4) Syncs not forced for
- the log file at each commit
- the log file before data page is forced to disk
- page allocation when file is grown
- data writes during checkpoint
Sunitha Kambhampati added a comment - 23/May/05 12:08 PM committed this change with svn 169538.
Changes include:
1)To enable this no syncs mode, the property setting is derby.system.durability=test If it is set to any other value other than test, then this property setting is ignored and the system will default to the usual mode where all syncs happen correctly.
2) If database is booted in this mode then the flag to indicate this mode is being used is set in log.ctrl file and it will not change after that.Thus there wont be any switching between this mode ( no syncs) to default ( all syncs) mode because we cannot guarantee that the database will be in a consistent state once its booted in this no sync mode..
3) This flag is now written out as part of the log control flags in log.ctrl file instead of using a spare byte.
4) Syncs not forced for
- the log file at each commit
- the log file before data page is forced to disk
- page allocation when file is grown
- data writes during checkpoint
Changes include:
1)To enable this no syncs mode, the property setting is derby.system.durability=test If it is set to any other value other than test, then this property setting is ignored and the system will default to the usual mode where all syncs happen correctly.
2) If database is booted in this mode then the flag to indicate this mode is being used is set in log.ctrl file and it will not change after that.Thus there wont be any switching between this mode ( no syncs) to default ( all syncs) mode because we cannot guarantee that the database will be in a consistent state once its booted in this no sync mode..
3) This flag is now written out as part of the log control flags in log.ctrl file instead of using a spare byte.
4) Syncs not forced for
- the log file at each commit
- the log file before data page is forced to disk
- page allocation when file is grown
- data writes during checkpoint