 | |
#41
 
| |||
| |||
|
Re: implementing a database log -
04-22-2008
, 01:53 AM
|
"Christoph Rupp" <cruppst... (AT) gmail (DOT) com> wrote in message news:91140c56-1f05-4b5d-b45f-b34920db2051 (AT) x41g2000hsb (DOT) googlegroups.com... Brian, On Apr 21, 11:00 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. It's not an SQL database, i don't even have the notion of "rows", but basically i think your #4 is the same as my #1 or #2. No, it isn't. #1 requires the logging of additional records that may not have been affected by an update. #2 doesn't log the entire changed record, but only bits and pieces. I would think that limiting the units of change to individual records--entire records--would simplify the process of marking and isolating units of work while at the same time guaranteeing consistency. |
change to an individual record. Are you suggesting transactions to
define arbitrarily large units of work aren't needed?
Typically a log will contain special log records to mark transaction
boundaries. Many systems allow interleaving of transaction log
records by using a transaction id in each log record. Each
transaction is normally expected to end with a commit or abort log
record.
This is irrespective of whether physical or logical changes are
logged.
#42
| |||
| |||
|
|
"Christoph Rupp" <cruppst... (AT) gmail (DOT) com> wrote in message news:91140c56-1f05-4b5d-b45f-b34920db2051 (AT) x41g2000hsb (DOT) googlegroups.com... Brian, On Apr 21, 11:00 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. It's not an SQL database, i don't even have the notion of "rows", but basically i think your #4 is the same as my #1 or #2. No, it isn't. #1 requires the logging of additional records that may not have been affected by an update. #2 doesn't log the entire changed record, but only bits and pieces. I would think that limiting the units of change to individual records--entire records--would simplify the process of marking and isolating units of work while at the same time guaranteeing consistency. |
change to an individual record. Are you suggesting transactions to
define arbitrarily large units of work aren't needed?
Typically a log will contain special log records to mark transaction
boundaries. Many systems allow interleaving of transaction log
records by using a transaction id in each log record. Each
transaction is normally expected to end with a commit or abort log
record.
This is irrespective of whether physical or logical changes are
logged.
#43
| |||
| |||
|
|
"Christoph Rupp" <cruppst... (AT) gmail (DOT) com> wrote in message news:91140c56-1f05-4b5d-b45f-b34920db2051 (AT) x41g2000hsb (DOT) googlegroups.com... Brian, On Apr 21, 11:00 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. It's not an SQL database, i don't even have the notion of "rows", but basically i think your #4 is the same as my #1 or #2. No, it isn't. #1 requires the logging of additional records that may not have been affected by an update. #2 doesn't log the entire changed record, but only bits and pieces. I would think that limiting the units of change to individual records--entire records--would simplify the process of marking and isolating units of work while at the same time guaranteeing consistency. |
change to an individual record. Are you suggesting transactions to
define arbitrarily large units of work aren't needed?
Typically a log will contain special log records to mark transaction
boundaries. Many systems allow interleaving of transaction log
records by using a transaction id in each log record. Each
transaction is normally expected to end with a commit or abort log
record.
This is irrespective of whether physical or logical changes are
logged.
#44
| |||
| |||
|
|
"Christoph Rupp" <cruppst... (AT) gmail (DOT) com> wrote in message news:91140c56-1f05-4b5d-b45f-b34920db2051 (AT) x41g2000hsb (DOT) googlegroups.com... Brian, On Apr 21, 11:00 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. It's not an SQL database, i don't even have the notion of "rows", but basically i think your #4 is the same as my #1 or #2. No, it isn't. #1 requires the logging of additional records that may not have been affected by an update. #2 doesn't log the entire changed record, but only bits and pieces. I would think that limiting the units of change to individual records--entire records--would simplify the process of marking and isolating units of work while at the same time guaranteeing consistency. |
change to an individual record. Are you suggesting transactions to
define arbitrarily large units of work aren't needed?
Typically a log will contain special log records to mark transaction
boundaries. Many systems allow interleaving of transaction log
records by using a transaction id in each log record. Each
transaction is normally expected to end with a commit or abort log
record.
This is irrespective of whether physical or logical changes are
logged.
#45
| |||
| |||
|
|
"Christoph Rupp" <cruppst... (AT) gmail (DOT) com> wrote in message news:91140c56-1f05-4b5d-b45f-b34920db2051 (AT) x41g2000hsb (DOT) googlegroups.com... Brian, On Apr 21, 11:00 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. It's not an SQL database, i don't even have the notion of "rows", but basically i think your #4 is the same as my #1 or #2. No, it isn't. #1 requires the logging of additional records that may not have been affected by an update. #2 doesn't log the entire changed record, but only bits and pieces. I would think that limiting the units of change to individual records--entire records--would simplify the process of marking and isolating units of work while at the same time guaranteeing consistency. |
change to an individual record. Are you suggesting transactions to
define arbitrarily large units of work aren't needed?
Typically a log will contain special log records to mark transaction
boundaries. Many systems allow interleaving of transaction log
records by using a transaction id in each log record. Each
transaction is normally expected to end with a commit or abort log
record.
This is irrespective of whether physical or logical changes are
logged.
#46
| |||
| |||
|
|
"Christoph Rupp" <cruppst... (AT) gmail (DOT) com> wrote in message news:91140c56-1f05-4b5d-b45f-b34920db2051 (AT) x41g2000hsb (DOT) googlegroups.com... Brian, On Apr 21, 11:00 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. It's not an SQL database, i don't even have the notion of "rows", but basically i think your #4 is the same as my #1 or #2. No, it isn't. #1 requires the logging of additional records that may not have been affected by an update. #2 doesn't log the entire changed record, but only bits and pieces. I would think that limiting the units of change to individual records--entire records--would simplify the process of marking and isolating units of work while at the same time guaranteeing consistency. |
change to an individual record. Are you suggesting transactions to
define arbitrarily large units of work aren't needed?
Typically a log will contain special log records to mark transaction
boundaries. Many systems allow interleaving of transaction log
records by using a transaction id in each log record. Each
transaction is normally expected to end with a commit or abort log
record.
This is irrespective of whether physical or logical changes are
logged.
#47
| |||
| |||
|
|
Several advantages of logical logging, not the only ones, I'm sure: 1) Likely more insensitive to future changes in physical organization/operations. 2) Potential to reconstruct old db values with additional constraints applied (I don't know how many times this would have avoided much more awkward surprise requirements). 3) Ability to shadow via another physical db, eg., for read-only audit or various performance requirements (my favourite advantage, maybe most people would favour #1.) |
There are also disadvantages to logical logging
a) logical changes aren't always idempotent
b) there are many forms of logical changes, whereas physical changes
to a page are always assumed to simply be assignments to a range of
bytes within the page.
Both of these create a lot of complexity. I think physical logging
is much easier to implement.
#48
| |||
| |||
|
|
Several advantages of logical logging, not the only ones, I'm sure: 1) Likely more insensitive to future changes in physical organization/operations. 2) Potential to reconstruct old db values with additional constraints applied (I don't know how many times this would have avoided much more awkward surprise requirements). 3) Ability to shadow via another physical db, eg., for read-only audit or various performance requirements (my favourite advantage, maybe most people would favour #1.) |
There are also disadvantages to logical logging
a) logical changes aren't always idempotent
b) there are many forms of logical changes, whereas physical changes
to a page are always assumed to simply be assignments to a range of
bytes within the page.
Both of these create a lot of complexity. I think physical logging
is much easier to implement.
#49
| |||
| |||
|
|
Several advantages of logical logging, not the only ones, I'm sure: 1) Likely more insensitive to future changes in physical organization/operations. 2) Potential to reconstruct old db values with additional constraints applied (I don't know how many times this would have avoided much more awkward surprise requirements). 3) Ability to shadow via another physical db, eg., for read-only audit or various performance requirements (my favourite advantage, maybe most people would favour #1.) |
There are also disadvantages to logical logging
a) logical changes aren't always idempotent
b) there are many forms of logical changes, whereas physical changes
to a page are always assumed to simply be assignments to a range of
bytes within the page.
Both of these create a lot of complexity. I think physical logging
is much easier to implement.
#50
| |||
| |||
|
|
Several advantages of logical logging, not the only ones, I'm sure: 1) Likely more insensitive to future changes in physical organization/operations. 2) Potential to reconstruct old db values with additional constraints applied (I don't know how many times this would have avoided much more awkward surprise requirements). 3) Ability to shadow via another physical db, eg., for read-only audit or various performance requirements (my favourite advantage, maybe most people would favour #1.) |
There are also disadvantages to logical logging
a) logical changes aren't always idempotent
b) there are many forms of logical changes, whereas physical changes
to a page are always assumed to simply be assignments to a range of
bytes within the page.
Both of these create a lot of complexity. I think physical logging
is much easier to implement.
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.